In an earlier post, we have examined how we can use agile in a fixed-bid project by considering scope as a variable. in this post, we will take a step back and examine the ways in which we can leverage the power of agile within the business constraints imposed by a fixed-bid contract.
1) Continuous Integration (CI) : Whether you are following a Dedicated or Time & Material or Fixed-Bid type of engagement, CI is a very useful and proven Agile tenet. The Root Cause Analysis of the issues that come up during the last stages of a typical release will point to Integration issues as one of the root causes.
There tools around which can be used for automatically building and deploying your code at very frequent intervals (or on a need basis) so that the integration issues are closed as and when they are found, instead of accumulating till the end.
One good example is CruiseControl, which has versions for Java as well as Dotnet environments. You could visit the thoughtworks site for more info on CruiseControl.
2) Pair programming: Pair programming is an agile tenet which advocates having a pair of programmers work together on all coding aspects, instead of working individually. Compare this with a typical scenario where the programmers work individually for all
their work. 100% pair programming is a controversial topic, and we will not get into that debate in this post. But what is not controversial, and indeed beneficial, is to use pair programming in a contextual manner. That is, whenever you are faced with a difficult problem, have 2 people work on it. That has proven to be much more productive than the aggregate work done by them separately. Also, there is a knowledge backup within the team for all the difficult sections within the codebase.
3) Small releases: Have an overall fixed-bid contract which allows about 20% deviation in the scope. Then have smaller iterations where small chunks of feature requirements will be identified, zoomed-in, designed, implemented, tested, and be ready to be deployed.
In other words, it is very common to find the fixed-bid billing model tied to the waterfall methodology. There are inherent problems with the traditional waterfall software developement life cycle (SDLC) methodology, and it is better not to mix waterfall and fixed-bid. Pictorially it can be represented this way:
Requirements->Design->Coding->Testing->UAT->Golive
Feature set #1—>Feature set #2 —>Feature set #3
Where,the first line indicates the typical approach using Waterfall model
The main difference is that in the waterfall model, the compartmentalization is in terms of phases, whereas in Agile, the compartmentalization is in terms of features—ie, in Agile all the phases will be implemented for each set of features in the order of decreasing priority of features. We will talk more about the mechanics of this, in a future post.
In summary, some of the Agile tenets can indeed be used in a Fixed bid model, actually reducing the heartburn for all the stakeholders in the client’s as well as the vendor’s side.
Tags: Agile, continuous integration, features, fixed-bid, integration issues, pair programming, phases, small iterations, sprints, waterfall
