Musings on project management: Agile is a process -- or not?

Friday, September 12, 2014

Agile is a process -- or not?

First, the agilists tell us that they are not slaves to process, like their traditionalist brethren are. Agilists are free! And then they tell us that you must, must, must:

Release something every two weeks, or four at the outside
Have a daily stand-up of no more than 15 minutes
Have a retrospective meeting at the end of every iteration
and, so on....

And, they tell us, these are not processes but rather practices. A process, after all, has protocol, input, controls, and output.... and these don't?

Nonsense. Agile has process like every other methodology; they may be shorter in duration but they are processes nonetheless

Now comes a really radical idea into agile land: Let's do away with these processes and really be free! No less an eminence than Mike Griffiths, an independent trainer and consultant who is steeped in PMI ACP stuff, who blogs at Leading Answers, has given us this wisdom:

It's not the process, stupid!

Here's the core of his argument:

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

Sense making – agree information gathering steps and prioritize exploratory work

Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting

Consensus gathering - collaboratively gain consensus on direction, approach and decisions

Prioritization – build mindful to risk reduction and business value

Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates

Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings.
Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail

Did you read that last point? That's a biggie!

The typical advice is do pilots as the training vehicle... Fine, I agree with that. But Griffiths might say (though he didn't) that the purpose of the pilot is not to train on the process but to train on the ideals and principles as listed above.

Fair enough.. But CAUTION: this stuff DOES NOT SCALE. If you have a few teams of really good people who work well together, Griffiths is probably spot on re doctrine, though I'll be even these teams migrate toward process they define for themselves and work for them.

But, if you're working at scale, you probably need look towards what Kent Beck did when he invented XP: practice and process discipline! Toe the line!

I see this issue in my Agile classes repeatedly as students tell me they intend to trade process doctrine for freedom, whereas what they mean is that they are going to trade traditional process doctrine for a more agile doctrine. For newbies, that's probably a good strategy.