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.
Strategic Awareness
There are different levels of awareness and consciousness about the goals and intent behind a release or Sprint, and how a Product Backlog can be organised to tip the balance in favour of success.
Rules & Constraints
The rules and constraints in a project or program include the deadlines, release milestones and available funds etc. that are in place with a body of work. Here a release may be needed by a target date to synch up with an advertising campaign, or a product needs to be regulatory compliant and meet the expectations of a governing authority for example.
Awareness at this level is quite common and the constraints and rules of the game may be clearly articulated as part of the project or product brief and communicated often.
Risks & Challenges
The risks and challenges of a project or product build may not be immediately evident and may need some insight to derive and understand them. There may be a conscious act to try to define which risks or challenges are present in the work, and then to communicate these to stakeholders and the team.
Being aware of the risks and challenges provides some indications of the hot spots or areas of interest in the backlog that we should investigate further and then figure out how we are going to mitigate or manage those risks.
Value & Purpose
It may take a few Sprints and iterations to figure out where the true value in the work lies, and may not be obvious from the start. We may actually believe that the value relates to an aspect of the work, but then after a few Sprints it becomes clear that it actually relates elsewhere.
For example, a quick exercise with some prospective product owners that I ran a few years ago challenged them to describe the features of a regular online dating application and assess where they thought the customer value proposition was after the user stories were described and arranged in a story map. The expectation was that the value and differentiator of the app was in the strength and accuracy of the profile matching algorithm, that the right people were matched based upon their preferences and other information contained in their profiles. The better and more accurate the algorithm, then the better the application and the value in what we were looking to deliver.
However, surprisingly, as the conversation went on and the story map began to take shape, it turned out that the security of the individuals on their first date was the differentiator in the proposition. The product owners felt that if a first meeting between two people was safe and secure, then there was less of a need to provide the perfect match between people, and actually added the possibility of meeting new people that may not necessarily match all of the criteria in the preferences in the profiles.
Here the value proposition turned out to be in a different place from where we assumed it would be, and this is very common with other projects and programs which need a few Sprints to figure out where the true value proposition lies, and it really helps to get some good feedback from those Sprints to help discover and explore the value.
Sprint Goals
As mentioned previously, Sprint Goals provide a mechanism to indicate the intent behind the Sprint and a reason “why” we are doing the work.
Quite often I’ve seen projects and programs use the Sprint Goal to indicate a list of what they want to do like a shopping list of features or tasks. This may be useful but also only indicates an awareness of what is to be done as opposed to why we are doing it in the first place.
Increasing the level of awareness to consider the positioning and intent behind a Sprint now changes the perspective from considering a Sprint as a simple delivery mechanism to a more complex experiment, objective or a coordinated timebox with an intended impact.
Arranging several Sprint Goals together may well form an evolving strategy with reason and intent behind the Sprints that have evolved from being simple timeboxes adding random improvements.
Combinations, Patterns & Archetypes
There may be some common patterns with how the work and the positioning of the Sprints and their goals are conducted. These patterns or archetypes may be repeatable and indicate a way forwards to understand how to conduct the project or product that is sensitive to the risks and challenges and provides value within the constraints.
To help raise your level of awareness, I have included several archetypes and patterns later in this chapter, which can be used to generate strategic conversation in your teams and challenge your perspectives whilst introducing different approaches to solve your problems.
The list is not exhaustive but does provide a reference point that can then be used to derive an appropriate approach for your situation.
Becoming more aware at this level, then provides some solutions and novel approaches to the work, which may help to influence successful outcomes.
Dynamics
What behaviour would you like to encourage in the way we do the work? For example, we could incorporate lots of informal feedback and experimentation in our Sprints in order to discover what the next great feature should be. In this case, we accept that we don’t know what features will really resonate with our customers, but that we need to employ several techniques to discover them.
This behaviour in the way that we conduct the work should be sensitive to obtaining most value whilst addressing the risks and challenges, and this level of awareness encourages the practices and approaches that we should employ to get the best possible outcomes.
Guiding Principles
This is the highest level of awareness, in that, we are aware of our approach and why it is needed in order to secure a successful outcome.
For example, we may apply such principles as:
- neutralise the compliance risk
- add subsequent value with the remaining Sprints
For a regulatory compliance project or program the focus on firstly being compliant with a manual process or similar in the first Sprint, (neutralising the risk,) removes the pressure and risk away from the product or project, and now we can focus on adding tactical value with each remaining Sprint that are available within the time or cost constraints. For this example, the risk has been addressed right from the first Sprint and so we now have the luxury or releasing at any time with as much added value as we have remaining Sprints.
This level of awareness provides deep insights into the body of work and illustrates a guiding light that indicates why we are conducting the program or project this way in order to secure a successful outcome.
Evolving Strategy
All of the above forms a strategy which can and should also evolve, morph and change over time as more is known about the project or product. The strategy may need to change from time to time as new risks and challenges or value is discovered, and so we should always be listening to the feedback and adapting accordingly in order to remain successful.