Agile’s broad adoption and mediocrity – what to do

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.

First, I at least partly agree with Ken.  Broadness and Deepness need to be balanced. Just going broad, with no quality, may  hurt more than help.

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.  It probably alone, not done very well at all, can give a 20% improvement.

But it really takes an active, purposeful, spirited team to get real success. Now, we hope the magic of the Scrum stuff pulls them in, but they must also come in.

2. Need a 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.  But they always start as ‘beginners’ (at being a PO), so we all must actively help them improve.

3. No real Team.

The people don’t feel they are a real Team. And few seem to know 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 typically not aggressive enough in doing this. Or the company does not support it meaningfully.

This is often related to not having a dedicated ScrumMaster (in a Team of 7-ish) who understands his job is to drive the removal of impediments until the Team is the best it can be. (That is, all the time.)

5. Better Engineering Practices.

When switching to agile, a team needs to move to more agile engineering practices. 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?  [Note: In Feb 2012, the Giants won the Super Bowl.]  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 2011, 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 ways). They are not beginners in the sport, at all.  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 are 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. They are doing Scrum-Butt.  Not good.

***
There are other reasons.  Many more.

We need more teams playing Scrum professionally, and showing others how it really ought to be done.  Write your article about how your Scrum is pretty darn good.  I will help (I mean right now, with the writing).

 

« « Six Myths of Product Development || Release Planning: Effort (1) » »