(GR)²

Right now, I'm working in a waterfall environment -- gather the requirements, get sign-off on the requirements, manage any change requests after the requirements are signed off, move to design, then development, then test, then production.

And I'm not the CEO, or the CIO, or even the director of my group; I'm an individual requirements manager. So the degree to which I can push change is pretty limited. But so much of what I'm reading and hearing about how Agile approaches development projects makes so much sense! I've been talking to people like my friend Mickey, and pondering how I can apply this attitude in the waterfall environment I'm currently in.

Nancy Van Schooenderwoert has an article at Agile Rules in which she talks about empiricism as the essence of Agile. It's often referred to as "inspect and adapt," but it is basically the scientific method, as far as I can tell. Here's how I understand it:

1. Come up with an initial approach (theory)
2. Try out that initial approach (testing the theory experimentally)
3. At the end of a set (short) period, evaluate the results of that approach (the results of the experiment)
4. Refine your model

And that is a basic analytic tool I can use under any circumstances.

So my current goal is to look at the projects currently on my plate, determine where I can cut short the definitional process by giving a clear and clearly limited summary of what we need to do next, and doing that thing followed by immediate evaluation and refining of the model.

The other piece of "Agile Attitude" that this will depend on is the frequent brief touch-base with all project team members, to find out where things are working effectively and where we need to adjust or adapt. So the other thing I'll be trying to do over the next week or two is move from weekly hour-long meetings toward shorter (half hour? twenty minute?) meetings held twice a week, or eventually more frequently than that.

And then I'll inspect the results of that effort, and adapt accordingly.