A fellow agilist asked a question about Scrum and process - wondering why an Agile methodology would be rather rigid about basic practices. Here is my answer, from the ScrumDevelopment yahoo group:Re: Are SCRUM and XP actually Process Oriented?Hi Vicky.
I do not think we need to divorce the term "process" from Scrum. However, Scrum is not, in my mind, "a process" but rather a way of thinking about process.
Alistair Cockburn's point in Agile Software Development (well, he probably made more than one point, but the one that seemed to start it all rolling :-) is that in his research, successful teams generally were not doing what they "thought" their process "ought" to be. In fact, their process really was whatever they were actually doing. People working together have process. People working with Scrum have process. It's just not *defined* process.
I think what keeps me sane as a Scrum coach is this: Scrum reminds us that this process belongs to us, and teaches us tools for making it better over time. What Scrum does prescribe is an *empirical approach to process*: decide what to do, do it, inspect the results and reflect on them, decide what to do next...
In my understanding, the empirical approach requires that some things be held *constant* while others are varied, to allow us to measure results and draw conclusions in relation to what went before. To allow this, Scrum Masters teach a set of practices which have worked well for many teams, and suggest that, at first, teams hold these practices constant while they observe the effects of all the other variables - personalities, politics, room layout, hardware, and especially the elusive "self organization" that must take place in the interstices intentionally left between these few recommended practices.
If everything is varying, there is no basis for comparison, and the team is back into ad-hoc-ism, or perhaps chaos.
I would call a team a Scrum team if it uses the basic Scrum practices, or can explain why they don't use them and how they have compensated for their absence. Imho this latter kind of explanation requires an understanding of process patterns and subtleties that novices are not likely to see, being caught up in the maelstrom of the paradigm shift. So I'd expect a new team to use the basic practices for many iterations, while they learn the real patterns of Scrum, which are not about the practices at all, but about values and thinking and collaborating and truthfulness. In fact, another name for these patterns might be "common sense" or "wisdom"... For many of us, Scrum is an attempt to teach a return to common sense.
I'm very visual: I think the practices must be practiced in a "wax on, wax off" manner for a time, to allow teams develop "process improvement muscle" while the underlying truths emerge. (do you know the film Karate Kid? :-)
So, yes, there are a few rigid aspects to Scrum for beginners - consider them training wheels, or roller-blading knee-pads. As a coach, I see that there is a time for these, no matter how frustrating. If teams were not frustrated over the practices, they'd be frustrated over something else. In fact, they probably were, before we began Scrum. It's human nature.
When teams whine, I ask them: do you think you know enough about Scrum to understand the implications of removing this practice? Do you know why it is there, and how to compensate for its absence? If not, I recommend they continue with it for a while and focus on changing something else.
Best of luck in your Scrum adventures!
deb
Deborah Hartmann
Agile Process Coach
CSM/P
Toronto
PS: I still use knee-pads... but not training wheels. Make of that what you will :-)
