Today, as much as Agile is scoring over traditional methodologies like Waterfall, the customer demand for fixed bid (AKA fixed price) projects has not died down. Even though Agile significantly improves its success quotient due to improved communication/collaboration, rapid feedback, enhanced flexibility in managing changes, etc., Agile sceptics point to problems. Problems such as project scope creep, insufficient customer involvement, lack of predictability (“when will the project complete and what will it deliver”) and quality issues caused by inadequate testing or overly intense (fatigued) development.

Under such scepticism, you might think the question “can we do Agile in fixed-price mode?” could only have one answer.

This article critically examines this question and provides a commentary in terms of its pros and cons, and a proposes a way of working with Agile in a fixed bid project, that can still be highly beneficial for both the customer and the vendor. Fixed bid projects pre-supposes delivery of software at a (known) cost within a time-frame which is estimated and agreed upfront, with full clarity available with respect to:

• requirements in sufficient detail with understanding complexity and priority;
• who will do what;
• what will be delivered and when;
• how (technology, people needed, estimates/plan/schedule); and
• the budget of the customer.

Suffocating Agile: When Scope, Schedule and Cost are fixed

Many organisations have a preference for full-fledged fixed-bid projects because of the sense of assured predictability it affords them about the scope, schedule and the cost. Keeping these three elements fixed is not typically vendor friendly and can run counter to the Agile way. Here’s why:

• Agile’s raison d’être is embracing change and if the changes that the customer wants cannot be taken up because of a desire to fix the project upfront (i.e. by delivering to business imposed timelines), it becomes self-defeating;
• As and when a “must-have” change is required, discussions concerning how to accommodate the change are required and can mean changes to cost and schedule which can strain and damage the relationship. A far cry from the ability to embrace change!;
• If more functionality than was originally planned is (forcefully) introduced by the customer, and demand begins to outstrip supply the rhythm of development and the team’s state of mind can come under intense pressure due to the need to continually deliver iteratively in an ‘agile’ mode;
• The essence of Agile being about empowered delivery teams, transparency, shared learning, bonding, fast feedback/delivery falls by the wayside in a tightly fisted fixed-bid program.

So it follows that ‘fully-armed’ fixed bid is not suited to walk hand-in-hand with Agile.

The EmbArrk Way: When Schedule and Cost are fixed but not the Scope

It is possible that the customer may expect the application delivery by a certain business date within a specified budget. Schedule and cost being tangible can be regulated, however scope being subjective and customer-influenced is difficult to fix. So what’s the way out?

The way to make this work is to segregate and understand the scope in a time and money mode and do the implementation in fixed-bid mode. This is a win-win for both the customer and the vendor. Let’s examine this from an Arrk Group perspective.

A customer wanted to shift from a traditional approach of software development to Agile; therefore the initial phase of the project involved Arrk Group running an EmbArrk workshop to gather and agree high level requirements (i.e. epics), along with product backlog containing (functional + technical) user stories amongst other deliverables like lo-fidelity prototypes, high level release plan and cost estimate.

The essence of the EmbArrk framework is engagement with different stakeholders to create a credible functional roadmap, story development (as much as possible within the scheduled three weeks duration of the workshop), rapid prototyping with emphasis on usability, all aided with visual models.

The entire scope (i.e. product backlog) was formed with the customer’s involvement to understand and prioritise the work. Product related suggestions or ideas from the customer were discussed and updated in the backlog. The project artefacts delivered helps to build agreement across all stakeholders and brought customer and Arrk to a precise understanding of what would be delivered, by when, responsibilities on all parties involved and helped build mutual trust, all within the three week schedule of the workshop.

User stories were then estimated based on the story points. Relative sizing of the user stories helped estimate the entire backlog in terms of story points. Total number of story points was treated as (fixed / determined) scope for the project.

Arrk Group agreed with the customer that change would be accepted throughout the project. This was achieved by firstly understanding the relative value to the business of each story and using this to decide priorities, agreeing that stories could be swapped in any iteration or sprint and reserving a percentage of the overall budget for additional stories. The swaps would be agreed on the basis of story points assigned thus keeping control on overall scope and cost.

When combining Agile with fixed-price projects, the following are important considerations:

• The fixed scope is represented by total number of story points derived during an EmbArrk workshop, make sure to include a story points reserve to accommodate new stories that maybe identified during the project.
• Additional stories requested by the customer and representing reprioritisation of the stories, enhancements, feature de-scoping is eminently possible, as in an Agile way of working. Arrk Group terms them as zero-cost changes.
• All changes are determined by the customer according to their relative priorities.
• Risks, assumptions, dependencies and issues must be meticulously tracked and managed.
• Initial sprints should be treated for setup, learning, etc. to stabilise the team velocity to determine if very different from that used during the EmbArrk rapid discovery and planning process.
• Scrum ceremonies should be diligently followed like sprint planning, daily stand-ups, show-n-tell demos to customers and team retrospectives.
• Transparency is critical.
• Burn down charts and similar must be used to track the scope – schedule.
• Based on the completed story points and task based total man hours, we can identify by sprint, the amount spent compared to the fixed cost.

Fixed bid projects are a good way of sharing risk between customer and the supplier, while Agile (undoubtedly in our view) represents a better way to manage projects compared to traditional methods. By agreeing upfront the total story points to be delivered as scope, and then simple mechanisms to embrace change, it is possible to remain within the boundaries of fixed cost and schedule and deliver flexibly to the customer. Agile brings collaboration and quick feedback loops to the fixed bid projects, while ensuring transparency amidst a promise of delivering a usable product.