Change is free except when it’s not.
The primary reason that any project fails is that we cannot predict the future. What we believe to be true at this moment will invariably change over time. Change is costly which is why we endeavour to plan ahead, defining what will be done, when it will be done, and how much it will cost. We rate our ability to predict the future so highly we do not factor in the invariable change that needs to be accounted for during the course of a project.
With any textbook waterfall for project there is a Gantt chart, complete with accurate timeline and cost structure. The allure of the Gantt chart is its ability to fake confidence and successfully secure commitment to a bid, and convince the client everything is under control – it never is.
Waterfall does not plan to change and that is why it fails. Offer anyone £100 to show you a single project where the original Gantt chart timeline and the actual timeline once the project has completed match exactly, you won’t even need to reach your wallet. If an organisation is very lucky They may have one example where the Gantt chart and the actual timeline almost match, but even in such a case change has occurred and unexpected cost is the result.
Scrum welcomes change. The well-defined plan is thrown out, in favour of the more realistic and flexible roadmap. The items in the near field are more well-defined while items further afield are less well-defined, this allows organisations to focus on what is directly in front of them without losing sight of obstacles further down the road. Change is expected and embraced, we don’t lie ourselves and others that we are somehow and divine and different from the majority, capable of predicting the future Despite curiously never having won the lottery jackpot.
Iterations of 1, 2, or 4 weeks allow development teams to work on what is right in front of them without distraction, and enables a product owner and stakeholders to review what has been delivered in the last demo and better understand what should be delivered next. This flexibility allows the client to change their mind and invariably do without negatively impacting the productivity Of the team and the project. The only condition attached to embracing change is that the change should not be actioned as part of the current sprint commitment.
The sprint commitment is a collection of effort agreed to be committed to during a single iteration by the development team. The commitment is not a promise or guarantee but a best guess estimate The development team believe they can deliver based on knowledge and experience, and ultimately empirical data.
Development teams have the right to push back on and even turn away items of work that lacked clarity and definition. It is the responsibility of the product owner, working with the scrum master and overall development team, to clearly define the desired outcome and definition of done. Ensuring the development team know when a task is complete and that it will meet the desired outcomes that will best serve the stakeholders.
To change an item already committed to during an iteration Is a signal To the product owner and scrum master That there is a lack of agreement As to what is required To best serve the stakeholders. We do not have all the information all of the time and information presents itself over the course of the project, with this new information we adapt the deliverables as part of the next iteration. We embrace the change in the next iteration.
If it is found that work within the current iteration is not worth the effort based on the information available, the product owner may take the decision to remove items of work from the current iteration. This change to the current iteration should not distract from the remaining committed effort. If however the change to the current iteration is such a significant impact the remaining work within the iteration should be dropped altogether, the product owner may consult the development team and stakeholders to end the sprint prematurely and restart the sprint process.
Agencies that work with agile in mind should write this agreement into the contract with their client, stating that changes are free provided they do not interfere with the current active iteration and do not constitute new requirements not previously defined within the statement of work.