Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for how to think about what to release to your customers when. Hopefully it’s self-explanatory, but the idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not, when explained like that, so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. At the beginning they’ll probably have to put up with a lot if they want to use it, but with each successive release they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning and all along the way the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it usually involves some rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

HT: the brilliant User Story Mapping by Jeff Patton and Kevin Alves

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Sketchplanations tagged with agile