Tuesday, January 15, 2008

I've been following the LeanAgileScrum discussion on to Agile Project Management list with some interest. Here's the reply I sent recently:

I would like to relate a story of a personal experience from a few years ago.

I worked with a group that had a rather heavy-weight requirements process. By which I mean, big nasty template with signoffs. I once saw, literally, a five-page requirements document that equated to one line of code.

So, in comes the agile coach, and he says, "this requirements doc is junk. We're going to discuss the requirements and write things on these little index cards ..."

The requirements people first admitted the requirements docs were bad, then fought to keep them tooth and nail.

What's going ON here?

The best explanation I found was that we were taking away the one thing they knew to cling to. Oh, it wasn't very good, but it was a safety blanket. Without that, *now* how do we do our jobs?

I think moving from a heavyweight, Big-Up-Front-Everything shop to a scrum shop is much like that. Many people want prescriptive processes. They want to be told how to do it. They want to be able to follow the process instead of inventing it.

Or, at least, they _think_ they want something like that. If they *have it*, they'll feel constrained by it and hate it and complain about it, but gosh, having a template sure is a lot easier than having a blank sheet of paper. Even if it's a crappy template.

So you see these good ideas like Agile or Scrum institutionalized, procedure-ized, process-ized, turned into certifications ... and someone has to come and invent a new buzzword to say "no, stop being stupid" only more politely.

Today it's called lean, or maybe post-agile. And, if it achieves some good, I'm fine with it.

3 comments:

I think the worst way to adopt agile is to just adopt the process without taking the manifesto and principles seriously. I like to say that these people are being Agile without actually being agile. It's important, when you introduce scrum to an organization that has been process heavy for a long time that you take time to address the new set of values that come with incrementally building software. I've found that the transition from waterfall to scrum is very difficult for some people, and anyone who hopes to introduce it successfully would do well to anticipate emotionally charged resistance.

Software project management goes through fads, just like skirts. Sometimes they're really short, and sometimes they sweep the floor.

I wonder whether the next fad will be a process-less process, where procedures and guidelines will be banned. Everyone will get together and agree what they're going to do and how they're going to do it, and then go ahead with it.

I am now agnostic about fixed processes. Some shops are comfortable with them--nay, they can't operate without them. Some try to reinvent them anew for every project. If I'm in one of the former shops, I look at the context and just buckle down and work by the processes. Otherwise, I look at the context and try to work out what will bring results in that environment, and go ahead and do that.

As you say, if any of this achieves good, I'm fine with it. Even the waterfall process (probably) produced some working software.