Into Agile

A blog about agile software development by Staffan Svenstig

If something is hard to do, do it often

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

I have found to like the sentence: “If something is hard to do, do it often”. It sounds a bit strange, right, but it makes more sense if you dig deeper into it. Customer releases can be really hard to do. Never ending milestone meetings, tons of documentation, manual testing that goes on for weeks, bugs found that requires hotfixes that restarts the testing in a never ending loop. When releasing is this hard, it is not strange that it is done so seldom. But what we can do to ease the pain, is to do the deliveries more often. Doing it more often, drastically eases the pain. That is the power of continuous (or frequent) deliveries. It did hurt, so now we do it more often, and now it doesn’t hurt.

One term used in agile development methods is the Agile release train. In the real world, trains departs on a regular schedule. And if trains departs frequently and reliably, you don’t need that much upfront planning. Just show up and take the next train. In the SW development world the trains are a metaphor for our releases. If we do releases frequently on a regular schedule, a feature that is not ready at a specific time will not delay the delivery. Instead you leave out the feature from this delivery, and put it in the next, which is not that long in the future from now.

The benefits of delivering frequently on a regular schedule are many. Some examples below:

  • Practice. By doing deliveries often, you learn. As with any activity, we improve by doing it more often. You automate things that takes too long time to do manually. You streamline the process. After a while, it is not that hard anymore. Practice make perfect.
  • Deliveries becomes more difficult to do if they are too large. If you break your work into smaller increments, they are easier to do. Fewer changes means easier integration work and less likely to find bugs.
  • Developers get fast feedback of their work, and this reduces the cost of fixing bugs that are found. 
  • When delivering often, you can get customer feedback. Are we doing the things they want, or we need to change?
  • Easier to manage dependencies to other deliveries. If you have dependencies between different systems, like in the automotive industry where you work together with other components, it is necessary to do timely deliveries. And you have a better chance of doing timely delivery if you do deliveries more often. When you do deliveries in time, you have the possibility to integrate and test together with the other components.

So if you are faced with a task that is hard, ask yourself if you can benefit from doing them more often, making you more effective and remove a source of stress.