Is Change Free in Agile?

The underlying purpose or motivating factor behind the whole Agile development methodology was to allow teams the flexibility to inspect and adapt to changes. This was something the practitioners of traditional waterfall methodology were longing for after scope creep ruined almost every project they worked on so, they jumped headfirst into the Agile pool so that they can “Embrace Change”. So far, so good – right?

Unfortunately, one of the biggest misconceptions about Agile is the fact people think that change can be introduced at any point during an Agile project and it will be free & easy because isn’t Embracing Change the underlying philosophy of Agile?

Yes, an Agile project is supposed to Embrace & Adapt to changes. But, are these changes free? Read on, to find out more…

Does Change Have a Cost?

In one of my recent projects, I was talking to my product owner to get the product backlog in shape for the upcoming product release. He did have a couple of features/backlog items for the team but the features were still under review and could potentially change. Myself and the Scrum Team were a bit reluctant to start work on a user story that was eventually going to change whereas the Product Owner just smiled and said – But I thought you’re agile, and isn’t the whole point of being agile that you welcome changing requirements? Why are you guys so reluctant?

Yes, he was right, the Agile methodology does allow us flexibility to embrace changes, but I had to explain to him that this change is going to have a cost impact and is not free.

Let’s say we start work on User Story (US) 1 and finish it in Sprint 1. In the middle of Sprint 2, while we are working on US 2, we receive changes in US 1 which need us to take up a few days’ worth of rework which results in neither stories being finished in Sprint 2. In Sprint 3 when we are about to finish both US 1 and US 2, we receive further more changes on both stories which results in more rework and once again neither story is completed at the end of Sprint 3.

Though the team was occupied for 3 Sprints, the eventual outcome is 2 stories that are partially complete with potentially more changes on the horizon. Haven’t we quite literally wasted 3 Sprints by the team in our aim to adapt to Change? Not to mention the opportunity cost the company has lost because, this effort could’ve been used to build useful features that could increase the value of our product. Get the picture?

This is the “Cost” I am talking about when we say, Change isn’t Free. The bottom line is – “Every change has a cost”.

This is the point that gets overlooked by new followers of Agile or Scrum because the trainers who imparted scrum wisdom to them probably missed mentioning this point.

What is your experience in handling change in Agile/Scrum projects? Do share them in the comments…