Way back in 1981 Barry Boehm published his book Software Engineering Economics. In it he included the Cost of Change Curve (which he had previously published in a 1976 IEEE article) which showed that the cost of change grows exponentially as software development progresses through the stages of requirements, design, code, test and production. It indicates that making a change after software is released will cost 150 times more than making it at the requirements stage. This is the main reason that traditional approaches to software development try to minimise the amount of change that occurs in the later phases (by, for example, completing all design work before coding starts).
But modern techniques call in to question the validity of the Cost of Change Curve. As Uri Nativ puts it in this post:
“When you incorporate techniques like Continuous Delivery and Test Driven Development you are diminishing the basic assumptions that were valid back in the 1970s. We can fix a defect in production within minutes.”
And indeed, in 2001, the authors of the Agile Manifesto declared that change late in a project, rather than being resisted, should actually be considered a good thing. They recommended that you should:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
So do Agile methods really achieve this? Do they allow changes to requirements to be made at any time with no cost or timescale implications?
In practice Agile approaches aim to minimise the cost of change in several ways. By doing just enough design for only the features that will be implemented within the next few weeks they minimise the risk of designing something that will be changed or removed from scope. They avoid design rework by only completing the design “just in time”. By using technical practices like Continuous Delivery and Test Driven Development they reduce the cost and time involved with testing and deployment. Doing this makes it feasible to test and deploy far more frequently.
Interestingly though, Agile techniques recognise that change once development of a feature has started does increase the development cost and timescales. In his book Succeeding With Agile Mike Cohn describes why teams using Scrum should try to avoid changes introduced mid-sprint:
“Few organisations are in industries that change so rapidly that they cannot set priorities at the start of a two week sprint and then leave them alone. Many organisations may think they exist in that environment; they don’t. It is usually a matter of becoming more accustomed to thinking ahead. I want to help those outside the team learn that there is a cost to redirecting the team. Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t plan.”
Kanban takes a slightly different approach. Because there are no fixed length iterations (sprints), the business is free to re-prioritise and change requirements at will up until the point that work is started on a task. Even then Kanban systems can allow for urgent work to take priority by expediting it. David J Anderson (in his book Kanban: Successful Evolutionary Change for Your Technology Business) describes how this works in manufacturing:
“The ability to expedite offers vendors the ability to say ‘Yes!’ in difficult circumstances to meet a customer need. However, expediting orders badly affects manufacturing supply chains and distribution systems. Expediting is known in industrial engineering and operations research both to increase the inventory levels and to increase lead times for other, non-expedited orders.”
And the same applies when using Kanban for software development: the business can choose to expedite something, but has to accept that other features will be delayed as a consequence. One of the great benefits that my team has found since we introduced a Kanban system is that it made us think about and define what the process should be for expediting (i.e. who makes the decision and how it is communicated). This means that:
- Things are only expedited when it is really necessary (and more often than not, it isn’t)
- Everyone on the team is aware of anything that is being expedited and why
- We explicitly limit the number of tasks that can be expedited at any one time (to 1)
In practice we have found this means tasks are rarely expedited and developers have reported to me that they receive fewer interruptions.
So, in my view, Agile does not enable change to be made without any cost. What Agile does do is:
- Reduce the amount of change that may be required by doing less work upfront
- Reduce the cost of change that is required by using modern technical practices
- Reduce the amount of change to software that is already under development by communicating clearly to the business what the impact of that change will be
And that ability to embrace change, whilst also managing it effectively, is one of the key reasons that Agile techniques allows you to deliver more value, faster.