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…
No comments:
Post a Comment