Why making things “easier” makes them harder: The argument against modifying Scrum
I’m sure many ScrumMasters implementing have heard this or similar: we’re not like other teams; we do things differently; Scrum won’t work in our organization. The result is usually: “let’s modify Scrum so the adjustment is easier on the team/organization/processes.” Sound familiar? I’m not against some modification to ease the transition, but it needs to be for the right reasons – the TEAM. Mostly the modification is done for the organization and culture – that is to what I’m referring.
First, Scrum principles have been proven to work in all sorts of teams and organizations. No organization is truly “special” or too complicated to have Scrum work effectively, especially not yours. Maybe that sounds harsh, but read on and I will enlighten you with my experience.
Secondly, modifying practices too much almost never makes it easier. In fact, in most cases it makes it exponentially harder. This revelation was inspired by my tweet, “The % #agile #scrum methods are modified is exponentially proportionate to the % of extra work, complexity and team stress that results.” which I composed after many stressful meetings trying to convince my management not to modify practices further and failed – for now.
So here’s the real life example on why I know this doesn’t work…
The story: Our Agile team cannot possibly do all the work to complete a story in one iteration (let’s call this n). Someone has a great idea to do the requirements an iteration prior to development (let’s call this n +1). Another person has an idea to move testing to the iteration after development (let’s call this n-1). What does this give us? A mini waterfall taking place over three iterations.
But alas, it seems we are doing all that work in one iteration…just not on the same user story. So instead of focusing on one user story we’re now focusing on three, each in different stages. This is just the beginning of the complication.
So what are the consequences besides the massive confusion for all?
- Putting a hold on delivering business value as stories are spread over three iterations
- Productivity is being lost as team members are trying to split their time across multiple iteration efforts and therefore spend more time switching tasks than concentrating on one.
- An accurate team velocity can’t be calculated because stories that are developed aren’t truly being accepted during the iteration.
- Too much work in progress (obviously)
Definition of Done confusion – there’s a different definition for each section of work
In the end, what was supposed to make the transition easier has just turned into a mess. For ScrumMasters out there struggling with this – keep fighting it or it might be a time where things have to fail in order to show it’s not working. Referring back to my “Confessions of a New ScrumMaster” post, keep asking why to try to get to the bottom of things – the answer in this story is our user stories are too big and we need to break them down and also cultural issues within the company. Change is scary, but I guarantee that large scale modification will make things much harder. It hurts the integrity of Scrum and that is one of the reasons Agile myths emerge and it can get a bad rap.