concocting  extraordinary  teams

August 02, 2006

Process is Inevitable - Embrace It, Then Change It :-)

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!


Deborah Hartmann
Agile Process Coach

PS: I still use knee-pads... but not training wheels. Make of that what you will :-)


Anonymous Paul Oldfield said...

I like process. I like practices. The big problem with process and agility is that we find it hard to get beyond the idea that we should do each bit of the process each time.

That approach is appropriate where the practitioner knows zero or one way to achieve the immediate goal. As soon as he knows two ways, he has the option of choosing the most appropriate.

In my experience, people that have a defined process will still choose to work in the most appropriate way that they know how, unless the process police are there to enforce use of the defined process.

If we look at agile approaches, there are so few practices defined that there's plenty of scope to go wrong in the gaps, and no guarantee that the problem will be correctly identified and fixed when the safety net catches the project.

Yet as you say, even these practices may be too many for the advanced team.

It would be nice to make the rule that every team should have at least one person of 'Agile Coach' grade, but are there enough to go round?

Fri. Aug. 04, 10:48:00 a.m.

Blogger Dmitri Zimin(e) said...

>> ""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. ""

Deb, I think you hit a very important point here. SCRUM is not about the practices, and even not about the process, it is about the spirit of human collaboration and truthfullness. But as with all spirituality, one can't get it directly: the matters are too thin. The way we learn Zen, karate, or tea ceremony is through practice. Tea ceremony is practice, process, or even result. Filling yourself with tea is a side effect, "flowers on the side of the road". But we start with practice to capture the spirit. After that practice are not any more important.

Fri. Aug. 04, 03:06:00 p.m.

Blogger Deb said...

Paul, at least in Toronto, I'm available for hire! :-D

Fri. Aug. 04, 05:07:00 p.m.

Anonymous Paul Oldfield said...

Deb said...
Paul, at least in Toronto, I'm available for hire! :-D

Likewise for UK, preferably Scotland, I might be available ;-)

Sat. Aug. 05, 08:48:00 a.m.


Post a Comment

<< Home