How can you combine Scrum with a project constrained by a fixed price and completion date? Tim van Baarsen discusses his experience of completing a fixed-everything tender through continuing to work with Scrum behind the scenes.
Following the creation of a backlog from the initial requirements, Tim's team then began to release iteratively in regular sprints. Through pointing and burn-down visualisations, they were able to provide predictability and adaptiveness in spite of a macro-level time box and specification. The project was delivered on time and within budget.
To help understand how scope can be adjusted on a fully constrained project, Tim writes:
“Even in 'fixed everything projects' we all know that requirements will change in time, they always do.”
He continues:
“change requests don’t really fit in our Agile approach, however we want to remain flexible so we prefer to exchange requests.”
Tim describes the “exchange request” as a mechanism for dealing with changes in understanding, such that redundant or less important stories, may be replaced with new ones, so long as they are of an equal size. Through these “exchange requests” the risk of change is mitigated by keeping the total size of work constant.
Earlier this year Peter Vaihansky addressed the question of whether a large project can be fully constrained. Citing a survey by McKinsey and the BT Centre for Major Programme Management at the University of Oxford, he points out that the successful fixed-everything project is a myth. The survey, covered “more than 5,400 IT projects, software projects (especially large ones)", finding that on average these run 66 percent over budget and 33 percent over schedule.
Peter's article suggests that the lack of a feedback loop is often the cause of failure in most fixed-everything projects. He writes that this can be resolved by replacing a fixed-price with a fixed budget, such that:
”your financial outlays are capped, and the deadline may be fixed, but you get to vary the scope and make changes to the requirements based on the reality of how the project is actually going.”
The success of an agile project is always down to the people involved. At the very onset of the project, Tim created a cross-functional “Tiger Team.” He also recognised the need for a traditional Product Owner, such that the full specification may be humanised into a single “point of accountability”; someone capable of understanding the client's requirements and making decisions on their behalf.
Through the Product Owner and Exchange Request process, the team have demonstrated a method of responding to change without pushing out time scales. By allowing the product owner to make calls on scope, a minimal viable product was delivered within a fixed time-scale.
