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.
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.
I think you’re right about there being people who desire the prescriptive processes, but there could be another thing going on.
This post is interesting because you follow it with this one. Compare your statement in the current post:
“The requirements people first admitted the requirements docs were bad, then fought to keep them tooth and nail.
What’s going ON here?”
to the one you make in the next post:
“…The problem is that in that world, the developer is a commodity who doesn’t add a lot of value.”
Any process change is hard for people. It is especially hard for those who look down the pike and wonder if they won’t add a lot of value in the future.
In spite of the manifesto’s insistence on people over process, many seem to roll out the change without giving too much thought to the feelings of people who may be turning into chickens.