Scrum doesn’t do anything

Brilliant post!


“Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class.  Scrum is a framework for surfacing organizational dysfunction.  It is not a process and it is not prescriptive.  The core framework of Scrum, as described (e.g.) here and here does not actually do anything.  It is, in a sense a contract we put in place between those seeking value and those building it.  But a contract doesn’t produce anything.  An interface is passive.  We need an implementation.
Scrum begins to work when people understand it well enough to create a concrete implementation, to emerge a process that is their own.  Understanding and respecting the Scrum framework and the set of rules allows you to become aligned with others, to have a common set of values and principles from which to operate.
Scrum itself can be thought of as similar to a set of game rules.  Think chess, think soccer.  The rules are easy to learn, and knowing them means you can play the game with others.  The rules are the ties that bind us together.  But just knowing the rules means nothing in terms of deriving pleasure from the game.  You need to play, to be involved.  It is doing, not knowing that brings about results.  To play well you need to develop strategy, and in team games you need to develop relationships, and trustful interactions.
In any game, once you start breaking the rules everything falls apart, and no one will want to play with you.  It is the same with Scrum.
So respecting the contract, the rules, or in software parlance, respecting the interface, allows you to create a process that suits your context — and your context is many things… people, industry, business, market place, product, location, language, physical environment, culture, people.  It starts and ends with people.  Scrum doesn’t actually do anything, people do things.  The Scrum process will emerge through the interaction of the people, and it will be different for each organization or team.  And this is where people trip up; too many think that creating their own process starts with breaking the rules.  It doesn’t.  Do that, and you have failed before you begin.
The Scrum process being created must operate within the agreed parameters, must be bounded by the rules.  All methods of the abstract class must be implemented, or the class won’t compile, won’t run.  Try to move your bishop in a straight line in a game of chess, and your opponent will leave the table.  Pick up the soccer ball and throw it and you’ll be red carded.
The framework of Scrum is a powerful mechanism for surfacing organizational and personal dysfunction.  It is that very power that causes people to try to circumnavigate the rules, to take shortcuts.  They don’t want to look.  But not looking doesn’t cause problems to go away or broken things to mend, it just delays the inevitable giant crash.  We don’t call out the value of courage in Scrum for nothing.
Comparing Scrum then to implementation practices such as XP or software craftsmanship makes little sense.  Each of these movements offers excellent tools for implementing a solid Scrum practice, for making the abstract concrete.  Scrum offers a strong framework and a relentless rhythm to shake out the dust of years.
You cannot “do Scrum” but you can certainly embrace it, and the more courageously you do so the stronger will be your emergent process.

From http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/