Agile Fixed Bid – An Oxymoron?

Ideas2IT is primarily a high-end IT development outsourcing firm. We have been used to take up projects on fixed bid for clients who have a definite set of requirements. Even then, there is almost always scope changes due to changing requirements or due to requirements being elaborated in a way which was not originally envisioned while estimating. This leads to us raising change requests and having a tough time convincing the client.If this is so, how can we do a fixed bid contract for projects following the agile process?Agile, by definition, has to be flexible to accommodate changes as the project progresses. And how would a fixed bid work? Isn’t it an oxymoron?

The Truth about Fixed Bids

If you have done any fixed bid outsourcing before you would have realized the following:

Fixed bid is best suited for projects which have their requirements well defined.
Short duration projects work well in fixed bid mode.
Any small change in scope entails a long process of estimation and approvals.
In longer duration projects, you are forced to make a lot of compromises as the project progresses with the intent of keeping the project on track.
Fixed bids mostly follow the water fall methodology making it rigid to accept any changes midstream.
Even when the iterative process is followed, the very nature of fixed bid doesn’t allow for much changes.

So, isn’t it all the more true that Agile Fixed Bid doesn’t make sense?

In the traditional sense, yes. Agile fixed bid doesn’t make any sense. But Agile is anything but traditional!! Agile has brought in a sea change how software used to be developed. Huge systems that took a couple of years in development normally ended up being totally not useable or addressing the requirements of the user community sub-optimally. With Agile, constant feed backs from the user community and more frequent production pushes have made sure the end product better addresses the user’s need.But Agile has also brought in more complexity in terms of being able to budget for a project. If the requirements keep changing, how do you even estimate? If you are not able to estimate, how do you out source in a fixed price mode? Isn’t time and material (T&M) the best model to execute an out sourced agile project then?

Here we go again, T&M vs Fixed Bid

Well, it is a known fact that time and material model works best for project where there are constant changes in the requirements. Again, the outsourcers are a wary of time and material engagements as they are constantly pushed to evaluate the value they are getting through the outsourcing engagement. In a fixed price model, you exactly know what you are getting. But the challenge is what you get may not be what the users want. So, is there a viable alternative?

Enter Agile Fixed Bid…

What?? Agile fixed bid again? Didn’t we slay that monster in the preceding paras?At Ideas2IT, we are constantly approached by customers who want us to follow the agile process. In fact, we advocate the agile process for all our projects so that the customers can continuously provide feedback and make course corrections as and when required. But they also want more control over their budgets than what a traditional T&M engagement would provide them with. After a lot of experimentation, we have now come up with a couple of options which enable customers to work on a fixed bid model within the Agile process.

Executing Agile as a series of Fixed Bids

While we scope out the project requirements, we are fairly clear on the requirement details for at least the first few sprints while the rest would get progressively elaborated as we proceed. The idea is to estimate the work for the first few sprints and treat them as a fixed bid. As we progress into the project and requirement backlogs get flushed out with granular items, the subsequent sprints also get estimated and costs fixed. This way we are able to address both the concerns of flexibility and control.

The Cost per Story Point model

Another variation to the above model is to arrive at the costing per story point as the mechanism for the project budget. Each sprint, we pick up a few of the backlog items with pre-agreed story points. The costing is now based on the cumulative story points of the chosen backlog items. The focus now shifts to the story point evaluation which any way is part of the Agile Process.Eureka??Now that we have found a way to do agile in a fixed bid way, is it time to shout Eureka and run naked?? Not so soon. You will still have to consider a few things to make sure your outsourcing expectations are right.

UI/UX design – There is no right UI/UX design. While there are well established but ever evolving good practices in UI/UX design, the final decision on which UI to go with is a lot subjective. It makes a lot of sense to develop the UI a couple of sprints before the backend work starts as many a times flushing out the UI crystalizes the requirements better there by leading to more granular backlog items.
Rework – Rework is bound to happen when change is inevitable. Make sure you capture rework as part of the back log and treat them as separate items. There is a huge temptation to bulldoze the rework in addition to the new story points, but this will lead to less optimum time and in turn poorer quality.
Bugs – In a traditional fixed-price bid, we tend to add a buffer for bug fixing. In the agile model, bugs are supposed to be found and fixed within the sprint cycle. If found later, it needs to be taken up as a backlog item. There is no space in the estimation for anticipated bugs. The outsourcer will be worried that if there are more bugs than expected, there is no budget protection as all the defects will be lined up as backlog items for future sprints. We address this concern by arriving at a % of the sprint effort will be dedicated for bug fixing. This % varies sprint to sprint and project to project. As we progress deeper into the project, there needs to be larger % allocated for bug fixing. There is no fixed formula for this and a lot will depend on the nature of the project.
Testing – Ideally, in a two-week sprint, 60% should be for development and 40% for testing. You should keep this in mind while allocating story points. Developers too often do the mistake of underestimating the testing time required. If you are building pure reactive systems, integration testing becomes a time-consuming process. Make sure to choose the right frame works that allow you to quickly integrate and test.
Build and Release – In these days of continuous integration and deployment, you will have to take into account the time that would be needed for automated testing and DevOps scripting. It is better to bring this into your project execution culture. It is very difficult to retrofit.

It is a JourneyWe are not claiming that we have figured out everything. But we do have come a long way in this journey. Our customer satisfaction stands as testimony to the success of the Agile Fixed Bid Model. At Ideas2IT, we are committed to travel further on this journey to fine-tune the outsourcing models and create a win-win for both the outsourcer and the service provider. Still, intrigued by the Agile Fixed Bid Oxymoron?? Drop us a mail at sales@ideas2it.com and we will show you how!!Are you looking to build a great product or service? Do you foresee technical challenges? If you answered yes to the above questions, then you must talk to us. We are a world-class custom .NET development company. We take up projects that are in our area of expertise. We know what we are good at and more importantly what we are not. We carefully choose projects where we strongly believe that we can add value. And not just in engineering but also in terms of how well we understand the domain. Book a free consultation with us today. Let’s work together.

Ideas2IT Team