When it comes to agile methods, almost everyone agrees that agility can apply to the software development team and to the organization within which a software development team finds itself. Some people will also argue that agile methods are applicable to organizations that don't develop software, but that's a discussion for another forum. This raises some questions: To what extent can the one be separated from the other? Can an agile team succeed if the organization around them doesn't wish to adapt to an agile approach? To what extent does the organization's resistance to agile methods affect the success of a team? Should agile methods focus on the the team or the organization to the exclusion of the other?
These questions are not new, but they are of particular relevance now, when the Agile Alliance is looking at ways to refocus itself and has suggested it is considering focusing on the agile team:
The Agile Alliance should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.
The threads Brian Marick set up on agile forums for the 'pro' argument, the 'con' argument and the associated poll have attracted some attention, as has the definition of team success. Laurent Bossavit speaks up for an agile-team focus:
I'd be happy with an AA focused on the "front-line" folks. And, whenever the AA is concerned with how things are working out between the "front line" folks and the rest of the business, I would want the AA's mission should be "to help the software development people engage and align with the business".
For Scott Lilly, this seems to be a black-and-white issue:
"localized optimization = no optimization"
Others believe this is best tackled holistically, such as Paul Oldfield:
Change works best IMHO and IME when there's top-down and bottom-up change, at the same time and both working toward a shared vision.
I believe the effectiveness will be considerably more than twice the effectiveness of doing just top-down or just bottom-up alone.
This discussion has also spread into blogs. George Dinwiddie seemed to have mixed emotions when he argued that the two concerns may not be separable, but that APLN's focus on the organization may allow the Agile Alliance to focus on the team. Another sideways look at Agile suggested:
But there's no Agile without active and enthusiastic business participation. Which leads to a problem ... many organisations find themselves at a pretty pass, a singularly vicious circle. They don't believe in their IT departments because they "don't deliver". The departments don't deliver because the requirements are unstable and hard to articulate. To solve this they need to think and act Agile. This requires them to trust their IT folks. But they don't. Because they "don't deliver."
Although some have already raised their voices elsewhere the discussion has been muted. The InfoQ Agile community is a large and vibrant community which can contribute to this discussion. We'll be asking a few members of the agile community as a whole large to join the conversation, but most importantly, we've asked you:
- Can the concerns of the agile development team and the agile organization be separated?
- To what extent are they separable, and to what extent does the success of one depend on the other?
- Should the Agile Alliance focus on the Agile team and leave the agile organization to others such as the APLN?