On the Road to Agility Fair
First published in The Agile Journal, 4 May 2011
The path to Agility, like the road to damnation, is paved with good intentions. First among these is the valuation of people and their variable needs over the strictures of definitive process.
All four of the values expressed in the Manifesto can be seen to align to this tenet. Each of them reminds us to look beyond process so we don't lose sight of what people actually need. A velvet revolution against faceless bureaucracy, Agile Methods are a thesis for humanity in this technical world:
1. Individuals & Interactions over Processes & Tools
2. Working Software over Comprehensive Documentation
3. Customer Collaboration over Contract Negotiation
4. Responding to Change over Following a Plan
The problem is, once people become central to our methods - once the sprawling, brawling mass of that very humanity starts to directly drive our thinking - we lose the benefit of detachment. Barking orders from atop a structured process framework might score low in the touchy-feely stakes, but at least it keeps someone above the fray and whose perspective will range beyond the mire. It's worth noting that even rugby teams can have their managers on the sidelines. And you'll notice they keep well out of the scrum.
Let's stop awhile, and ask ourselves the old question, just for amusement: "What are the managers doing?". Well, let's look at what the team is doing, and then at what they aren't. We can see that the team are delivery focused. They are making the moves, passing the ball onward across the field of play. Their vocabulary is clearly of immediate action, of operations and tactics. They don't seem to be thinking much about strategy, but they may occasionally remember that somebody else is...the manager. Does your Agile team remember that, and value it? The deadliest "Agile Antipattern" is the assumption that if operations and tactics are handled well, then strategic planning becomes unnecessary, or will somehow take care of itself.
And strategic planning isn't even half of it. There are all sorts of management activities which an Agile team doesn't - and shouldn't - get involved in, but which somebody else has to. Project inception; role appointments, contract negotiation (yes, it still happens, if you want to be paid), liaison with other stakeholders - the brawling, sprawling mass of humanity that isn't even on the pitch - all of this and more is the remit of managers. It means that the stakeholders who are on the pitch - i.e. the team - can get on with the "fun" part of playing, but without dealing in the "fluff" which so often bores them.
In short what we have are a wide range of personality types, each with their own vision and values. There are the team players who are hopefully focused on the game, and there are the customers who may never meet them. There are the product owners who are the point-men for requirements, the coaches who promote intelligent application of the rules, the testers who sometimes appear to be playing for a different side altogether, and the managers who join it all into a functioning whole. It's a Vanity Fair of participants. Each may think that he or she is the most important and indispensable, but they would all do well to remember that the game extends beyond their immediate vision, and to recognize the value in the greater scheme that may, just possibly, be provided by others.