Always talk to the worst Gorilla first- Risk mitigation though facing it.

“THREE MONTHS!” I’m pretty sure my voice cracked in a very unmanly-like manner just then. “We have to slip the release by three months?!” Okay I had my voice under better control, now if I could just loosen the death grip on my pen before it broke. “And you’re telling me this three weeks before we were supposed to release!” I needed a new pen anyway.

Jake, meanwhile, was managing to keep his usual calm demeanor through all of this. If he’d ever had a drop of caffeine in his life, you couldn’t tell by his response. Nodding slowly he said, “Yes.”

Yes? That was the sum total of his response? If I squeezed any harder on my broken pen, they’d need to use tweezers to get the bits out of my skin. “Jake,” I said with more calmness than I felt, “I can’t go to E-Staff with just ‘yes, we’re going to slip.’ I need to tell them what went wrong.” What I didn’t say was what I was feeling, I needed something, or someone to hang the problem on.

Jake gave a shrug, “Well we knew there was a lot of risk with the new destabilizers in the matter conversion code. It ended up being a lot more integration work than we thought it would be.”

I gripped the edge of the table. Two inch oak wouldn’t break under my grip like my pen had. “Okay, so why are we not hearing about this until just now?”

Jake pointed towards the planning wall, “Because it was put last in the product backlog. We only just started working on it last week.” He turned back to look at me, “that and because when we tried to estimate it as a 54 point story, ‘everyone’ (he was being nice, he could have just have easily said the product owner and I)  objected and insisted it couldn’t be more than an 11 point story. Honestly, I’m not sure we can even ship in three months, this could be a non-starter feature.”

I loosened my grip on the table and buried my head in my hands. It was looking like I had two perfect nooses for this debacle. One for the product owner and one for… Me.

“You know…”

Oh, just great! The last thing I needed was an 800 pound gorilla showing up to give me his “pearls of wisdom.”

There was Hogarth, quietly contemplating the burn down charts on the planning wall. He was being very un-gorilla like, standing almost erect with his great hands clasped behind his back. He was facing away from me, but I could still hear his voice clearly. “I love slides. I really enjoy the feeling in your stomach as you push off and start dropping.”

Slides? What on earth?

Hogarth sighed, “Still I don’t play on them much. You know why?”

I had no idea what on earth he was talking about. I did know he was going to tell me even if I didn’t want to know.

And he went ahead and did, “The problem is you have to climb up the ladder first. I hate doing all that hard work first. I wish I could slide and then climb the ladder.”

“Hogarth! That’s utterly ridiculous. You can’t go down until you’ve gone up. It’s the hard work that allows you to have the easy ride. That’s the whole point of a slide.”

He turned to eye me, one hand pointing back to the burn down chart which showed how our velocity had shrunk consistently for the entire release. “So nothing like your software development practices?”

I sighed and nodded. Sometimes his questions just showed how much he just a gorilla lost in a jungle of silicon. “Yes, Hogarth, nothing like our software development practices at all.”

He nodded, “Yeah that’s what I thought.”

Finally, I’d gotten one over on him. Of course our software process was nothing like climbing the ladder first so we could coast to the bottom.

Wait a minute…. Damn it! He did it again!



Clean the garage or sort my sock drawer, put away clothes and vacuum the bedroom? Given the choices I’m probably not going to start with the garage. So when I’m done, I’ll have gotten three fairly small things done, and I’ll be no closer to getting the elephant in the house clean (If you can park a car in your garage, I envy you. I can’t park a Hot Wheels in my garage it’s so full). So at the end of the day, the biggest issues I’m facing is still there and I’m too tired on the little stuff to work on it.

We do the same thing all too often when developing new products (any kind, software, hardware, toys, financial instruments, etc.). And all too often we end up with a looming specter at the end of the project. One that often turns out to be bigger and nastier than we realized. That or maybe we’re just too tired from all the other stuff to face something so big.

We do this so often it has become normal for us to accept this behavior. Reportedly, the US Navy air program has projects that take years to complete. Project Management is done by a senior officer and their tour of duty is three years, which is shorter than the whole project. There is a marked tendency for first project manager to push hard stuff down the line so that when their tour is up the easy stuff is done and they look great. The next Captain is then faced with all the really challenging stuff. The second tour of a project has come to be referred to as the “Dead Man’s Tour,” because the second guy looks like a failure.

Extreme Programming tackles this head on. They have a concept called “Do the worst things first.” The concept is to get the toughest issues out of the way before moving on to the really easy stuff. I know, I know, you’re saying “hey that’s not very agile. I thought we were supposed to focus on early wins.” Yes, that’s true and when you first start a project communication is usually your worst problem. So you do an easy sprint or two to make sure everyone is working together well. The early wins make the team ready to tackle the worst technical issue with the project.

And what about the risk of the worst things? As we see in Hogarth’s introduction, Jake talks about not being sure it will even work. Might not even work?

“Holy broken faucets, Batman, what a waste of resources if the whole project fails now.”

That’s right. If we put off the really hard stuff, and then the really hard stuff kills your project, not only is the project dead, you’ve also wasted a lot of time, resources and people on a project that didn’t fly. If you’d done some early prototypes and tackled that big hairy audacious goal first, then you would have known if you should even keep going or not.

Fail early, get better, don’t waste time and resources.

So what risks are you putting off in hopes they will go away? Next time you’re at the zoo, ask the ostrich how well putting his head in the sand works for him.