Release Strategy - Revision history

Mmusij: /* Delivery Focus */

2022-10-27T01:04:29Z

Delivery Focus

← Older revision		Revision as of 01:04, 27 October 2022
Line 2:		Line 2:

	==Delivery Focus==		==Delivery Focus==
	Teams that only consider a superficial understanding of the work tend to adopt a reactionary ''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 or any sense of adaptation. They drop into a "delivery focus" where the deadline and the number of items delivered becomes more important than what ''value'' is being delivered to the customer. The metrics and efficient delivery becomes more important than the value delivered.		Teams that only consider a superficial understanding of the work tend to adopt a reactionary ''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 or any sense of adaptation. They drop into a ''delivery focus'' where the deadline and the number of items delivered becomes more important than what ''value'' is being delivered to the customer. The metrics and efficient delivery becomes more important than the value delivered.

	There also seems to be an underlying assumption that all items are of equal value, and that more incremental delivery of items equals more value delivered. Which is not necessarily the case. More value delivered is more value delivered.		There also seems to be an underlying assumption that all items are of equal value, and that more incremental delivery of items equals more value delivered. Which is not necessarily the case. More value delivered is more value delivered.

	==Value Focus==		==Value Focus==

Mmusij at 01:03, 27 October 2022

2022-10-27T01:03:52Z

← Older revision		Revision as of 01:03, 27 October 2022
Line 2:		Line 2:

	==Delivery Focus==		==Delivery Focus==
	Teams that only consider a superficial understanding of the work tend to adopt a reactionary '''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 or any sense of adaptation. They drop into a "delivery focus" where the deadline and the number of items delivered becomes more important than what '''value''' is being delivered to the customer. The metrics and efficient delivery becomes more important than the value delivered.		Teams that only consider a superficial understanding of the work tend to adopt a reactionary ''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 or any sense of adaptation. They drop into a "delivery focus" where the deadline and the number of items delivered becomes more important than what ''value'' is being delivered to the customer. The metrics and efficient delivery becomes more important than the value delivered.

	There also seems to be an underlying assumption that all items are of equal value, and that more incremental delivery of items equals more value delivered. Which is not necessarily the case. More value delivered is more value delivered.		There also seems to be an underlying assumption that all items are of equal value, and that more incremental delivery of items equals more value delivered. Which is not necessarily the case. More value delivered is more value delivered.
Line 11:		Line 11:
	Additionally, teams with high value focus will not look to deliver the whole backlog of items, but will instead look to maximise the value from the backlog. When the backlog ceases to yield sufficient value in the eyes of the customer, then they will look to move on to another body of work. Hence, not all of the items on the backlog may be worked on, which can be quite sobering for delivery focused teams.		Additionally, teams with high value focus will not look to deliver the whole backlog of items, but will instead look to maximise the value from the backlog. When the backlog ceases to yield sufficient value in the eyes of the customer, then they will look to move on to another body of work. Hence, not all of the items on the backlog may be worked on, which can be quite sobering for delivery focused teams.

	'''Value''' is also subjective and socially created, which also means that perceived value can change over time. This then prompts teams to continually test their assumptions with customers throughout the work to understand where they are adding value, and where the highest yield of value is on the backlog, which they accept is not a static quality and may change and migrate.		''Value'' is also subjective and socially created, which also means that perceived value can change over time. This then prompts teams to continually test their assumptions with customers throughout the work to understand where they are adding value, and where the highest yield of value is on the backlog, which they accept is not a static quality and may change and migrate.

	==Risk Focus==		==Risk Focus==
	Some bodies of work present key risks, such as, integration risk for a central framework that needs to connect to several services for example, or a new app that has a volatile value proposition in the eyes of the customer. Teams with a good awareness of the key risks in the body of their work will tend to address those risks head on in the early iterations. Neutralising the risks early then takes the anxiety out of the work and the team can then focus on how to make the product better with each successive iteration.		Some bodies of work present key risks, such as, integration risk for a central framework that needs to connect to several services for example, or a new app that has a volatile value proposition in the eyes of the customer. Teams with a good awareness of the key risks in the body of their work will tend to address those risks head on in the early iterations. Neutralising the risks early then takes the anxiety out of the work and the team can then focus on how to make the product better with each successive iteration.

	For the example with the central framework, the integration risk may be neutralised straight away using a '''steel thread''' [[Backlog Strategy Archetypes\|Backlog Strategy Archetype]] that looks to connect each of the services together from the outset of the work using a simple '''ping''' for example. Here the integration risk has been neutralised straight away and now the team can focus on adding value on top of this rudimentary connection in successive iterations.		For the example with the central framework, the integration risk may be neutralised straight away using a ''steel thread'' [[Backlog Strategy Archetypes\|Backlog Strategy Archetype]] that looks to connect each of the services together from the outset of the work using a simple ''ping'' for example. Here the integration risk has been neutralised straight away and now the team can focus on adding value on top of this rudimentary connection in successive iterations.

	The value proposition example may involve initially prototyping multiple approaches for the apps and getting out their and interacting with potential customers to see what resonates and what doesn't. The initial investment to prototype then furnishes the team with more knowledge about what will resonate and what does not, helping them to refine their backlog and adapt their approaches accordingly.		The value proposition example may involve initially prototyping multiple approaches for the apps and getting out their and interacting with potential customers to see what resonates and what doesn't. The initial investment to prototype then furnishes the team with more knowledge about what will resonate and what does not, helping them to refine their backlog and adapt their approaches accordingly.
Line 26:		Line 26:

	==Multi Release Strategies==		==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.		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.		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.

Mmusij at 01:02, 27 October 2022

2022-10-27T01:02:45Z

← Older revision		Revision as of 01:02, 27 October 2022
Line 1:		Line 1:
	[[Category:Agile:Articles]][[Category:Agile]]		[[Category:Agile:Articles]][[Category:Agile]]

	==~~Dynamics and Challenges~~==		==Delivery Focus==
	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 only consider a superficial understanding of the work tend to adopt a reactionary '''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 or any sense of adaptation. They drop into a "delivery focus" where the deadline and the number of items delivered becomes more important than what '''value''' is being delivered to the customer. The metrics and efficient delivery becomes more important than the value delivered.

	~~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~~.		There also seems to be an underlying assumption that all items are of equal value, and that more incremental delivery of items equals more value delivered. Which is not necessarily the case. More value delivered is more value delivered.

	~~The challenges in a body of work can vary, but here are several different examples:~~		==Value Focus==
	* '''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.~~		Teams that have more customer awareness tend to focus on the value of items and how to deliver that value. They will explore, prototype and seek feedback to see what resonates with customers throughout the delivery of the work, and actively adapt what they are doing accordingly. Here there is also a tendency to accept that not all items on the backlog are equal and that some items are more valuable than others, which presents opportunities and options to exploit. More emphasis and effort may be placed on higher value items, and lower emphasis and effort on lower value items.
	* '''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~~.		Additionally, teams with high value focus will not look to deliver the whole backlog of items, but will instead look to maximise the value from the backlog. When the backlog ceases to yield sufficient value in the eyes of the customer, then they will look to move on to another body of work. Hence, not all of the items on the backlog may be worked on, which can be quite sobering for delivery focused teams.

	~~==Time to Market vs.~~ Value ~~to Market==~~		'''Value''' is also subjective and socially created, which also means that perceived value can change over time. This then prompts teams to continually test their assumptions with customers throughout the work to understand where they are adding value, and where the highest yield of value is on the backlog, which they accept is not a static quality and may change and migrate.
	~~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~~.		==Risk Focus==
			Some bodies of work present key risks, such as, integration risk for a central framework that needs to connect to several services for example, or a new app that has a volatile value proposition in the eyes of the customer. Teams with a good awareness of the key risks in the body of their work will tend to address those risks head on in the early iterations. Neutralising the risks early then takes the anxiety out of the work and the team can then focus on how to make the product better with each successive iteration.

	~~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~~.		For the example with the central framework, the integration risk may be neutralised straight away using a '''steel thread''' [[Backlog Strategy Archetypes\|Backlog Strategy Archetype]] that looks to connect each of the services together from the outset of the work using a simple '''ping''' for example. Here the integration risk has been neutralised straight away and now the team can focus on adding value on top of this rudimentary connection in successive iterations.

			The value proposition example may involve initially prototyping multiple approaches for the apps and getting out their and interacting with potential customers to see what resonates and what doesn't. The initial investment to prototype then furnishes the team with more knowledge about what will resonate and what does not, helping them to refine their backlog and adapt their approaches accordingly.

			==Exploration Focus==
			Teams that are not sure of what the problem is let alone what the solution is, may respond to this situation with successive prototypes to learn about problem space and the solution space. Working closely with customers and stakeholders to continually refine their prototypes and narrow down where the value proposition is with regards the problem to solve, and the solution to solve it.

			A backlog of work may well invest initially in prototyping with a view to converging and narrowing the scope to what the problem really is and a valuable solution for it in later iterations.

	==Multi Release Strategies==		==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.		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.		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.
