The Value of Frequent Releases

I took the big, thick requirements document filled out using the template and broke it down into a dozen cards. I brought the cards to the customer, asked them to sort the cards, and told them they would have their first new functionality in two weeks, not six months. Once they used that functionality, they could order the cards or create new cards. The only catch was that in twelve weeks, the music stops and so does development. This was totally new for them; it turned planning into a game. The only thing the manager did not like was the twelve-week limit.

Many people are familiar with the idea of the 80/20 rule. It sounds great, in theory, until your customer tells you they really do need all the things – these are requirements, Matt, not desires.

Yet we finished that project in five two-week sprints, for a total of ten weeks. We finished early.

Think about what it would mean to deliver that 80% of value, then switch to something else. Do a bunch of stories that deliver $2,000 a month and, when you get to the ones that would only delivery $1,000, cut over to another project delivering $2,000. Rinse and repeat. The world, as they say, becomes your oyster.

The Impact on Testing

This is the hard part. It’s easy enough to scale down development – just change one field, one button. Serious testers intuit that for most programmers, a whole lot needs to be retested. Not just that button. Scaling up testing frequency is a lot harder than scaling up development. Done poorly, you’d certainly get less software out the door in a given month by trying to regression test twenty-two times, at once per day, than once per month. And with multiple deploys per day … fuhgetaboutit.

The longer, harder road is to improve engineering discipline and skill to reduce regressions. That includes architecture work, fast deploys with feature flags to enable rollback, plus the development of programming skill.

Or you could just get really good at testing.

As it turns out, testing is a bit like building a muscle. If it hurts, and you do more of it, and do that well, you get stronger. It is always possible to lift heavy incorrectly, and do serious damage. Form matters. The same is true in testing. Most of the organizations I work with can usually cut their testing time in half with a few simple tweaks. In some cases, it is a 90% reduction in test time. Shrinking the cycle time and rejiggering the process could mean you throw away old, outdated ways of doing work.

I am not suggesting you go to continuous deployment overnight. Instead, get better at testing, and engineering, intentionally. Call each step forward a win.

Conclusions

Ship more often, deliver value. Ship more often, deliver less waste. Ship more often, become better at programming and testing.

Ship more often should be feared, but in the same sense you fear going to the gym or changing your diet. If you do the work, in six months, or a year or two, you’ll be, well, “shredded.” You’ll look back at what you were and see something you hardly recognize. Of course, if you want to go to the gym or not that’s on you. Right now, I’ve had other priorities in my life. The software gym? It costs you almost nothing, and offers you so much.

Ship. More. Often.