Remember Calvinball? From the Calvin & Hobbes comic strip, the most important rule of Calvinball is that anybody can make up new rules for Calvinball. As a result, it’s never played the same way twice.
Great fun for kids running around playing outside, but what about adults cranking out code in large organizations? I don’t mean on a break–would you play Calvinball while actually working?
Absurd on its face, but today’s development teams play a bit of Calvinball whenever they purport to follow an Agile methodology like Scrum. Why? Because of the fourth principle of the Agile Manifesto: responding to change over following a plan. If you’re planning to follow Scrum, then that’s your plan. But to follow Scrum, you need to be willing to throw out the plan. In other words, you get to make up new rules as you go along. Calvinball!
If you don’t follow this Calvinball principle, then you’re not really Agile. But if you do follow it, you risk complete chaos. Chaos is fun on the playground, but it’s decidedly not fun in the cube farm. How do we get around this problem?
The solution is straightforward. Unlike Calvinball, with Agile we need to make up new rules within the context of the Manifesto itself. In other words, we must always focus on working software and customer collaboration–even when we change the rules. You may have already run into this situation, if you’ve ever dealt with Scrum Buts.
A Scrum But is a statement that follows the pattern “We use Scrum, but X so Y,” for example:
“We use Scrum, but Retrospectives are a waste of time, so we don’t do them.”
Or:
“We use Scrum, but we can’t build a piece of functionality in a month, so our Sprints are 6 weeks long.”
If your reaction to these statements is “without Retrospectives you’re not doing Scrum!” or “Sprints have to be four weeks long or you’re not doing Scrum!” respectively, then you’re not playing Calvinball properly. Remember, it’s OK to change the rules–as long as the result still focuses on working software and customer collaboration. The questions for you, therefore are: can you make the rule changes in the statements above while still maintaining the priorities of the project? And what additional constraints do you need to introduce in order to do so?
