Release planning and predictable delivery

Many organisations wrestle with the seeming incompatibility between agile and release management and they struggle with release planning and predictable delivery.

The incompatibility between predictable delivery and agility is fictitious (tweet this) and while usually created by an organisation and structure that is unwilling to let go of the old ways and embrace the tenants of agile it can also be the result of a Teams fervor to divest themselves of all things that smack of prior planning.

There is a lack of understanding that agile and the path to agility is far more than just a change in the way that you build software, it is a fundamental shift in the way that you run your business. Much like the lean movement in manufacturing, companies that embraced it wholeheartedly were the ones that ultimately see the competitive edge that it provides. If one is unwilling to let go of the old ways then one can’t attain the value of the new.

This change will take hard work and courage as the fundamental transparency required to inspect and adapt effectively is at odds with the measure of the past. The lack of predictability of software development is the key to understanding the new model.

Why is software so unpredictable

All software development is product development.

In lean manufacturing we can optimise the production of pre developed products through the nature of its predictable production. Each widget takes the same amount of materials and time to produce so any changes that we make to that time or materials can easily be qualified and the benefit demonstrated. Manufacturing is predictive.

With software everything that we create takes its own amount of time: You can really only know how long something took after it has been completed. Even in manufacturing if you asked an engineer how long it would take to develop a new widget they would not be able to tell you with any certainty. Once they have developed it however they can tell you exactly how long it will take to make each one. In software development we are always doing new product design therefore we have no certainty…and this often results in chaos.

All is not lost however as we can, by looking at our history of delivery for similar things, make a pretty good forecast

The best thing we can then do is to expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast.

Figure: Diminishing returns from Agile Estimating – Estimation Approaches

Ultimately Software Development is a creative endeavour and has the same lack of predictability that painting a picture, writing a book or making a movie has. Yet movies get made all of the time. How can that possibly be! Well they have a Director (Product Owner) that has a bunch of money and a plan for delivery, a Producer (Project Manager Scrum Master) to make sure that everyone has the skills, knowledge and assets available at the right time and place and one or more Units (Development Teams) that have all of the skills necessary to turn the Directors ideas into a working movie. They create Storyboards of what they expect to create so that they can run it past the stakeholders and get feedback. They take those storyboards to the Units who collaboratively work together with the stunt, prop, lighting, camera, sound and wardrobe crews to get estimates and costs and ultimately coordinating to create the movie.

Making a movie is just like building software, you need a budget, you need a plan, and you are trying to reach a ship date. And just like building software you have to make money at the end of the day so that you can do it all over again.

Accept the lack of predictability

While I hope by now you understand that the lack of predictability is part of the nature of building software there are many things that we can do to lessen the impact of that chaos. Indeed if you were to estimate all of the discreet things that you need to do to achieve a goal (lets call them backlog items) in Small, Medium and Large what would your standard deviation of actual hours be? I would wager that it is fairly large. So large in fact that at least half of all mediums would be more accurately classified as Large. But that reclassification can only be done with hindsight.

This is normal for organisations that move towards agility as the transparency that it brings uncovers these sorts of problems. In order to increase the accuracies of our forecasts there are a number of simple activities that we can perform. These activities, while easy to understand, are very hard to do as they require a culture shift within your organisation as well as the courage of the participants to make them work.

Focus on continuous quality

Most software lacks quality for one simple reason. You can’t really see the quality like you could with a table or a painting. I am not talking about the quality of the User Interface, but the quality under the covers; the quality of the code.

If you put developers under pressure to deliver they will continuously and increasingly cut quality to meet deadlines.-Unknown (Tweet this)

A lack of quality of the code results in a increase in Technical Debt (or more accurately an unhedged fund) which in turn results is two nasties. The first is the teams  increasingly have to spend more time struggling with the complexity of your software rather than on new features. If you are still pushing your teams to deliver the same feature level every year you are only encouraging them to cut more quality and thus incurring technical debt becomes a self-fulfilling-prophecy. The second is an increasing number of bugs found in production. Bugs found in production also directly impact on the amount of features that the team can deliver and any bug, no matter how small, costs ten times ad much to fix in production than it does in development.

