Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-Orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality. While Continuous Delivery has become a very popular destination for many software engineering and IT shops, Release Orientation goes well beyond the rapid feedback and rapid test and release cycles of Continuous Delivery. Release Orientation is focused on realizing value through regular and frequent solution releases going into production (or customers’ hands) – thereby realizing continuous value for the business. In other words – Continuous Concept to Cash.
Let’s work backwards from the point of value delivery – the release – backwards to understand how to make Release Orientation a reality for your organization.
First, you need to create a widely publicized, at least internally, schedule that the entire solution delivery organization, including the business, knows intimately. The release schedule is the schedule is the schedule – it becomes the immutable part of your solution delivery. Let’s be clear – there may be many cadences of releases – the key is that those cadences are well known and predictable. One of the key advantages of this way of delivering is that if you can get these releases to happen frequently enough and predictably, no one gets too upset if their particular idea did not turn into a release this week or month – there’s another one coming down the pike really quickly.
Second, if you’re running Scrum, you can set up your schedule of releases to be every one, two, three, or four sprints – that’s about every 2 – 8 weeks. If your releases are much more than that apart, you will lose the ability to say to that passionate business “idea” person – “not this release, but the next one’s coming out quick”. For each team, they look to fill the content of their Sprints from a prioritized backlog – this is standard Scrum practice. Sprint after sprint, they go and grab the items off the top of the backlog. Of course, the backlog can be entirely adjusted between sprints. The key here is that a team has clear direction on where to grab their ideas.
Third, as part of the flow, any particular high-level idea can turn into a list of prioritized backlog items. We have a bunch of ideas that each generates their own backlog items. The team’s prioritized backlog is now the culmination of a bunch of ideas, broken down into backlog items that can be mixed and matched as content for any particular sprint. In that way, THE most important backlog items, regardless of what idea they were borne from, are getting done first. This is the key to Release Orientation vs. Project Orientation. If Project Oriented, we would need to get all the backlog from Idea #1 done first, then the Idea #2, and then Idea #3. With Release Orientation, we recognize that some significant value can be delivered from 1 or 2 of the top backlog items generated from any particular idea. And, in this way, we can be delivering multiple ideas simultaneously.
Flow breaks out! Release Orientation – A Continuous Flow of Value.