It's time for Scrum to evolve

This week has seen a flurry of activity online concerning the current state of scrum, it's flaws, and if it should be changed.

While criticism online of a particular method is nothing new, more attention has been paid this week when Uncle Bob listed 8 issues that he had with scrum...

1. No technical practices. Scrum is great at giving project management advice,
but provides no technical help for the developer. Any good implementation of
Scrum needs to borrow technical practices from some other method like XP. The
suite of technical practices that should be added probably include: TDD,
Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.

2. 30 day sprints are too long. Most scrum teams have either shrunk them to 2
weeks or perform some kind of midpoint check at the two week mark. I know of
some teams that have two 2-week "iterations" inside a single 4-week "sprint".
The difference being that they use the sprint for reporting upwards, but use the
iterations for internal feedback and control.

3. The tendency of the scrum master to arrogate project management powers. This
is not a problem with Scrum out of the box so much as it is a problem with the
way scrum sometimes evolves. Perhaps it is related to the unfortunate use of
the word "master". Perhaps the XP term "Coach" might be a better word to use.
In any case, good implementation of scrum do not necessarily correlate scrum
masters and project managers.

4. The C in CSM is unfortunate. Again, this is not so much about scrum out of
the box as it is about the scrum community. That letter C has gotten far too
significant for it's intention. It is true that the people in a scrum team need
to be trained. One of the things they should be trained about is the role of
the scrum master. The problem with the C is that it changes the notion of scrum
master from a role into a person. It is the person who has the C. In an ideal
case, the members of the scrum team will rotate through the scrum master role
the same way the members of an XP team rotate through the coach role. This
rotation is never perfect, and sometimes the role sticks to one or two people
more than others. But the idea was never to raise up a particular person with a
rank. We never wanted that C emblazoned on their chests.

5. Scrum provides insufficient guidance regarding the structure of the backlog.
We've learned, over the years, that backlogs are hierarchical entities
consisting of epics, themes, stories, etc. We've learned how to estimate them
statistically. We've learned how and when to break the higher level entities
down into lower level entities. Epics->Themes->Stories->Tasks.

6. Scrum carries an anti-management undercurrent that is counter-productive.
Scrum over-emphasizes the role of the team as self-managing. Self-organizing
and self-managing teams are a good thing. But there is a limit to how much a
team can self-X. Teams still need to be managed by someone who is responsible
to the business. Scrum does not describe this with enough balance.

7. Automated Testing. Although this could be considered a derivative of point
1, I thought it worth calling out as a separate point because it is so
fundamental. Scrum doesn't mention this, yet it is the foundation of every
agile effort. Agile teams work in short cycles because feedback only works well
in short cycles. But short cycles aren't enough. You also need objective
measurement of progress. The most reliable way to know how much a team has
gotten done is to run automated tests and count the tests that pass.

8. Multiple teams. Scrum has little to say about the coordination of multiple
teams. This is not a failing unique to scrum. Agile itself is virtually silent
on this issue. Scrum talked about the vague notion of a "Scrum of Scrums" but
that idea really hasn't played out all that well. Scrum-in-the-large remains in
the domain of certain consultants who claim to have an answer. There is no real
consensus on the issue.

Agile blogger Mike Cottemeyer have waded in stating that the concept of an Agile PO needs to be significantly rethought, and Alan Shalloway of Net Objectives has long maintained that Scrum (and other agile approaches) have long suffered from it's overty developer focus, and anti management bias. Alan has stated that extending scrum with lean/kanban can go a long way to make scrum significantly mire successful.

Jurgen Appelo has come in swingng to the defense of scrum, saying that a lack of technical practices is a strength, not a weakness as it allows scrum to be applied to other professions beside development.

For my part I am firmly with the critics on this one. Let me start by saying that I think scrum has some great things in it. The management practices are a good way for teams to get started down the road to becoming more agile. Simple things line retrospectives and standups reallly help noobs understand what agile is.

But that's is where it ends. Scrum is so simple and incomplete that it does not adequately serve it's target audience appropriately. It's fine to say that scrum is meant to serve multiple audiences, which is great in theory, but let's look at reality, the vast majority of scrum users are developing software. They are not graphic designers or painters or management consultants. I've seen teams get into serious trouble with flaccid scrum, ie no technical practices, because they thought they had what they needed. In reality they were worse off than the previous waterfall state. No documentation, external qa, but no CI or TDD, what a mess.

Scrum practices also come off as being a little naive and almost condecending to teams with even a little emotional intelligence. Rules like chickens can't speak (ie managers) at certain meetings and the notion that developers only have to deal with product owners seem like an extension of many of the spoilt developer attitudes that came out of the dot com era.

I actually think for agile to be successful teams need to take scrum practices and mature towards Lean an kanban. The language is more mature, and you can use more sophisticated but still simple tools to better model and manage more complex situations than one team serving one product owner.

Finally I think for such a simple approach scrum is a little dogmatic about what you have to do. Again this has to do with maturity, beginners might need to be told exactly what to do and who can talk in a stand up meeting, but teams that move a little bit up the maturity curve quickly find this kind of advice pedantic.

I won't even get into the whole certification fiasco, which to me is a complete joke.

So in conclusion I think owners of scrum need to take a look at this criticism and seriously consider how they can incorperate public feedback into improving scrum. This is critical if we are to continue to take scrum seriously.