Rachel Davies recently needed to step down as chair of the board of the Agile Alliance. I’d proposed the following in response to my disquiet over the state of Agile as it moves into the mainstream, so someone suggested I run for chair on a platform of carrying it through. I did, and I was elected. I’ll be chair until August, and I take it as my responsibility to bring some derivative of this to a vote of the membership. We’ll be working on this proposal at the Agile Software Development forum. Help out, please.
Proposal for the refocusing of the Agile Alliance
Whereas the main problem when the Agile Alliance was founded was making Agile a respectable choice, now the problem is that teams are not ready to execute Agile,
Whereas many team members are weak in the basic skills and need to learn them, many others are fluent at the state of the practice and want to improve it,
Whereas Agile software development comprises a constellation of crafts that beckon toward excellence,
Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful,
Whereas the Agile Alliance has a cash surplus, one that exceeds the amount needed by programs created under its current structure, and
Whereas the Agile Alliance has never successfully engaged with higher levels of management or businesspeople with major funding authority,
NOW, we declare that the Agile Alliance should be refocused as follows.
It should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.
“Members of the Agile team” is defined to be everyone who’d be expected to attend a team standup meeting: programmers, testers, user experience designers, Scrum product owners or XP Customers, technical writers, and so on.
“Succeed” means that (a) team members love their work, (b) the business both considers its money well spent and also sees the current version of the software as a readily-tapped reservoir of potential value, and (c) the software is so good that team members bore people at parties describing how easy it is to change, to push builds to production, to debug, and so on.
After Agile2007, conference attendance no longer entitles the attendee to Agile Alliance membership. New memberships and renewals require both payment of dues and also a verifiable claim of a contribution to the Agile community. (“I’m a committer on CruiseControl.”, “I brought pizza to the local user’s group twice this year.”, “I gave money to the Apache Foundation.”, “I donated these three books to the local community college’s library.”, etc. The size of the contribution is not important; it’s the fact of a contribution that is.)
The Alliance will fund small conferences, run by volunteers, targeted toward experienced practitioners, dedicated (in part) to advancing the practice. These conferences are expected to lose money. We hope to fund at least five conferences a year, in at least three continents. The Agile Alliance will choose conferences to fund based on bids by groups of volunteers. In addition to funding, it will provide logistical support.
In software projects that justify a long-term investment, we believe Agile development aligns the interests of the team with those of the larger business. The business sees the product’s realizable business value increase each iteration, in an order chosen by it. The need to keep delivering running tested features at frequent intervals forces the team to improve their craft.
But let’s not kid ourselves. Businesses don’t make decisions; individuals within them do. Sometimes those interests are contrary to the interests of our members, whether because the decision-maker lacks knowledge, has a command-and-control personality incompatible with Agile, is maneuvering through a power struggle, etc. While the Agile Alliance is not a union, it will intervene on behalf of members, whether by providing a supportive outside voice, aiding exiting employees in job searches, removal of a company from a list of known-good employers, other methods we haven’t thought of yet, or any combination of the above.
We will spend down our surplus by soliciting requests from Agile user groups and (secondarily) other groups that contain Agile Alliance members. Preference will be given to proposals that benefit a local user group. Benefit to the larger community is a secondary criterion. The goal for the first year is to spend half the surplus. The goal for the next year is to spend the rest, less expenses for ongoing operations created during the first year or carried over from the current version of the Alliance.
Existing programs will continue to be funded under the existing model. New programs may be started under that model.
At the end of the second year, there will be a careful evaluation of whether the Agile Alliance has, in fact, improved the success rate of Agile teams over what it would otherwise have been. The evaluation will include people in the role of Devil’s Advocate. Unless the evaluation concludes that the Alliance is making a substantial difference in the world, the Alliance will disband, distributing any remaining monies to user groups.