Your product delivery plan versus reality


Hello!

Here in Spain, August is a month of Very Serious Holidays. Much of society shuts down - including many neighbourhood shops, most school holiday programs, and even my favourite cafe. It is hard to achieve anything.

As an immigrant to Spain, every year I fight against this. I try to get work done, believing I can magically fit things into the non-existent time on my schedule. And every year I fail at this.

I thought I’d be able to keep up my routine of writing these newsletters each week. Reality thought otherwise.

I’ve been in Spain for 15 years, so perhaps it is time I accepted the national August pause. Which brings me to...

Adapting product delivery for cultural realities

Chapter 5: The Power of Constraints of Kill the HiPPO tells the story of DNSimple and their adoption of the Shape Up framework. If I recall correctly, a good part of DNSimple’s team is in southern Europe, which shares Spain’s culture of a healthy work-life balance.

Instead of fighting the culture, DNSimple modified Shape Up - which argues for six-week product development cycles followed by two-week “cooldown” periods - to include additional two-week breaks.

This break isn't part of Shape Up, but DNSimple introduced it after engineers shared feedback about Shape Up's aggressive pace. It left them constantly building, with little time for other tasks or rest.⁠

You don’t want burned out staff struggling to get things done with unrealistic timeframes. Working contrary to the culture around them will burn people out.

Ten years of cycles

This got me thinking about how many major features we can realistic deliver in our products. If each 8- or 10-week cycle + cooldown period delivers one major feature, then in a year each team will deliver 6 major features at most. That’s not much - especially given your mile-long backlog.

And over 10 years? A product team will deliver only 50 to 60 major features. If you maintain a feature backlog, I’d guess that your backlog contains more than that.

Two consequences come to mind:

  1. Each cycle is precious. So don’t waste it. You’d better do everything you can to make sure that the feature you are building is really something that your customers want and will use.
  2. Delete most of your backlog. Keep just a few things on it. There’s no point in having hundreds of items on your product backlog, given that you can’t deliver them all even in 10 years.

Can we solve this with multiple product teams? Yes, you’ll be able to deliver more, but there is a price. You’ll spend even more of your time hiring, managing, and co-ordinating - and at the risk of giving unproductive people more places to hide.

A Kill the HiPPO podcast in video form

I didn’t realise when the episode was first published, but my appearance on Rogue Startups is also on YouTube.

Watch it here - and you’ll spot some of my daughter’s artwork on the wall behind me.

Until next time, keep making great software.

Steve McLeod
​​killthehippo.com​

PS: If you’ve bought Kill the HiPPO, have you written a review yet?

Subscribe to Kill the HiPPO