Help me stir things up
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.
May 21st, 2007 at 6:50 am
Brian, thank you for opening this discussion.
In an earlier post, you quoted: “…one of the advantages of Scrum is that it has rules. When, for example, a executive wants to take aside a programmer for a special project, the Scrum Master can depersonalize the conflict by saying that The Rules say that means blowing the sprint, and does he really want to do that? It’s a shame the code internals have no such protection.” I thought about this and your recent suggestion to consider “Skill, Discipline, Ease, Joy”.
How about “building outwards” from the much-discussed XP team / code-as-design aspects of Agile, and treating some wider system concerns in detail?
In which:
* skills may include gathering and expressing how much and how well a solution needs to satisfy critical aspects of the problem area
* disciplines may include regularly estimating the potential contribution of “what to do next” against those critical measures
* ease may come from a team organisation in which these wider skills and disciplines are the main responsibility of say a product manager or some new role
* joy may come from satisfying a wider group of stakeholders, in which the system solution is more than the software being delivered
Although some online discussions of “agile management” and “lean” mention these areas, I feel that there may be room for a more rigorous treatment.
It could be that some rules emerge, from a somewhat technical direction, that are as powerful as Scrum’s “blow the sprint” rule.
I imagine that such rules could “protect” the most important areas of the solution-being-developed and system-being-improved.
regards,
Bob.
May 21st, 2007 at 10:25 am
To clarify: “how much and how well a solution needs to satisfy critical aspects of the problem area”
By “critical aspects” I mean in addition to features (which are amenable to repeatable, executable tests); operational aspects like:
* performance under load
* reliability in normal configuration
* security
* ease of training and use
I imagine that such aspects are measureable, with known current values and acceptable minimum values for the development in progress.
Am I dreaming?
regards
Bob
May 22nd, 2007 at 9:41 am
I’m not quite sure what you’re getting at. Let me restate and see if I’ve understood.
1. “When this happens, the software should do that”-type requirements are well-understood now.
2. So-called “nonfunctional” requirements like performance are not.
3. We are also weak in knowing how to ask for and how to deliver complete *systems*, as opposed to the software components of such systems.
4. That would be a good thing to focus on.
May 22nd, 2007 at 10:16 am
I think security presents a particular challenge here. First, there isn’t really a good quantification for security, and we’ve been tyring to come up with one for over 30 years. Furthermore, the primary standard for measuring system security is the “common criteria”, which is steeped in the waterfall. I would definitely be interested in seeing the proceedings if the security community leaders and the agile community leaders were to sit down and try to reconcile their definitions of “good software”.
Another challenge is that when thinking about security, one usually defines a feature in terms of what that feature doesn’t do, and the agile community (and really most of the software engineering field) tends to define a feature/behavior almost entirely in positive terms. I’ve been trying to reconcile these perspectives when applying agile processes in my shop, and the results have been truly mixed.
One thing (competant) security people almost all agree on: you can’t bolt security onto an app right before you push it out the door: you have to think about it up front. I would be interested in hearing some stories from agile teams that attempted to write security into their stories up front.
May 22nd, 2007 at 10:16 am
I have a more positive outlook on the state of Agile, since here in Denver I’m seeing new teams succeed with agile. I like these ideas. I don’t see any reason for the Agile Alliance to have a big surplus (and I don’t understand some of the decisions around Agile 2007 given that information). I have always wanted the Agile Alliance to give money to people at the real grass roots, in small amounts but large enough to do some good. Our local user group could benefit from having $200 to rent a place to meet so we can have a meeting when we don’t have a sponsor. We’ve also talked about having a local one day conference, and having some funding from AA would help motivate that.
We just started a very localized agile user group, just for the Denver DTC area, and found it is a great forum for agile teams of various levels of experience to share ideas. I think the more local you go, the better. Think globally, act locally!
So, what exactly do you want us like-minded people to do? I’m not much good at wordsmithing a declaration, but I’m good at stirring things up.
– Lisa
May 22nd, 2007 at 11:17 am
1. “When this happens, the software should do that”-type requirements are well-understood now.
Yes.
2. So-called “nonfunctional” requirements like performance are not.
Not often available or discussed as early as they could be.
3. We are also weak in knowing how to ask for and how to deliver complete *systems*…
In which individuals and interactions are part of the system.
In which the expression of “nonfunctional” requirements should allow us to measure - whenever needed - the level to which our system is suitable.
I imagine that warm feelings (ease?) may occur, as when modifying software in an environment with automated tests.
4. That would be a good thing to focus on.
Yes.
regards
Bob
May 22nd, 2007 at 2:10 pm
I’m in. As a practitioner I would be pleased to stir things up. This is not to say the the Agile community isn’t a collection of Stirring individuals, but the ferocity and the intensity seems to have been diluted as more and more people ’see the light’.
My concerns are the dogmatists, slackers, and cookie cutter seekers will attempt to ossify what it is we do.
May 22nd, 2007 at 2:48 pm
[…] Exploration Through Example » Blog Archive » Help me stir things up 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 […]
May 23rd, 2007 at 7:44 am
My overall suggestion is to widen Agile’s scope rather than aiming to spread its current area of interest more widely.
Expand into “system engineering” territory?
(I commented here once again, after reading the ‘context-driving’ post - and being unable to comment there, by some quirk.)
regards
Bob
May 23rd, 2007 at 8:59 am
I think that there is an argument to widen the the scope of the agile alliance. I think that there is a basis for examining the underlying skills of all stakeholders who wish to undertake agile projects. Not only are we asking individuals to work in new ways technically, we are also asking them to communicate in very new and different ways. The success of an agile project, IMO lies as much in the team’s dynamic and communication skills as in the project management of the technical side of things.
By highlighting a more holistic aproach to agile implementation, all tems would have a greater chance of success.
May 23rd, 2007 at 7:08 pm
I certainly agree that things like team dynamics are important. I see them as within the scope of my proposal.
May 23rd, 2007 at 11:19 pm
I think everything proposed is fine except element 6 with respect to disbanding. I think two years is far too short - Agile is likely to have to wait for an entire generation to clear their desks and be replaced by people who want to do Agile. Also, one of my basic dictums is “Continued existence is the surest form of ensuring goodwill” which means, in this case, if the Alliance is disbanded, it will have wasted any public outreach earned if ever in the future it is decided to start it up again. Also there is the oddness of running a campaign that espouses that if you are ineffective you will quit - people are not motivated to vote for quitters even if it is a rational thing to plan for.
May 24th, 2007 at 7:24 am
What I want is the urgency and focus that deadlines bring. But you’re right. There ought to be a better way. What?
May 24th, 2007 at 8:49 am
Ideas:
* Have a two-year-long initiative on a broad “people” or “communication” aspect of Agile, and report business benefits
* Start another one next year, to overlap, aiming to extend the “reach” of Agile
* Support a few shorter but more technical “proof of concept” actvities, to extend the scope / “applicability” of Agile
* Over the next 18 months, plan for succession and ongoing leadership, so you can take a break from it :-)
regards
Bob
May 27th, 2007 at 9:39 am
One of the things I have found by talking to people on different ‘agile’ projects is the
overall misunderstanding of ’systems thinking’. It’s been mentioned above, but I have found
that the emphasis by many ‘new’ agile teams is on individual components rather than the system.
Sometimes what new teams need is just someone to help focus them and provide some feedback.
Could one of the things the Agile Alliance helps with is sponsoring an agile coach to new teams
or at the very least provide a list of names of people in their neighbourhood that could help them?
June 1st, 2007 at 7:08 pm
[…] been some discussion of my proposal to change the Agile Alliance. The proposal will have to be modified, but a lot depends on people’s opinions about the […]
June 3rd, 2007 at 7:39 pm
[…] this time, Brian Marick has been stirring things up at the Agile Alliance. I’ve joined in the discussion of his observations and proposals only a […]
June 5th, 2007 at 4:27 am
Tomm asked about security. He and others may be interested in the SDL and more in particularly, the book written by Mike Howard and Steve Lipner:
http://www.microsoft.com/mspress/books/8753.aspx
How is the AA going to measure success? What are the CSFs, etc? This needs to be defined and scoped before people commit more of their valuable time to this grand plan.
The offer of assistance to user groups has always been there for groups that contained five AA members, so could you ellaborate on how this is different.
June 5th, 2007 at 12:02 pm
Rather than have me develop Critical Success Factors and measurements, I was hoping that we could select representative (volunteer) members and have them work it out. But first we need to know “representative of what?” Hence, the first basic question: should the Agile Alliance advocate for the core team or the whole business?
Lame, I know.
Assistance to user groups with five members is limited to speaker support, I believe. And user groups are not a focus of the Alliance. We wait for them to come to us, rather than putting together a buffet of tempting help.
In any case, it appears that the proposal is not going to fly.
June 22nd, 2007 at 3:25 pm
Carnival of Agilists for June 22/07 - In Progress…
People Over Process In one his all too infrequent posts Pete Behrens reminds us that is all about the people and not the practices: Scrum is Team-Driven Development. Johanna Rothman reminds us the Standup is about the team and not…
June 26th, 2007 at 10:39 am
[…] Interesting post from the new head of the Agile Alliance here. […]
August 2nd, 2007 at 10:32 am
[…] all comes to mind because of my floundered effort to refocus the Agile Alliance. From the discussion on Agile Forums and other conversations, I concluded that […]