There are many considerations on how to make the move from Project Orientation to Release Orientation. Probably more than any other, the key is a belief in moving your organization’s mindset to the new of way of thinking and recognizing that the value of the old project container has vanished in an agile delivery model.
Specifically, let’s talk about five key considerations to make the move to Release Orientation.
- Portfolio management – It’s really important when doing agile at scale to have a lean way of getting a view of the entire portfolio of initiatives. We need to be able to cheaply get an accurate view into every release going on. We need to have a clear view of where we are investing – and one of the keys to Release Orientation is to start talking about investments in terms of # of teams rather than number of people. Getting less granular in your investment currency makes the investment decisions move faster. For Release Orientation to really work, you need to know the metrics that impact customers (rather than focus on projects) associated with customer experience, defects, etc. We can rejigger those investment decisions based on what’s happening to the customer based on the release. You need to get into one picture the spend on business vs. architecture intent. We also need to avoid metrics explosion. Pick only those metrics that truly give you a picture of what’s important across the portfolio and think hard about the potential nasty side effects of some metrics. For example – we have seen a metric like “% of first pass tests that have passed”. What’s wrong with that metric? What’s the potential bad side effect? We will have developers stop delivering code early because they don’t want this metric to blow up. We should really be measuring defects that got into production – where quality really matters.
- Organizational Structure – Release Orientation forces you to become organized around flow and especially to achieve results in the DevOps area. Most organizations we have seen cannot be disciplined enough to invest in the continuous improvements needed in the early days of moving towards Release Orientation. Therefore, you most likely will need to create a dedicated continuous improvement team to build the bridge, lay the track, and help the delivery engine move faster, better, and stronger
- Release Roadmaps – One of the keys to transform to Release Orientation is to create lean release roadmaps that provide the right time granularity based on the time horizon – 12 month roadmaps or 3 month roadmaps. We can use 12-month roadmaps to help get broader organizational buy-in to initiatives across the enterprise or within a value stream. These are really just boxes put in the rough start and end timelines for any particular initiative – no more precision and definitely not a commitment. We can use 3-month roadmaps to provide a theme or story granularity of the expected delivery over the coming 3-6 sprints – again, not a commitment, but we have a higher level of confidence in this roadmap because we have gotten really good at story estimation when the time horizon is less than 3 months.
- Configuration Management and Branching – To truly be Release Oriented, you need to get to a Configuration management / branching strategy that is simple. Everyone in the delivery stream works on the same release branch which allows for continuous integration across the release stream and minimizes the need and cost of merges
- Environments Management – You need environments that allow for rapid feedback and flow towards a release going out the door. You need to create enough environments so that teams can work independently on getting their stories turned into solutions locally and then promote those solutions into environments that are used by a broader and broader set of the organization. You need environments that can be created, torn down, and re-created via self-serve which points towards high virtualization of environments.