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.
2 Responses
Excellent post and perhaps you could provide an opinion on the reason why a team would say something is too big for a sprint.
First I am not a scrum master, I am one of the guys who has to deal with the very unrealistic assumptions SCRUM creates, basically somehow there is no dependency and lets skip design.
So we get to the issue and I will use an easy example. I will get a story that is in effect this. I the business owner need to have a flag pole on top of a 60 story building. , next story, I want to have a string to put a flag on and raise the flag on the pole. Next story. I want a flag of X color and Y shape.
Then the issue, there is no 60 story building. That has to actually be purchase or built and then a flag pole put on it. Yes a flag pole can be installed in a day, it will be a year or two before the building can be built.
Now I used a very obvious and extreme example but it happens with software development. I want user security groups to have on every screen in my app.
Great, there is no system in place to do that function and it takes 3 weeks to install and configure just to get it ready for a story like that.
Just like the building it is too much for a single sprint.
The scrum masters and coach will harp like small children the story is broken down, its a flag pole, too bad for you if you cant build an entire building in 5 days.
So then you get the effect you described attempting to get that building built by modifying scrum to attempt to satisfy a rigid methodology and somehow actually build the building.
Yes I have attempted to reject stories that cant be built in 5 days, though that is when you get to the fact that once a story is written the various leadership cant accept the fact its wrong. They wont call it an epic because what value is it to the business to have the 60 story building built, they just want the flag pole on top. Or the security on every screen.
The security on every screen is even resisted because with 560 screens, the simple task of enablement is by volume alone greater than a sprint but at least those screens can be broken down to individual stories. Just not the 3 week build.
The coding example is real, this happens all the time, in every scrum project I do and it is amusing to watch. How the team will effectively build it anyway because the scrum masters and business owners are demanding the story be done and pretend the 3 weeks of buying and installing the needed software components happens in some sort of alternate universe.
So the end result is the modified SCRUM which I agree has little benefit if not counter productive or you get skunkworks. Basically the development team doing what they need to do to make it happen behind the scenes and merely reporting only what is related to stores to satisfy scrum reporting requirements and make story writers and scrum masters happy and belief their method is working.
What is your suggestion? My example is a security tool, it is a purchased product, which takes 3 weeks to install and configure into a set of servers and tools, just to be ready to start the story. It is a product, there is no do it half way, you could not get half of Microsoft Excel to install and expect anything, its all or none and any security product or rolling your own results in the same 3 weeks. Business users get that glassy eyed look about what value is it to me, which I would normally say I guess you don’t want the security the story is about.
Thanks
Great points made here. Scrum is based on proven methods which will be beneficial when you implement them the right way in your company. Making large changes to the original Scrum process is very likely to end up as a mess like the example given here.