Scrum & Fixed-Bid!

One of the primary concerns of the software practitioners about the Scrum framework(or Agile methods in general) is its adaptive nature as opposed to the conventional prescriptive approaches. The common question that is usually thrown around is “How can you estimate and present a bid if you are Agile? How does it work if the customer expects a fixed bid?” This article tries to answer that question in the few paragraphs that follow. Without even to get into the very fundamentals of Scrum, a quick thought about the framework makes the thinker focus on three important aspects: Time-box: The projects based on the Scrum framework are time-boxed which means that the period of activity is fixed, usually one to four weeks for a sprint and one to three months for a release. What this means is that the development team tells the customer team “We will give you something at the end of this period”. Scope negotiation, not time: As the time is fixed and quality can never be compromised up on, the only point of negotiation here is scope. So, instead of buying more time to address the entire scope scheduled, the agile teams reduce the scope to fit to the schedule in the event of their inability to complete everything that they said they would. Prioritization: All the items that are being developed using the Scrum items are ranked as per their value and worked upon in the same order. This means that the items with the highest importance are attempted first and in case the team is bound to miss some items, they are usually from the bottom of the list, i.e., the items of lower value (Unless, of course the team misses a huge part of its target). Now, coming to the bidding problem, the ideal situation is that the team bids for the project on a Time & Material basis, in order to accommodate the changes in an efficient manner. However, many customers prefer to know the costs ahead so that they can plan their budget better. So, the challenge is to find a way to fixed-bid a Scrum project.

It is not as difficult as it sounds. 


Yes, the difference is significant, let us examine why. The time is fixed and so is the cost. So the customer would know exactly what they are spending. This helps them plan their budget better. Negotiation is on the basis of scope. So, even in case of any slippage, the customer and the development teams do meet their deadlines, albeit with limited scope. The release happens as planned on the committed date and this helps the team enormously since there is “certainty” as far as the release is concerned. Cutting the scope down!!. History tells us that a lot more than half of the features required upfront are not used. This is mainly because the product owners tend to club “Nice to have” features with “Must have” features. Since the Agile projects get executed on a priority basis, the teams always complete the features with highest value first so that in case they miss some feature, that usually falls within the range of a feature that is seldom used and the product owner could even decide not to implement that feature in the near future. The comparison is clear - in the traditional style, the development team gives everything to the customer with additional cost and on the Agile way, the customer gets the minimum viable product on time. What is better?

The bidding approach is not difficult either - Once the customer lets the scope out, the development team could do a quick vision planning that results in “Rough order of magnitude” estimates. This ball park estimate gives the teams the initial direction and the decision making advisory.

Then the team would plan the releases with story points. This should not take much time since it is not really detailed and the estimates are in terms of story points. Once the story point range is known, the team would match its velocity with the story point scope and then presents its bid, based on the number of releases required to deliver the features requested by the customer. The team may also advise the customer about the features that may not add value to the customer, there by leading to savings.

Then the interesting part - if the scope changes during the course of the development activity, which usually would, the changes are handled within the time-box. The scope changes, but not the estimates. If the requested (new) feature is of high priority, then the feature(s) matching the effort needed to develop the new feature would go out to the next release. So, the time is preserved and the value of the release is enhanced – a Win-Win! 
To summarize the concept, in a fixed bid environment, the team commits to a “fixed quantity” of features that would add maximum value to the customer. The set of features may change, depending on the evolving needs of the customer. This is in contrast with the traditional methods that make the team commit to a fixed set of features. How does Agility address the other challenges related to the fixed-bid projects that are sourced out? Team challenges: Quick and free communication among the team members - Eliminate communication gaps and waiting Transparency and total visibility – Build trust Lightweight processes that use “Just enough” formalities – Minimize waste Information Radiation – Detect problems early and minimize risks Completely aligned teams – Resolve dependencies efficiently Scrum of Scrums – Manage the whole Program Process Challenges: Fixed time (Time-box) and Committed Size/Throughput Variable scope to facilitate flexibility Change Management through Iterative Release & Sprint Planning Iterative planning to gradually eliminate uncertainty and get better at estimation How does it map to key project management practices? Scope: Epics, User Stories & Prioritization, Backlogs, Story Points Time: Time Boxing, Sequencing based on Priorities, Velocity, Task Hours Quality: Defect Prioritization & Management, Test-Driven Dev. Communications: Stand-ups, Reviews, Retrospectives, Informal communications Risk Management: Impediment Tracking & Removal Integration: Continuous Integration and Builds Cost, HR and Procurement can remain the same or customized as per the needs