I've been working through some interesting process issues with my employer's CTO and head of Product Management. The thrust of these discussions is that we've revised our Product Planning and Product Development processes, and I'm currently working on documenting what we've agreed upon. No sooner had we come up with a plan, however, than a "highly important" project sprung up, prompting discussions about suspending parts of our process because this project was so important. I've managed to stop my head from spinning long enough to gather some thoughts....
Origin of Process Changes
I've grown my current development team from nothing, and grown our process along the way to fit the organization. Our informal process guide has always been "just the right amount of process for our needs... and nothing more." In our most recent revisitation of process, I worked with our CTO and Product Manager to address schedule variations due to requirements problems.
In short, we were entering a release with only the most vague sense for requirements for features in that release. In the past, this had resulted in schedules not being met because we didn't really understand what we were supposed to build until we moved a portion of the way through the release. I'd suggested better requirements a number of times (citing Joel Spolsky's excellent guielines), but this was written off as too much work.
Prototyping, it was agreed, would be the best compromise for our situation, allowing us to build out more detailed requirements iteratively. We tried this in a mini-release, and though we had some minor problems, it was deemed to be generally workable. A side effect of this process is that our release date couldn't really be known until we moved through about 1/2 of the release. Prior to that, we had a target and a +/- range for our date, but nothing one could take to the bank.
It was about this time, of course, that the Important Release reared its head. We needed to figure out a date for the release *right away*, which was the first violation of our process. Nevertheless, I came up with a date based on similar work and similar releases we'd done in the past.
The date wasn't good enough.
Thus began the further erosion of process: "why can't we skip parts of the process and speed up the release?" "I know this isn't our normal process, but this isn't a normal release -- this one's *IMPORTANT*".
There was clearly a whole raft of concepts that just never managed to lodge securely in the nooks and crannies of these executives' minds. These are a couple of pretty smart people, so I can't chalk this up to lack of cognitive ability. There's something here that these guys really don't get, and I can't account for it.
The Missing Link
In the spirit of "we hold these truths to be self-evident", I'm adding here the rationale I've used to establish process. It seems to make sense to me, but as my recent experience has shown, it can't be taken as a given that this makes sense to everyone. I've seen this widely chalked up to "some people don't get it", and I have to echo that sentiment at this point.
Our software development process, like most, is designed to move us through a release as expediently as possible. It's not my habit to put process in place to make us go more slowly. Unfortuneately, this is a nuance that's frequently lost on the casual observer. Process, it's felt, is overhead. Cut the process, and you'll go faster.
Steve McConnell's Rapid Development has a great passage about a software team from Ernst and Young who attended a programming contest and used process to great effect. They appeared to get out of the gates more slowly than everyone else, but their process made their progress so reliable and relentless that they quickly overtook everyone else. They ended up finishing second because of a breakdown caused by skipping part of their process! (They ended up using the whole process at the next event, and won it).
If process didn't help us, we wouldn't use it. Therefore, any process we've got is here because it makes us go faster. Simple idea, but frustratingly elusive when it comes to getting non-developers to internalize it.
I tried another example with seemingly little effect. Imagine someone who spends lots of valuable time coming up with a disaster recovery plan, and then when a disaster hit, the first thing they do is reach for the disaster recovery plan and chuck it in the trash. "I don't have time for a plan," they'd say -- "We have an emergency on our hands." Most people, I think, would say that they deserve whatever fate befalls them.
Not so with a software development process, though.
I'd like to hear your impressions and ideas. Register and post your comments if you've dealt with this.