Involvement as Fun

[jducoeur]

There. After four years of my haranguing about it (and about three months of talking about how to *do* it), we took our first real baby steps in Agile Development today. We took one of the side-projects for the new system (one of the test harnesses), talked through the User Roles involved in it, and began to write the Stories for the feature.

It's going to take a while to get used to it -- much of the time was spent simply getting people on the same page of what a User Story *is* -- but overall it was a good experience, and reasonably productive. Best of all, everyone seemed to enjoy themselves, specifically because everyone on the team, including the junior members, were explicitly equal in the process. Management will be responsible for deciding the priorities for these stories, and everyone is quite clear that some of them probably won't ever happen, but everyone got their say. If nothing else, accomplishing that may be worth the pain of changing how we do things.

It does remind me remarkably of Carolingian Great Council, in a way. One of the precepts I've always followed there is that you don't have to *do* what everyone says, but it's very important that everyone get to speak their mind. It produces much more of a sense of involvement in the whole thing...

Comments

[cvirtue.livejournal.com]

you don't have to *do* what everyone says, but it's very important that everyone get to speak their mind. It produces much more of a sense of involvement in the whole thing...

Or it gets the yahoos all complacent so you can then do what you want to do anyway, a la Moon is a Harsh Mistress.

I often wonder this when I hear of new movements in an organization which invite commentary, and then wonder further if those new movements don't seem to produce any traction over months of effort. It's like Student Council taken into the real world.

However, I hope/expect that your company is not nearly so machavellian, and it bodes well, because certainly it can work well, if done with good intent.

[jducoeur]

I'm sure it could be used in that sort of way, but it misses enough of the point of the exercise that it would probably become counterproductive before long. Most people do tend to eventually notice when they're being covertly ignored...

[siderea]

Or it gets the yahoos all complacent so you can then do what you want to do anyway, a la Moon is a Harsh Mistress.

That was my first thought, the way jducoeur phrased it. :)

It's not so much that everyone gets to speak their mind as that what's on everyone's mind gets heard, just in case, you know, their ideas are any good. :}

[jducoeur]

It's worth noting that both are valuable, but for somewhat different reasons. Letting everyone express themselves as they want to is important for morale; understanding their ideas is important because they provide a different viewpoint, and often have insights that the groupthink at the top might not have.

But the two are really separate goals. There are plenty of ways to solicit input from people that are non-public -- that can get those ideas into the stew through other channels. Letting them express those ideas in an *equal* way serves other purposes as well, beyond just knowing what they think...

[goldsquare.livejournal.com]

So: are QA and Documentation users, or part of the process, or something else?

You can imagine why I ask. :-)

[jducoeur]

We really don't *have* any documentation people at this point. Our only full-time external Doc guy died last year, and the only person left really doing internal documentation was umbran, who got laid off last week. (Yes, I suspect we're going to regret that particular decision.)

But yes, QA is fully engaged in the entire process. It's all being laid out by a small committee of the heads of Dev and QA, and their common boss, the VP of Engineering. The theory (based what seems to be the consensus among the more plausible Agile sources) is that all features really need to be treated as a collaborative process between Dev and QA from the start, and we're trying to take that principle fully seriously. QA starts developing the test plans while Dev is designing the feature, and we start testing the feature in the automated testbed as soon as it's checked in...

[goldsquare.livejournal.com]

That worked very well at X Consortium, and X11/CDE showed it.

I've also done that at BEA, and a few other places. It really, really pays off.

Damnit, I want to do it again.