ScrumButs Are the Best Part of Scrum

3 September 2009

Posted in Uncategorized

Many organizations in the world are adopting Scrum, and many of those are adapting Scrum. But the adaptation of Scrum is frowned upon by lots of practitioners, and Ken Schwaber even has a name for this "bad" practice: ScrumBut.

The pattern of a ScrumBut is like this:

Here is a shorter description:

ScrumBut = (practice not being followed)(logical excuse)(workaround)

There's even a definition for it:

scrumbut [skruhmbut] noun.
1. A person engaged in only partial Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenants of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"

Well, I like ScrumButs. And here's what I want to say to all ScrumBut-bashing zealots:

The But of Scrum is the best part. If you can't swallow that, you shouldn't be teaching Agile!

I believe an explanation is in order, so here we go…

Scrum teams are self-organizing complex systems. The behavior of any complex system is a function of its structure and its environment. A process or method is a description of behavior. It describes how a system should behave to be successful in its environment. Scrum describes how a development team might be able to successfully deliver software to its environment. But… because optimal behavior is a function of internal structure and external environment, the real optimal method always depends on the team's structure and environment.

In short: the optimal method will always be an adaptation…

Here is a quote I used in my talk at Agile 2009:

A project cannot be viewed independent of its surrounding context […]. An understanding of the context is in itself not sufficient to prescribe a method. Rather, the method to manage the project is embedded in the context and one must allow the emergence of such a method through interaction between the actors and the environment. [emphasis mine]

Pundir, A.K., Ganapathy, L. and Sambandam, N. (2007)
Towards a Complexity Framework for Managing Projects

When you believe that Scrum teams are self-organizing systems (which I do, and I know Ken Schwaber does too), then you must accept that optimal behavior of a team cannot be predicted. It is impossible to design the process up-front. It must emerge, just like the design of the solution.

And that's what retrospectives are for!

It's OK to say "We do Scrum, but we don't do stand-ups because there are only two of us, and we already communicate all day."

It's OK to say "We do Scrum, but we don't have a ScrumMaster because we decided to share this responsibility with the whole team, just like in XP."

It's OK to say "We do Scrum, but we don't do fixed sprints, because just like in Kanban we have a continuous flow of releases, and in our environment iterations make no sense."

Of course, I understand that there are organizations that adapt Scrum for the wrong reasons, making it half-Agile, or even non-Agile (part 1 and 2 of the definition above). We might call these adaptations negative ScrumButs. They make a team's performance worse.

But if you do your retrospectives well, they should lead to positive ScrumButs, making the team's performance better, which is great! It is the best part of Scrum! Scrum is a great starting point for many teams, just like XP and Kanban. But unlike those others (and thanks to continuous improvement through retrospectives) Scrum is the only method that is able to morph itself into XP+retrospectives, or Kanban+retrospectives. And back again!

But only if you allow and cherish ScrumButs…

(picture adapted from Mountain Goat Software)

Twitter – Subscribe – Newsletter – Bookmarks