The 4 Circles of (Software) Hell

Getting new software out the door and into clients' hands for the first time can be hell. In a number of valid situations, Agile devolves into Waterfall when you know there is a certain threshold you have to hit before you can even play the game. The specific problem always seems to be that work-to-do increases the closer you get to release. This puts you in an eternal state of "almost there".

But what of that work is truly indispensable? The truth is there is always a glaring problem just on the horizon, always a bug fix, always a UI deficiency, always a critical improvement that "needs" to be made. In truth, if you let these hold you back, your clients will never see your work, your company will never see a return on that work. If you let those secondary problems happen, the consequences are WORSE than releasing code with problems.

There is a method I've found, however, that teams can use to claw their way out of this eternal state of torment. Inspired by Kano Analysis (and Big Trouble Little China), this method gets you to clients' hands (good, bad or ugly) in the shortest time by categorizing activities into 4 "Circles of Software Hell" and then constraining activities to progressively less hellacious "Circles".

Here are the step to using the "Circles of Hell" methodology:

1. Anchor your release date
2. Collect all your issues and categorize them into one of the 4 Circles (described below)
3. Start in the worst, 4th Circle, and address all of the issues.
4. Move to Circle 3 issues only when all the issues in Circle 4 are addressed
5. Move to Circle 2 issues only when all the issues in Circle 3 are addressed
6. Move to Circle 1 issues only when all the issues in Circle 2 are addressed
7. When your release date comes: If you are not in Circle 4, release. If you are in Circle 4 postpone.
8. Use Staged Rollout (see LaunchDarkly), Behavioral Monitoring (see Pendo), and Asset Performance Monitoring (see NewRelic) to get early feedback so that your customers can tell you what what your next true priorities should be.
9. You're released now, be Agile, be Lean, move fast.

The 4 Circles:

Circle 4: The Brick

Place items here if you can say about them: "If ____ stays the way it is, we may as well hand the client a brick." In fact, a brick may have more utility for the client than this software.

• Not even worried about crashes, it doesn't even run.
• Critical activities are literally and absolutely impossible to perform, not even with all the time and patience in the world.

To get out of Circle 4, there can be NO remaining Circle 4 items to address. You may not work on items from any other circle until these items are addressed. Once they are addressed you may move on to....

Circle 3: The Anathema

Place items here if you can say about them: "If ___ stays the way it is, most clients will absolutely hate us"

• The software may crash constantly
• Critical activities can "technically" be done with enough time, patience and work-arounds. They might crash 9/10 times though.

Once every critical activity can "technically" be done, and all the high-probability crashes are gone, you may move to items in Circle 2.

Nothing issue may exist here that may occur in 20% of interactions or less. Crashes 15% of the time then see Circle 2.

Circle 2: The Inconvenience

Place items here if you can say about them: "If ___ stays this way users may perceive the software as being little rough."

• At this point the software isn't crashing constantly
• All critical activities can be done, but are may not be particularly polished
• Any "Scale Issues" go here, not in Circle 3. Remember, we're talking about getting out the door here, not satisfying the entire world. In the mean time, manage your scale issues with Staged Rollout.

Circle 1: The Catharsis

Place items here if you can say: "If ___ stays this way people will perceive the software as polished"

Catharsis is the end state. If you make it this far, shame on you, you should have set an earlier release date.