Nowadays “Agile” is in everybody’s mind. It has all started in the nineteen’s with first attempts to follow early agile methodologies in the area of software development, and it was finally set in stone by the agile manifesto in 2001, published by the Agile Alliance.
In the light of the increasing popularity of Agile approaches, not only in software development but generally regarding multiple changes in enterprises, an important question pops up here and there. Can Agile be combined with Fixed Price projects? This question is very valid as more and more software development projects are in FP mode, with a huge portion of the risks transferred to the vendor.
At a first glance you may think that the character of an FP project always demands to have the deliverables clearly described, down to the detail, with models, mock-ups, lots of documentation and with plenty of non-functional requirements to fulfil the acceptance criteria fixed in the contract.
In contradiction to that, Agile appreciates changes throughout the development phase, even late changes are welcome if they deliver value. This is the keyword: value has to be delivered, and this justifies or is sometimes only possible by having an agile attitude towards changes. So, simply saying we will not do it Agile is not an option.
If we are asked to combine both elements, Agile and FP, we are in a dilemma: Agile leaves the doors open for (even late) changes while in FP projects contracts are “closed”, i.e., deliverables are definitely fixed with the closure of the contract. More often this can happen simply because different cultures meet: e.g. Business is used to and insists to have contract in place while development and project teams more and more want to go for Agile as they see that more value can be delivered. How can we escape from this?
The key is the structure of the requirements. In order to close a reliable FP contract, at least the Business Requirements need to be fixed. According to the BABOK® the Business Requirements describe the “Why” and major parts of “What”, while they shall not deal with the “How”. If you consequently restrict the contract to Business Requirements and probably a selected set of Non-Functional Requirements (aka Quality Requirements) there is enough room beyond the contract to apply an Agile methodology.
Let’s look at a scenario where Waterfall-minded Business people meet a vendor with SCRUM development teams. How could a FP contract look like? A Business Requirements Specification (BRS) needs to be created by Business Analysts, of course in close collaboration with the Business, somehow satisfying one of the twelve principles behind the agile manifest “Business people and developers must work together daily throughout the project” but with the slight difference that there are no developers in the early phases of a project. Business Analysts are asked to elicit the Business requirements, performing all tasks described in BABOK®’s Enterprise Analysis (e.g. determine Business Need – What does the company really need?) and finally deliver the most important element of the FP contract, the BRS. And to be in-line with SCRUM, a BRS can consist of Epics, can use Personas and more elements of SCRUM which makes it easily usable by agile developers who step in later.
If the Business accepts a closure of a FP contract with such a Business Requirements collection but without a detailed description of the solution, the major pre-conditions for an Agile development based on a FP contract are given. But, there’s one important ingredient which I think is needed in each and every Agile project: Trust. Only with a significant portion of trust (in what will be delivered without having a clear imagination of it) Business will be willing to release the budget which is needed to set up an agile project organisation and to start with the development.
Quintessence is that as every Fixed Price contract needs to have some concrete content. The BRS can be used for this purpose, preferably adapted to the agile style which will be used by the development team after the FP contract has been closed.
For those who want to deep dive in agile Business Analysis and Project Management we offer a 2-day course http://www.masventa.eu/en/academia/agile-business-analysis-and-project-management/ which gives you 16 PDU or CDU for PMP or CBAP Re-certification.
Apologies, but the following two events are only for German-speaking folks:
If you are interested in agile Business Analysis and Project Management you may want to join a Webinar http://www.masventa.eu/sub/gratis-webinar-2510-1500-agile-business-analyse-und-projektmanagement-nach-babok/
This topic will be discussed by some BA and PM experts on the 1. Business Analysis Summit in Salzburg, October 11th 2013, please refer to www.business-analyse-summit.com. Do not miss to join!