August 06, 2011

The organizational mindshift of Agile

Quite often, adopting Agile requires organizations to change more than expected, and sometimes more than the organizations are willing. I don't think that organizational leaders understand that Agile is not a set of practices or tools from which they can pick and choose, instantly transforming them into an 'Agile Organization'.

Instead, Agile is a set of values; often the values are foreign to those the organization has long held. Embracing these values requires adopting some new practices and tools, for certain, but it must be the values driving the change, not the tools.

I listened to an episode of the Agile Toolkit Podcast the other day, in which host Bob Payne and Kelly Allan discuss Agile and its relationship to W. Edwards Deming's management teachings. At about the 12:00 minute mark, this exchange discusses how much change an Agile transition demands from a traditional, conservative organization:
Kelly - Agile, I think, will help drive even more of Deming's thinking into, and I hope will drive out a lot of the prevailing notions of management as it's practiced. 
Bob - Yep. 
Kelly - So, what do I mean by that? In part, certain practices like pay for performance and performance appraisals, incentives and rewards and driving in fear and management by quota and management by results and these kinds of things, have no place in the Agile world. Agile rejects that.
Bob - We try.

Kelly - Yes. The rest of the organization, of course, is still stuck in that old management model. So Agile picked up all those things by - so, for example, Deming calls the annual performance appraisal one of the 'deadly diseases' that he lists. His eighth point is 'drive out fear from the organization'. Because if there's fear in the organization, you tamp down innovation, you tamp down experimentation, you tamp down new product development.
Those words, "they have no place in the Agile world", are pretty strong. And I agree with them. But I don't think many business leaders understand how strong the Agile values are when they say they're ready to transition to Agile. What they are wanting is to change a few things here and there, holding their core (often anti-Agile) values steady, and claim victory. They expect software to somehow get built better and faster, as if through some sort of magic applied with the Agile label.

In reality, the management practices of the past are simply dressed up to look like Agile, and continue to be applied as before. See, change is not so hard!

In his book The Art of Agile Development, author James Shore has this to say about the common practice of reporting time usage to management:
If the project is under time pressure - and projects usually are - stakeholders may want to know that the team is using its time wisely. Often, when the team mentions its velocity, stakeholders question it. "Why does it take 6 programmers a week to finish 12 days worth of work? Shouldn't they finish 30 days of work in that time?"
Although I prefer that stakeholders trust the team to schedule its tasks wisely, that trust takes time to develop. In the beginning, I often produce a report that shows how the programmers are using there time. This report requires that programmers track their time in detail, so I stop producing it as soon as possible, typically after a month or two.
In other words, this report, which has probably been a staple report for the organization over the years, is foreign to Agile, which values trusting your team over requiring the team to track time.

To the Agile mind, this time-tracking is waste, as it doesn't lead to working software; in fact it delays the working software. In the Agile point of view, this waste shows that the organization's Agile implementation is broken, and Agile itself demands that it get fixed.

An organization that isn't ready to consider that these practices and processes are broken, that isn't ready to consider rejecting them as Agile does, is simply not ready for Agile.