How to prevent a(nother) death spiral (part 2)

In my previous article, I talked about the symptoms of a death spiral, where your { requirements, dev, build/release, test } cycle begins to constrict as you approach a deadline and tension rises, making everyone edgy and impatient.

After you escape a death spiral, you have a window of opportunity to prevent the next one.

First step: admit there is a problem. “Death spiral = bad.” Done!

Second step: find the cause. The cause could be attributed to a few critical ingredients:

  1. Your dev cycle is too long. When the users hear that the train is leaving the station, they begin to think “If I miss this train, how long until the next one leaves?” Then, “can I wait that long”. If your dev cycles are 6 months, and it takes 4 retries for the user to make up his/her mind, then you are looking at 2 – 2.5 years. If you were them, you would be freaking out too. However, if the release cycle was 2 months, I think I could wait 2 months. Even if I miss two trains in a row, it’s not like I will be waiting 2.5 years. This is a psychological tactic, but it works very well.
  2. You aren’t getting good requirements. Realistically, the only thing that will fix this is either a) more experience, which will take time. Or b) change your process to compensate for inexperience by using prototyping. You might think that hiring a BA will fix this, but it doesn’t. You would have to hire the equiv to Martha Steward for magnificent BA and she would have to train you. Only then could you compensate for inexperience from requirements givers AND takers, plus an under-matured development process.
  3. Expectations aren’t accurately set. If you can’t get good requirements, you can either a) wait for perfection or b) lower expectations. Keep in mind that there are an infinite number of “wrong” ways, but very few “right” ways. The more rigid your criteria for “right”, the fewer the number of “right ways”, which reduces your chance of reaching one. So, you should get things into perspective/reality. Releasing software that doesn’t perfectly meet everyone’s needs is not going to bring the end of the world. It will be awkward for a while, but it will also encourage people to organize their thoughts better (like prototyping does). Make mistakes and learn from them. Plan on it.
  4. You must not waffle on your release process or date. If you ever have to blow a release date, then your process is broken, badly. You need to predict and prevent the factors that caused you to miss your release date. Start by improving your process and then you can stand behind it and enforce it firmly. I nearly listed this as #1, because the only way that your release cycles will tighten is if you allow them to. So define a process that makes sense, and adjust it before things get ugly. Because, when things are ugly, you will be tempted to make panicked changes and panicked changes rarely (almost never) end up with good results.

I realize that all of this sounds a lot like a pitch for using the Agile method(ology). I’m a little less hung-up on names of methodologies and more interested in using an approach that is going to work. I have actually worked with people who banned Prototypes from a project because “prototypes are part of Agile and we are not going to use Agile”. Ultimately, a project can struggle or fail, solely because you don’t have the tools that are necessary to be successful. When you lack the right tools, an ordinary, typical hurdle can become insurmountable. It is a little hard to imagine, but it happens.

In contrast, I have worked in teams that used what they needed. They took parts/elements of several (4-6) different methodologies/tactics (etc) to complete various projects. Each of those projects went more smoothly than the previous. Those teams spent some time working on their processes before working on their projects. They wound up working smarter instead of working harder. It was so harmonious; you could almost imagine David Lee Roth singing it: “ooh-la-la, Software Development methodology, aaaah-yeay-yeahaaa”, …hmm, or maybe Beyoncé sings it.

Anyway, bottom line: To avoid a death spiral:

  1. Define your process, with particular detail to build/test/release process (schedule) and write it down (so you can stick to it).
  2. Define the scope of this dev cycle [ie. what features are in/out for this cycle] and lock it down.
  3. Identify the features that are on the edge of the scope (pick the ones that you could postpone, if you run out of time). This train only has X seats, if one more passenger gets-on, then one must be kicked-off. Stick to it.
  4. Keep your cycles short but not too short (1-2 months is ideal). It yields quicker adjustments, quicker ROI, without being nutso.
  5. Pick a release date that is based on your scope. Be prepared to bump features off this train and onto the next one so you can meet your deadline.
  6. Don’t budge on your process. Learn from your mistakes and don’t repeat them. (plan on it)
  7. Remind people that there will be another train coming along in 1-2 months. There is no need to panic. The time will fly-by. Focus on reviewing and refining requirements so you don’t have to take 2 more dev cycles.

Each time you apply this process, refine and repeat. If everyone commits to playing along and giving it a chance, you will see the process purify itself and other adjustments to your process will become clear after a few cycles. As people see this process working and they become experienced, things will become easier.

For now, hang in there. You have my sympathy. I feel your pain.

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in IT Psychology, Methodology. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s