Line 37:		Line 41:
	===Minimum Marketable Product (MMP)===		===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.		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.

	==See Also==		==See Also==

Mmusij at 05:46, 3 December 2018

2018-12-03T05:46:04Z

@@ Line 44: / Line 44: @@
 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.
 ==See Also==
@@ Line 112: / Line 49: @@
 * [[Purpose & Strategy]]
 * [[Evolutionary Strategy]]
 * [[Backlog Strategy]]
 * [[Backlog Strategy Archetypes]]

Mmusij: /* Evolving Strategy */

2018-12-03T05:44:46Z

Evolving Strategy

← Older revision		Revision as of 05:44, 3 December 2018
Line 105:		Line 105:
	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.		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.		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.

			[[File:PO_Strategy-81.jpg\|600px\|Levels of Awareness]]

	==See Also==		==See Also==

Mmusij: /* Minimum Viable Product (MVP) */

2018-12-03T05:41:33Z

Minimum Viable Product (MVP)

← Older revision		Revision as of 05:41, 3 December 2018
Line 30:		Line 30:
	===Minimum Viable Product (MVP)===		===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.		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.

			[[File:Multi Release Strategies.jpg\|500px\|Multi Release Strategies]]

	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.		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.

Mmusij: Created page with "Category:Agile:ArticlesCategory:Agile ==Dynamics and Challenges== Teams that only consider a superficial understanding of the work tend to adopt a “conveyor belt”..."

2018-12-03T05:39:58Z

Created page with "Category:Agile:Articles Category:Agile ==Dynamics and Challenges== Teams that only consider a superficial understanding of the work tend to adopt a “conveyor belt”..."

New page

[[Category:Agile:Articles]][[Category:Agile]]

==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.

==See Also==
* [[Product Owner]]
* [[Purpose & Strategy]]
* [[Evolutionary Strategy]]
* [[Backlog Strategy]]
* [[Backlog Strategy Archetypes]]