Release Strategy
Dynamics and Challenges
Teams that only consider a superficial understanding of the work tend to adopt a “conveyor belt” style of working that orders the Product Backlog and then progressively works through each of the items in order without too much thought about why it is needed. This is a reactionary style of working that only responds to the changing order of items.
Teams that have a higher level of consciousness and an awareness of the dynamics and challenges in the body of work tend to think more strategically about how they can deliver it and order it to minimise risk, uncover unknowns and test assumptions. Releases become proactive with a depth of intent behind the composition of the release rather than the default “conveyor belt” behaviour.
The challenges in a body of work can vary, but here are several different examples:
- Minimising Risk Strategy - A new product is to involve a number of connections to other systems to then derive information and present this to an end user. The challenge here is integration risk, as there is a risk that the collection of other systems will not work together. To neutralise the risk straight away we might organise the Product Backlog and the release strategy to build a basic prototype as soon as possible that has no other functionality than to simply connect to all of the systems end to end. Successive iterations then add additional functionality to the product, but the risk of integrating the systems has been significantly reduced almost immediately.
- Impact Discovery Strategy - A core framework that is used by various other systems needs an enhancement. The main challenge here is the impact of the enhancement upon the other systems, and so the Product Backlog may be organised with regression testing objectives in mind. The regression testing objectives are explicit and define the work needed to achieve them and so reduce the known impact upon the other systems. Here the regression testing objectives may manifest as Sprint Goals to give purpose and direction to the Sprints with a defined outcome.
- Options Strategy - A financial services app that needs to satisfy external regulatory compliance objectives. Whilst the compliance objectives may be quite static in nature, there is some flexibility in how the compliance objectives are satisfied. The Product Backlog in this situation may be organised to allow various options for how the compliance objectives are satisfied. From a seemingly inflexible body of work, we have now been able to provide some options for flexibility and adaptation.
- Feature Discovery Strategy - A smartphone app is to facilitate superannuation contributions for 18 year old users who have just entered the workforce. The challenge here is that we don’t know anything about what features will resonate with this customer segment especially a seemingly boring subject like superannuation, and so we may organise the Product Backlog in rounds of rapid customer testing. These Sprints may involve rapid prototyping and deployment for structured customer testing as a means to answer a specific question or disprove an assumption. Here the Sprint Goals may be the customer testing objectives, which then helps to position the work done in the Sprint to answer questions or prove assumptions.
Generally, it is good practice to consider the challenges in your own Product Backlog and derive a strategic release plan that helps you to learn more, neutralise risk or resolve a challenge. This higher level strategic thinking can tip the balance towards success rather than blindly following the conveyor belt.
Time to Market vs. Value to Market
Most organisations when they start to use Agile approaches tend to focus on efficiency, delivering quickly and improving their time to market. This seems to be a reaction to traditional approaches that yielded lethargic and late delivery, and form their perspective an Agile transition is intended to enable their teams to deliver quicker and on time.
After a while however, it begins to dawn on these organisations that improving their time to market is only one dimension. We still have to deliver something that the customers want and desire, and that is improving the value delivered to the market.
Value to Market involves investing time and effort to understand the customers’ needs through customer research, competitor analysis, testing our assumptions with experiments and refining our understanding with validated learning. This does not necessarily mean that we will be quickest to market, but if we have a good solution that is desirable by the customers, then this can be the differentiator when compared to our competitors. We are not looking to be first in the market to capture the market share, but we might want to be last to market with a killer app that delights and makes the competition redundant.
Multi Release Strategies
When working with multiple releases it is always good to consider whether you are releasing to earn or releasing to learn. The latter implying a rapid release cycle to actively foster and then respond to feedback.
Organisations that are used to infrequent and large releases tend to defend their approach by citing risk concerns and that releasing less often reduces the risk. As a result, the releases tend to be large, cumbersome and often too complex to provide any degree of risk mitigation.
Conversely, releasing more often with smaller releases provides a risk mitigation strategy of managing small amounts of risk more often. The releases are small, easily managed, less complex and we get more practice at releasing, which improves the probability of releasing even faster, especially if this can be automated.
Minimum Viable Product (MVP)
Organisations that are in their infancy with Agile approaches and have traditionally worked with projects and large infrequent releases often misuse this approach and consider the MVP to be the basic release, or in the worst case, a substitute for the word “release”. Conversations often take place about what is in or out of the MVP, which when translated often means which items are in or out of the release.
MVP was always intended as a multi release strategy, with the intention being to provide something into the market quickly that isn’t necessarily going to earn any revenue or even customer loyalty, but the information and feedback gained can be invaluable for the next release in an evolutionary strategy. If some revenue can be earned whilst the project is still running then that can be used to offset the cost of development, which relieves the commercial pressure.
Minimum Marketable Product (MMP)
This is also a multi release strategy with the prime focus being on the ability to learn from customers and end users, testing assumptions and the market with an idea. The feedback translates into hypotheses for future releases and navigates the product towards the customer desires.
Steel Thread
This strategy is an iterative approach that initially looks to build an end to end prototype, that may not necessarily provide much in the way of functionality, but which reduces the risk.
This approach is usually used to neutralise integration risk when building a solution that is going to be used by several systems for example. The key challenge being: will the systems connect together without issues? The approach allows for a basic prototype that, in this case, would form a connection with all of the systems, and by doing so, reveal all of the issues and pain points involved with connecting them.
Once the initial Sprints have successfully connected all of the systems, then the following Sprints may deliver successive iterations building upon the steel thread adding more and more functionality whilst always neutralising the integration risk right from day 1.