Earlier this year (Mar 2016) I had the opportunity to run a workshop I created at Alistair Cockburn’s Agile Masterclass in Sydney. The workshop demonstrated how to create and use a Story map. However it also tied in two additional planning techniques that I’ve found extremely useful and lightweight. These techniques provide additional focus on the use of risks and strategies to decide on a course of action for a team.

A common challenge while planning is getting the right balance between top-down and bottom-up planning. Purely top-down plans suffer from not being based in reality, while purely bottom-up plans can be so specific you lose flexibility in achieving your outcomes.

The tendency is for teams to get stuck amongst the weeds overlooking common sense strategies to address risks.

By using this set of activities teams can avoid this and start to systematically think about the big picture, align on what is important and agree on a way forward. Blending these additional elements with something like story mapping adds depth to how teams plan.

During the workshop Alistair highlighted that the combination of activities reminded him of John Boyd’s OODA (Observe, Orient, Decide, Act) loop. This led me to think of this approach more clearly as Decision Oriented Planning.

Since then I’ve had the opportunity to teach these techniques at Campaign Monitor and our Delivery Leads use these approaches to help teams make decisions and deliver amazing products.

It was with great relief then, that Jeff Sutherland recently said that OODA was the mindset of Scrum.

The OODA Loop

Informed by his experience at the US Air Force, John Boyd developed the OODA loop and presented it in 1995 in “The essence of winning and losing”. The OODA loop values agility over raw power and has been applied in business contexts as a way of gaining a competitive advantage. By being able to execute an OODA loop faster than a competitor, allows a company to stay ahead of the game, undermining a competitors ability to respond.

As Jeff was an aviator himself, it’s not surprising that OODA was inherently a key influencer of Scrum.

The Elements of OODA

The OODA loop is comprised of 4 majors elements:
Observe — Orient — Decide — Act

In a team environment I explain these four elements as

Observe — Understand the environment
Orient — Align on what is important
Decide — Agree on a good course of action
Act — Do it

In complex changing environments enabling these 4 elements to occur quickly and effectively can allow teams to leverage their broad range of skills and experiences to increase the likelihood of successful delivery.

Although there are different ways to do each of these steps, irrespective of the way you choose, I would encourage you to use something to anchor a team’s focus and visualise what is discussed. This will help enable complex interactions to emerge which would otherwise not occur.

Observing the environment

My preferred approach for observing the environment is Jeff Patton’s Story Mapping approach. This technique has become the defacto standard for visualising product backlogs, and helps teams focus on how a customer interacts with the system.

Story Mapping is awesome as it encourages, amongst other things

• Storytelling as a technique to flush out any gaps in the environment
• A two dimensional backlog enabling better visualisation of priorities and dependencies

It also happens to be an awesome way to observe the environment and what a team will need to deliver to create value.

Orient on what’s important

To me the things you really want to keep an eye on when trying to ship a new product are the factors that could significantly affect delivery be it positively or negatively.

Putting my finance hat on, all of these can be classified as risks because they relate to an uncertainty of some kind.

With that in mind, my favourite approach to orient is the Risk Impact map.

Because it is so simple, it is also extremely powerful.

The Risk Impact map is a tried and tested favourite within traditional project management. Blended with a little bit of design thinking though you can really push its application. Primed with a few simple risk categories, both customer and delivery centric risks can be explored.

Teams are asked to raise any risks they have in any one of four categories.

Desirability — Will a customer want it?
Feasibility — Can we technically build it given our current environment?
Viability — If we build it, will we be able to make money from it?
Consumability — Will a customer be able to find it and consume it?

By providing this starting frame we shift thinking away from mainly feasibility orient risks towards a holistic systems view that helps expose additional risks that would typically remain hidden.

In practice you’ll find risks don’t fit in neat boxes so it’s ok to just pick any of the categories that suits. It’s more important to capture risks and expose them, than it is to perfectly categorise them.

Because your information about the environment is imperfect, don’t worry about finding every risk possible. What your team captures are likely the things that trouble them the most. As long as you revisit the risk map regularly you can operate effectively with a high rate of uncertainty.

With the map completed, teams are challenged with thinking about the smallest thing that can be done to de-risk items that have been identified as the most likely and impactful.

Visually, teams are tasked with taking the items in the top right quadrant and doing the least amount of work possible to shift these left or down.

With this in mind, it’s now time to decide on a plan.

Decide on a good course of action

After having observed the environment and oriented on what is important it can still be difficult to decide on a course of action and understand how it links to achieving longer term goals.

Which strategy of the many available is the best one to use to move forward?

The technique I’ve found the most effective in this space I have named Outcome Mapping.

Using an “envision the end state” approach this technique helps teams decide on an immediate course of action in order to achieve a longer term goal. (This approach is also used in other techniques such as The Future, Backwards and the Toyota Kata to help set direction in complex problem domains).

Outcome Mapping is as simple as drawing a single line starting at now, and ending in the future. Leaders and stakeholders are asked to use post-it notes to identify any key milestones that exist. This effectively sets constraints for the team that they need to achieve. For example a milestone might be “Ship the product by end Mar 2017”, “Be ready for a trade show on 15th Jan 2017” or even “Onboard 5 new engineers by Dec 2016”.

These constraints set an identified end state and when combined with outcome mapping, enables a team to have broad flexibility in determining appropriate action given their environment.

Within the defined constraints, teams are then asked to identify the outcomes that they would deliver in order to meet the desired end state.

For some teams it may help to provide a simple frame for outcomes.

• What would a team implement?
• What information would they get back from?
• What would it validate for them?

Some teams will define a sequential set of outcomes, but other teams will add parallel sets of outcomes identifying work that can be done in parallel, by other teams members or even other teams.

The main benefit of having a plan is its ability to align a team around a course of action, so be flexible with how the plan is created. As long as it is visible and intuitive to the team, there are really nothing that you shouldn’t allow them to do here.

With outcomes defined, it is now highly valuable to ask the team to group outcomes into mini milestones. These mini milestones help identify what a releasable slices is and the mid horizon goals that define what a team is trying to achieve during that period.

I use a 1st Release, 2nd Release, Everything else approach to get teams into the mindset of planning regularly. This helps them avoid attempting to define the mythical perfect plan, and get into a regular cycle of planning out what they are currently working on, and what they thing they will work on next.

Depending on the type of work release slices can really be anything.

Greenfield products often have customer validation, development of prototypes and/or steel threads as the first goals. In established products these are more likely to look like enhancing specific areas of the product, or improving or expanding existing customer journeys.

Acting on the outcome map

Having decided on an agreed outcome map, teams are now ready to act. Teams take the output of the outcome map, and bring it back to the Story map.

The Story Map should reflect the chosen course of action.

Release slices or outcomes are placed to the left of the story map in order. The cards on the right are reordered and sliced further to defined the minimum work required to achieve the desired outcome.

These cards now form the basis for execution with your chosen delivery framework.

Completing any outcome completes a single OODA loop and provides some information that influences future decisions. A team focused on learning will use this information to drive the next decision loop.

Final Note

These activities can easily be completed within a few hours, and set an agreed direction of one or two months.

Accelerating through the OODA loop by regularly reviewing and revising the Risk Impact map and the Outcome map will ensure teams adjusts their direction based on the changing realities of their environment.

All our teams at Campaign Monitor use this approach to ensure we know what reality is. In addition it helps us set a direction that meets the environment we have, not the one we wish we had.

With so many factors affecting delivery, this approach should help your teams to apply a basic OODA loop ensuring that they are always making the best possible decisions available to them.

If you are interested in accessing the Decision Oriented Planning workshop materials please feel free to contact me.

‍