Sun, 12 Sep 2004
Andy Schneider had some interesting comments on my cybernetics post. I'll comment on his comments after I get through various pressing business. The rest of these words are Andy's, reprinted with permission, except where he's quoting me.
I've worked on a bunch of broken and working agile projects and when I was reading your missive it kept taking me back to stuff I've observed.
I'm picking the bullpen as the unit of adaptation because I want to talk myself out of the notion that everything that matters is in the heads of the team members - some of it is "in" the configuration of the room, the Big Visible Charts, the source code, the Lava Lamps, the rituals that people take part in and the rules they follow and reinterpret...
When I read this I read the 'team' as the development team, the people cutting code and probably the customer representative. The definition is very dev centric (BVC, Lava Lamps, source...). When teams buy into this perspective I think they are already in trouble. These teams are often have the following traits:
The best agile people I see working view the team as encompassing people involved in the end to end process. Furthermore, they view agile as part of a multi-paradigm approach to the entire constructin process rather than as the proverbial hammer. I do a brief and not very profound short talk in scaling agile and I spend 50% of it ramming home the need to make business engagement work and the other 50% discussing how you dovetail your agile dev team into the corporate environment in a way that is acceptable to all. In my mind these are two key cornerstones to an agile project, often missed in the rush to pair programming, lava lamps and A3 charts on the walls.
You then go on to say:
...and others appalled by how often successful-in-their-own-terms Agile projects get taken down by organizational struggles and interests are trying to figure out how to convert receiving organizations into something Agile enough to really use their Adaptive Bullpens well.
The fact the Agile projects believe they need to convert other parts of the organisation suggests a few things:
The fact that some people are even defining success 'in-their-own-terms' seems a bit of an issue with an organisation where success is probably defined in very different ways.
Of course, it can be argued that true success can only be achieved when the entire business is agile, but I think that's an oversimplification. Whilst some agile projects may be too passive, I have found many are too introverted and focussed on the 'one solution'. What we really need is not the establishment of agile development teams with a 'customer on site' but the realisation that agile is an approach, that needs to be tailored to the host environment and that must be driven by people who see the 'team' as the people in the end to end process chain, not just dev and the customer rep. Let's break down this insularity and start to see the bigger picture.