There is only one way to deal with technical debt:

  1. Stop Creating it
  2. Pay a little back each iteration
  3. Goto #1

There are a number of strategies that can help you both stop creating and start paying back technical debt:

  • Sufficient requirements – If your backlog has things in it that are too big or to vague then your team will not really be able to understand them and this in turn creates a multiplier for uncertainty. Follow the INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable ) model for every single thing that you ask the team to deliver. If you invest in you backlog in this way you will find it much easier to deliver the contents and thus predict that delivery.
  • Team chooses what they can deliver – this implies that the Development Team can reject any item on the backlog that they do not understand. If we accept that every Development Team is trying to do their best to deliver for their Product Owner then the only reason to reject anything would be if an item is too big or does not have enough detail to understand.
  • Definition of Done (DoD) – Along with having sufficient requirements the single biggest blocker to predictability is a lack of common understanding of DONE. Done for a Development Team should equal what it means to complete an item with no further work required to ship it. As a reality check you may need to start with less than this and then build it up as you pay back your technical debt. Technical debt is the reason that your DoD is diluted and once you have a representative DoD your Development Teams predictions will get way more accurate.
  • Fixed length iterations – If you have variable length iterations you can’t be sure what you can do in a particular timeframe. How much decomposition do you need to do to the backlog? How much can the team deliver in a single iteration? You can’t be sure unless you have fixed length iteration.
  • No separate teams – This means no separate test teams, configuration management teams and definatly no separate maintenance teams. Its hard for folks to grasp, especially with the recent focus on DevOps but if you have separate teams then why would your Development Team, those best placed to fix any problems, care about the problems of other teams. The most successfully organisations at creating software have development teams that own the entire application lifecycle (Amazon AWS | Visual Studio.)
  • Manage dependencies – Managing dependencies is hard and my advice is don’t. A Development Team should have all of the skills required to deliver what you want at the quality level that you want. So if you need to have productionised databases, or scripting for production deliver then you might need a DBA or an Operations administrator or two. This can be hard for many teams or organisations but you will have far less success creating silos like Configuration Management or DevOps. Rather add those individuals that you need to the team. However if you have a dependency on a separate team, maybe you have an application upon which all of your other applications depend, then you may need another way. This is not a silo of types of individual skills, but of domain and that team just has something in their backlog upon which you are dependant. It is up to the teams respective Product Owners to fight negotiate over when these things get done.

If you can, do them all…


Remember that any software that you create is an organisational asset and decisions to cut quality need to be reflected in your company accounts and as such those decisions need to made by your executive leadership and should not be made by the Development Team.

  • Hi Martin,

    Great article! I especially like your analogy comparing creating software with movie making.

    However, I disagree with your points about DevOps. In my opinion – which admittedly might go against the DevOps movement as a whole – DevOps is about building stronger partnerships between the existing teams, dev and ops, rather than creating a new silo to live between them.

    This is especially true with configuration management where dev teams must learn to take ownership of the configuration and how it is managed in all environments, not just chuck it over the wall and make it an ops problem. A friend and colleague of mine discusses this in more detail in an article on our site, DevOps on Windows:

    Anyway, thanks again for the article, keep up the good work!


    • Russ,

      Thanks for your response.

      The problem is not with “devops” but that it has to exist in the first place. It is a band aid and not a solution. Why do we have a situation where people can ‘chuck it over the wall’ at all? Operations should be responsible for hardware only. The application should be supported and maintained by the Development Team. This removes the silo and forces the Development Team to deal with their own messes.

      Get rid of all of the silos by making the folks that would be in that silo part of the Development Team and holding the entire team accountable and responsible for delivery all the way to production.


  • Pingback: Does your company culture resemble Survivor?()

  • Pingback: Does your company culture resemble Survivor? - Community Blog()