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:

• They are not managing the 'group think' that arises from teams that bond and look inwards rather than outwards.

• They see their team as the 'agile' team surrounded by a hostile, non-agile or problem environment (reinforcing the group think and introversion).

• They fail to realise that feedback loops need to be in place between all the suppliers/providers and themselves, not just in the ways drawn out in the XP book - i.e. they just don't get the feedback part.

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:

• they haven't figured out how to adapt their external facing image to the needs of the host.

• conversion... sounds awfully religious to me (slightly tongue in cheek).

• The projects that later get taken down don't deliver busines value so their going in position, that the agile model they established would deliver business value, was probably mistaken - or at least its naive application was.

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.

Andy S