Strategic Awareness

From AgileMe
Jump to navigation Jump to search


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.

Levels of Awareness

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:

  1. neutralise the compliance risk
  2. 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