I was talking to a colleague about one problem, and then said, "but this is not our biggest problem -- our biggest problem is lame scrum implementations."
So, I thought I would discuss that.
First, truly, our biggest problem is not Scrum or anything to do with Scrum. Our biggest problem is to figure out what "the good life" is, and then to live it. (A nod to Socrates.)
But, if we take the premise in business (which I do) that Scrum helps us live the good life, then anything that hurts Scrum, hurts us.
And I think Scrum, unfairly, is getting a bad reputation because of lame Scrum implementations. And, more to the point, people are suffering with 'less good' lives because of bad Scrum implementations.
Now, in every case I have seen, a bad Scrum implementation is better than what they were doing before. Still....
OK. What are the root causes of bad Scrum implementations? Here are my top 5.
1. Bad team.
By this I mean a team that is fundamentally not competent for the work that they have to do, or is fundamentally dysfunctional.
This is pretty darn rare, but I have seen it happen.
2. Bad company.
This is a company or company culture that apparently does not allow any impediments to be removed. Or almost none. Or only at great human cost.
I find this issue to almost always be there, to some degree. Except that I feel (and yes, Virginia, it is hard to call this more than a feeling based on lots of experience) that people feel more powerless to change the company than they really are.
Now I have companies so bad that I have said "well, if you can't change your organization, you have to change your organization."
Still, as the key root cause, overall I rate it fairly low (second).
3. Low knowledge.
Mainly this is low knowledge of Scrum, or of how to make a business case to managers to fix the impediments around here.
I find this very common, bordering on universal. But the main root cause of this cause (ie, the reason is does not get fixed sooner) is a lack of aspiration. IMO.
People always misunderstand Scrum to some degree. People always do it wrongly (at least for the first two years), as any beginner does with any sport or any musical instrument. We have knowledge decay. Etc, etc. This is not so hard to fix once we recognize it and mitigate it.
4. Serious technical debt.
I won't try here to define technical debt. But let's just say that legacy systems are hard to change. So, the team that works with a 'bad' legacy system can seem to have a lame Scrum implementation and get almost no velocity of new story development.
And the underlying problem is serious technical debt.
Again, this can be fixed in due time. If there is the aspiration to do so.
5. Not sufficient aspiration.
So, this ends up being the classic problem of leadership. How to...
a. Get them to see a common problem that they really want to fix, and
b. Get them to feel that it is not impossible to fix it.
Or...how to ask for something, but not too much.
So, earlier I have almost said that lame Scrum implementations arise, fundamentally, because of lack of aspiration. Either people don't see the possibilities or they don't want them enough.
I think Scrum holds a lot of potential. In every dimension of improvement that we want.
So, why is this not seen better? I think there is no one person to blame. We can all get better. The 'Scrum guys' (such as I am) can explain it better. The leaders can lead better. The teams can have more courage.
And the teams will have more courage in time, as they start to believe we actually really mean 'self-organizing' in a sensible way...that it is not just another of a thousand meaningless slogans.
Does this breakdown of root causes show you a path to action?
Subscribe to:
Post Comments (Atom)
4 comments:
Great post! I have found these points are common with lean or agile implementations. I think your last point is the most common reason for failure.
Thanks for you comment! Now that I think of it, #5 is essentially the same point that John Kotter makes in "A sense of urgency" and some of his other books. They have to really *want* to make the change.
Yes, my last one was ordered to imply that I thought (too) it was the most common (root cause).
Others have had similar thoughts about Scrum for sometime... Martin Fowler coined the wonderful term Flaccid Scrum, Allan Kelly asserts Scrum is inferior to XP, and I've stated that Scrum cannot work without XP practices under the hood.
Stephen,
I am not in love with the 'flaccid scrum' metaphor. Much as I like sex. An unthinking person could infer that Scrum is somehow 'not good enough'.
Now, you raise another good point. I will take your lead and call the issue this: "what is the minimum amount of initial change to start doing lean-agile?"
Now, I am a CST and I love and recommend XP engineering practices. I think some people try them and dismiss them much too easily. Some of them are 'hard' and have to be worked at and used sensibly. But, sitting here right now, I would recommend all of them that I can think of.
Still, to change some group, where would I start? My answer: Scrum. Then Scrum helps me prioritize my impediments. And then, hopefully in good priority order (well, as best we can see), we fix things. Meaning to a large degree: we implement XP engineering practices.
My argument is that if you asked a team or two to jump to Scrum + XP in one step, I don't think I have ever seen a team that could do that. Hell, I see way too few teams that can go to Scrum in one step.
Why Scrum first? Well, I think it does some essential things: iterations, demo, PO, SM, impediment list, working software, business-technology collaboration...to name a few.
Now, that 'Scrum' is identifying the biggest impediments means to me it is working. So, in that sense, Scrum works quite well without XP. If you want to say that the team cannot be successful with Scrum without XP... Well, my experience is that we want to put it more this way: The team will not appear to be successful with Scrum (in the normal way we use 'successful') until it has strong engineering practices and, in most cases I think, XP engineering practices are great.
So, I think you will see some differences of emphasis between what you are saying and what I said...but it is essentially the same thing. In most cases, Scrum + XP is best.
Thanks,
Joe
Post a Comment