Ken Judy has an excellent, although blunt, blog post here:
http://judykat.com/ken-judy/agilescrumlean-broad-adoption-mediocrity-faul/
His main point maybe is that we do not have enough truly professional scrum (or agile) implementations.
And why? Because we have implemented too broadly too fast. Is probably the main reason, in his opinion.
Some good insights. Read them.
***
Here are my related thoughts.
The potential of a team using Scrum is enormous. And I don’t think any team, ever, reaches their full potential. In any sport, including what we call Scrum.
It is fair to say that most teams barely scratch the surface of their potential. They get a 20% improvement when they could easily have gotten 100%. And eventually get 5x – 10x.
Why? Some root causes…
1. Reliance on “Scrum”: Too many teams have a ‘sit back’ attitude and expect Scrum magically to do all the work. And it is amazing what Scrum alone can do. But it really takes an active, purposeful, spirited team to get real success.
2. Better Product Owner. Scrum will not magically make George (a really smart guy in your firm) a good product owner. In fact, all Scrum does is make us assign him that title, and then gives us lots of ways to observe, if we will, that he sucks at the job. Hopefully, someone sees the problem and fixes it. It really really helps to have a really really good PO.
3. No real Team. The people don’t feel they are a real Team. And no one knows how to form a real team. (Lots of explicit and tacit knowledge in doing that. We will talk about that later.)
4. Not attacking impediments. One of the most powerful things in Scrum is that single-piece flow of attacking one impediment at a time. The Scrum team is not aggressive enough in doing this. Or the company does not support it meaningfully.
5. Better Engineering Practices. When switching to agile, a team needs to move to more agile engineering practices. No, not for the silly reason that agile is in the name. Because the agile engineering practices are more effective. Probably more effective even if doing waterfall, but certainly when doing agile. SCM, automated build, CI, automated UT, automated functional tests, faster regression testing, etc, etc.
6. Scrum-Butt and Unprofessional Scrum. Do you think the NY Giants should have fired all their coaches in Sept 2011? Me neither. Yet, somehow, many people magically expect that all a team needs is one 2-day course, and then they can play Scrum professionally. Remember that at the beginning of September, every player on the Giants team has been playing football for years. At what you and I would call a professional level (college is virtually professional in many way). They are not beginners in the sport, and they need further coaching. Further training.
And we think people who are beginners at Scrum need only a 2 day course? C’mon. They need a lot more. Now, of course it has to be reasonable compared to the value. If you need help with that math, I can help.
Related, but a bit different, is how beginners (or beginning firms) are so sure they are smarter than the Scrum community, which now has many centuries of experience with Scrum. So, they change Scrum (‘we are special,’ they sometimes say). They do Scrum, but people on more than one team. They do Scrum, but they do the Daily Scrum twice a week. They do Scrum, but they don’t have working software at the end of every Sprint. Etc. Etc.
***
There are other reasons. Many more.
We need more teams playing Scrum professionally, and showing others how it really ought to be done.
