Businesses Must Find the New ‘Personal Touch’

Agile Myths: Change Without Cost

Atos - Agile Myths Change Without CostWay 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.

About David Daly

David is the Global Deal Assurance Manager at Worldline, the European leader in the payment and transactional services industry. He is also a member of the Atos Scientific Community where he is part of the DevOps track. He has worked within the technology industry for over 15 years in a variety of roles including developer, analyst, technical architect and development manager. He often challenges conventionally accepted wisdom and has a passion for proving that alternative approaches can produce better results. He lives in Nottingham with his better half, his 2 young daughters and a female cat called Bob. Outside of work David enjoys running and playing piano in a 60s covers band.

  • Philip Neale

    I wasn’t aware of the commonly accepted meaning of Agile, so I found this blog very interesting.

    I wanted to examine the underlying cost analysis behnd Barry Boehm’s data before making any comment on the method.

    I checked on Amazon with those reviewers who rated his book least highly, and found the following

    “There’s no reason to believe that the conclusions are very outdated, though it would be nice if someone did a new study like this that showed (very likely) that the numbers have changed only slightly. I got this book when it first came out and led many software engineering teams. The summary is basically that better tools and methods can add only 10-20% in productivity at any stage in the life cycle. The only way you can get higher, or much higher, productivity is by getting better people. And that’s what I found in 25 years of career after the book came out.” – 2013

    That’s assuming you and the client get the requirements right in the first place

    • David Daly

      Hi Philip,
      Thanks for the comment.
      I have a post in progress that talks more about the various factors that affect productivity, including the importance of the people working on the project (although I see that this is now being called in to question by some).
      And as you say, getting the requirements right is absolutely crucial. That is something that Agile does help with as I touched on in my post on Hypothetical Value.

  • Kirk Williams

    Really interesting post with lots of great points well made. It is really important imo to get the mesage out that Agile is not a magic wand and that there is an inevitable/obvious cost to change at some point. Being picky, I worry that to the casual skimmer the soundbite title is in danger of implying that Agile approaches and practices do not reduce the cost/impact of change (they do, as David ably articulates in the post). But for me the main thing to add here is the fundamental principle that the cost of change is not necessarily something to be avoided if it gives the business the right solution. Agile approaches are predicated on the expectation of inevitable change and, where that change has genuine business value, accommodating it. This is a very different starting point from encouraging a culture of resistance to change that all too often becomes entrenched in traditional approaches.

    • David Daly

      Hi Kirk,
      Thanks for your comment. I completely agree with what you say. Perhaps the link to my previous post on Hypothetical Value was too subtle (as I talk there some more about a key benefit of Agile being that it helps you to discover what does and doesn’t deliver value and adjust course accordingly).
      I also have another post in progress about the fact that Agile concentrates on delivering the right thing rather than delivering faster or cheaper. One of the ways it achieves that is by embracing change.

  • Philip Neale

    Are there any studies or available evidence which compares and contraststhe costing of alternative project management methods on like for like projects. How does that even work given market conditions?

    • David Daly

      Hi Philip,
      Not a lot but there is some. Without giving too much away from my next post, this report from the Cutter Consortium is well worth a look.