Agile project frameworks expect (and were designed) specifically to manage change. In a true Agile project, there’s no concept of a traditional change request. Change is managed through the application of the safeguards built into the framework itself. When structuring a contractual agreement, it is important to decide on how change would be managed without the need for a formal (and often costly) Change Request process.
Typically, and in order of magnitude/impact, these are our recommendations on how changes should be managed on an Agile project:
- Flex on scope within the existing envelope: Fundamental to Agile practice is the mechanism and agreement that scope is the only flexible variable (notwithstanding the next options). Where time and cost are fixed and a change occurs, this is the only place that can be varied. In practice, this will require an empowered Product Owner (or equivalent role) to be able to make decisions on what backlog items to take out of scope in order to accommodate the new/changed scope. This is alongside an agreement on what scope items are, Should or Could Have backlog items and can therefore be de-scoped with minimal impact.
- Agree to increase time: If option 1 isn’t enough or acceptable, and there is an option to request a change from the Business Sponsor for both duration and budget, then the next option is to increase the number of sprints to ensure that all Must Have Backlog Items can be delivered. This is only a decision that can be made by the Sponsor at the recommendation of the Product Owner. Before this is agreed, we also suggest that the Business Case is revisited to ensure that an extension in duration and budget does not adversely impact this. Sprints need to be extended at a fixed cost per sprint with the same persistent team in order to maintain predictable velocity.
- Agree to add an additional full team: Where duration/time cannot be flexed but budget can be increased, this is the next available option. Adding additional resources into the existing team is not an efficient option and can often add delays, break predictable velocity and disrupt the team. The best option is to add an entirely new team to the project who can work from the same backlog to increase project velocity. Again, as this option will impact the Business Case, this can only be agreed by the Sponsor.
- Agree to stop: Where none of the above options are viable without an unacceptable impact to the Business Case, the Sponsor should be empowered to make the decision to stop the project. Agile processes allow this to happen in a smooth manner while ensuring that, for the duration of the project, some value was still delivered. If no value can continue to be delivered, then stopping should be the only acceptable option. Also known as the ‘Fail Fast’ option, this can and should be celebrated as a positive outcome – a mature organisation that can capture maximum value and close the project early where necessary will ensure that funds can be redirected and used in the most efficient way possible.
Change is inevitable, it’s the project team’s ability to react and respond appropriately that determines whether the outcome is positive.
For more information on Agile Project Delivery and how PM-Partners can help your organisation accelerate results, contact us today on 1300 70 13 14.
