Monday, April 11, 2022

Strategy, Backlogs, Sprints and Scrum

Every business operates in a market and develops a business strategy to guide its way forward to capitalize on its strengths and opportunities. The challenge is how to operationalize the strategy in meaningful steps forward to achieve strategic goals as a single operating business.

A company can be focused on how to construct Scrum@Scale with a structured, hierarchical, product backlog that supports the business strategy. The business strategy is supported by a small number of Strategy outcomes. The Strategy outcomes are supported by Theme outcomes. Themes are broken down into Epics, and further into User Stories.  Scrum Teams use this backlog context to plan their sprints and create the highest customer value possible.

Scrum is focused on short sprints with small increments of customer value delivered. The focus of a Scrum-based organization tends to be on ensuring Scrum Teams are always productive. With a two-week sprint, the drum beat of unrelenting sprint planning, daily standups, sprint reviews, retrospectives and grooming under the pressure of burn-down charts and accelerating velocity, organizations often become extremely tactical and struggle to get above the fray.

Organizations who become so focused on the urgent needs of the Scrum Teams, quickly lose sight of the business strategy and long-term customer needs. Enter the Executive MetaScrum or EMS!  The company and Scrum@Scale empowers the EMS with the duties to get above the fray and guide the Scrum organization towards fulfilling the business strategy. However nice this sounds, leaders struggle to translate strategic direction into two-week increments for the Scrum Teams.

Before jumping into more details on how strategy and Scrum work together, allow me to develop an example of a business strategy and groomed backlog for a moment.

Let’s say that the business strategy talks about switching the business to a subscription based, software-as-a-service SaaS model and shifting away from a purchased software license model. Let’s say that the EMS has groomed a roughly one-year out Strategy outcome to get 80% of purchased software license customers using a new SaaS based model. This includes monitoring, support and an update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and, eventually, guides the upgrade process. This Strategy outcome is the first of other Strategy outcomes on the backlog that continues the movement of purchased software towards SaaS. But this also means that any further Strategy outcomes are, at least, over a year away.

The business grooms the Strategy outcome into the following Theme outcomes. The Theme outcomes are abbreviated here and would be expressed in:

‘As a Kubernetes clusters admin overwhelmed by the complexity of dealing with so many applications, I only have 1/100 of my cycles available for any one on-prem application to be updated and need <some customer outcome>, and I know that I’m  done when <some customer acceptance criteria>. ‘ 

For brevity, we have: A) Provide Kubernetes Admin Real-time monitoring and support information and B) Provide Kubernetes Admin update decision making insights, and C) Take over Kubernetes Admin update tasks. These are then broken down into the following Epic outcomes. Abbreviated here as: A1) SaaS set up (basic accounts, licensing access,  customer information), A2) SaaS customer connectivity (SaaS to on-prem SW  communication), A3) SaaS defect connectivity (SaaS to defect DB with correct filters), A4)  SaaS update connectivity (presents basic information to customer on updates), A5) SaaS  support chat, A6) SaaS defect search, A7) SaaS update search, A8) SaaS account resets,  A9) SaaS customer signup promotion discount, A10) SaaS customer survey, A11) SaaS  usage metrics, B12) SaaS defect notification recommendation based upon installed SW,  B13) SaaS update recommendation based upon installed SW, B14) SaaS code currency  metrics, B15) SaaS recording of on-prem SW update metrics, C16) SaaS auto-recording  of on-prem SW update failures, C17) SaaS basic risk assessment of on-prem SW upgrade,  and C18) SaaS basic ‘guided’ update of on-prem SW. Whew, that’s a lot of work to be  done isn’t it.

I’ll spare the on-going details of breaking the Epic outcomes into specific User-Stories and tasks, but you can start to image various Scrum Teams from SaaS development, on-prem SW development, IT operations and support development involved in the on-going work break down into customer story increments, sprint goals, and sprint backlogs. As this work fans out across the organization, the complexity grows. All attention from the business to the individual engineers is consumed by the details.

Not bad, right? You can see how we would go about getting the Strategy done.  Start A Theme. Do A1 then A2, A3, A4 and A5, etc. Follow with B Theme. Do B12, B13, etc. Then on to C Theme and Epics. Easy.

The sequencing of A Theme with Epics, A1, A2, etc. then B Themes and Epics, seems obvious to good planning. Doing out-of-order execution of parts of Themes and Epics seems to defy good predictive planning and good hierarchical structure. No one is that good at planning and grooming at onset, otherwise, we’d all retire at 30. Since we’re not that good at planning and grooming, expect to see a lot of out-of-order execution happening, as well as refactoring as we go. Still easy. Right? 

Well, it’s worse. Since when do we only have one Strategy outcome and three Themes? The reality is that the business has 3 to 7 Strategy outcomes and up to 50+ Themes all happening in parallel. So, the on-prem SW Scrum Teams has 2 or more other Strategies outcomes and maybe 30 Theme outcomes, as do the SaaS Scrum Teams, the IT Scrum Teams, etc. The various stories, dependencies, short-term work, longer-term work start to interact forming a complex array of customer story increments, sprint goals and sprint backlogs. Yikes!

Let’s not also forget about sales deals, revenue pressures, demanding customers, longer term architecture projects, and technical debt. These too are pressing for attention to address their needs. This adds to the near-term focus pressure and takes away from the business strategy. Does this seem real enough yet?

Strategies can be simple. They can be complex. Depending upon our abilities, the execution can be straight forward or prolonged. Depending upon our competitors, the results can be extremely rewarding, muted and/or confounded. Let’s use some games to help us illustrate these points. Consider tic-tac-toe, checkers and chess.

Tic-tac-toe also known as ‘Noughts and Crosses’ or X’s and O’s is a paper-and-pencil game for two players, X and O, who take turns marking the spaces in a 3×3 grid. The player who succeeds in placing three of their marks in a horizontal, vertical, or diagonal row is the winner.

Draughts or Checkers is a group of strategy board games played on a checkered board with 64 squares arranged in an 8x8 grid, for two players which involve diagonal moves of uniform game pieces and mandatory captures by jumping over opponent pieces.

Chess is a two-player strategy board game played on a checkered board with 64 squares arranged in an 8×8 grid. Play involves no hidden information. Each player begins with 16 pieces: one king, one queen, two rooks, two knights, two bishops, and eight pawns. Each piece type moves differently, with the most powerful being the queen and the least powerful the pawn. The objective is to checkmate the opponent's king by placing it under an inescapable threat of capture.

In tic-tac-toe, the strategy is simple. The moves are simple. When the marketplace is simple and the first mover advantage is in play, then focusing everything on the first and second moves determines the winner. There are at most 9 total moves in the game.  Moves are big decisions in the context of a game. In this case, having one Strategy outcome, a few Themes and everyone focused on one or two major outcomes is best. Very straight forward but not a typical business reality for big companies.

In checkers, there are more pieces, and the game board is bigger. However, movements are restricted, and capabilities must be earned. Checkers requires strategy and initiative refinements throughout the game. Strategy can be bold at the beginning until the opponent’s moves take effect. Moves are small and incremental, much like a sprint.  Strategies are brought about by a series of incremental moves. Checkers is like a complex business market because players have strategy and potentially one or more outcomes they are trying to bring about. However, it can also be unlike a complex business market as products have infinite flexibility in how they are brought about and operate in the marketplace.

Are you noticing the pattern? The game board, opponent, strategy, play outcomes, pieces and moves are akin to a market, competitors, strategy, Strategy outcomes, Theme outcomes, and sprints delivering incremental customer value, respectively. 

Let’s keep this pattern in mind as we look at chess. Chess is like checkers, except there are various capabilities of six game piece types. Pawns are numerous but are restricted to forward movement, one space at a time. The queen is most powerful as she can move any number of spaces in any direction per move. The other pieces have capabilities in between these two. The game strategy must take the game pieces capabilities into account and engage them smartly. Constant monitoring and adjustments are made to strategy and outcomes as the other player’s make their moves. Moving a piece to a desired location may take moves of other pieces before the desired piece can even move, during which time, the opponent is also making moves. This complexity is more like a business market and competitors. While we want to deliver certain outcomes, we’re inhibited and/or enabled by our capabilities, we must keep certain pieces on the board viable as we develop the next plays for other pieces, yet to be engaged in the game. We may be focusing on one area of the game board while our competitor is focused on another. While moves are technically visible, the strategy is invisible and constantly being re-evaluated. Every play, every sprint, seems minor but is important for the strategy of the long game.

Like all analogies, the chess game isn’t a perfect comparison to a real business strategy or market, but it illustrates well the value of constant re-evaluation of strategy and the cost/necessity of strategic change. It also demonstrates well how minor moves can upset an opponents’ strategy and/or outcomes. The most important lesson here is that chess provides a well-known, learning framework to explain how strategy relates to Strategy Outcomes to Themes Outcomes to Epics Outcomes to Stories (completed incrementally with each sprint), can build into a powerful market force.

Back to our earlier example, where our Strategy outcome is ‘to get 80% of purchased software license customers using a new SaaS based model, within a year’. Let’s call our Strategy S6 outcome as the following:  A monitoring, support and update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and eventually, guides the upgrade process

Adding complexity, let’s say that we have 5 other Strategy outcomes, S1 to S5. For ease, each Strategy outcome relates to a specific software offering that we already have (S1 to S5) or will have (in the case of S6). There’s no need to specify the S1 to S5 Themes and/or Epics outcomes in detail here, except to note that they have similar complexity of Themes, Epics, etc. as S6 has.

If we continue with the chess analogy, our marketplace is the chess board, and our major competitor is our opponent. We and our opponent have our products and/or offerings in the marketplace and are investing in them. The changes in the products reflect the piece moves.

Imagine that we have our offerings reflected by our Strategy outcomes that we eventually want to achieve over the course of the year (the game period). S1 to S6 outcomes are positioning of our six key pieces in the marketplace by year end. This means capability in position to take action for the coming year. (I’m using a year as a game play horizon for this post.) 

Now, we must move our offerings to their associated Strategy outcomes through a series of moves based upon our capabilities, in the given period. While our business will worry about each Strategy outcome, for the purposes of this paper, we are going to let S1 to S5 randomly impact our ability to get S6 in position by year end (the Strategy outcome).  Remember, we will also have impacts to our S6 outcome caused by our competitors moves. 

The last part of the setup are the moves. A move is taken at the end of a two-week sprint with every Scrum Team creating Definition of Done-Production Ready (DoD-PR) increments. This completeness of increments is critical to the game because partial moves or the inability to move a piece when needed, would undermine the game.  Equally, because we’re doing mature Scrum, each offering is ready to be moved at any moment in time. We are always in production-ready quality at the end of each sprint cycle for all offerings. 

The point of small increments being DoD-PR at the end of each sprint for all offerings cannot be stressed enough here. Having work-in-progress (WIP) preventing us moving forward on the strategy, would be akin to moving a chess piece back and forth on the game board because that’s the only move available. Consider the cost of these wasted moves during the game.

Let’s look at how we’ll bring about our Strategy S6 outcome during the year using two week sprints or moves. 

Remember our S6 Outcome is: ‘80% of purchased software license customers using a new SaaS based monitoring, support and update tool that automates defect queries, recommends updates, assesses the likelihood of a successful upgrade and, eventually, guides the upgrade process.’

S6 THEMES are: 

A) Provide Kubernetes Admin Real-time monitoring and support information

B) Provide Kubernetes Admin update decision making insights

C) Take over Kubernetes Admin update tasks

S6 EPICS are: 

A1) SaaS set up (basic accounts, licensing access, customer information)

A2) SaaS customer connectivity (SaaS to on-prem SW communication)

A3) SaaS defect connectivity (SaaS to defect DB with correct filters)

A4) SaaS update connectivity (presents basic information to customer on updates)

A5) SaaS support chat

A6) SaaS defect search

A7) SaaS update search

A8) SaaS account resets

A9) SaaS customer signup promotion discount

A10) SaaS customer survey

A11) SaaS usage metrics, 

B12) SaaS defect notification recommendation based upon installed SW

B13) SaaS update recommendation based upon installed SW

B14) SaaS code currency metrics

B15) SaaS recording of on-prem SW update metrics

C16) SaaS auto-recording of on-prem SW update failures

C17) SaaS basic risk assessment of on-prem SW upgrade

C18) SaaS basic ‘guided’ update of on-prem SW.

For simplicity, I have clocked the S1 to S6 position changes for each sprint or move. One could imagine any one of these taking more/less time, and you see the pattern laid out to bring about the Strategy outcomes.

Strategy 

Position 

Moves

S6

1st 

Get A1, A2 done by the SaaS and IT Scrum Teams

2nd 

Include SaaS A) in all S1 to S5 offerings’ licenses and drive volunteer customers to sign-up

3rd 

Get A3, A4 and A8 done

4th 

Get A6, A9 and A10 done, include SaaS A) discount if customers sign up account to use defect DB tool, incremental discount for update usage, and a final discount for automated updates.

5th 

(and next position for S1) Get A6 done for offering S1

6th 

(and next positions for S2 and S3) Get A6 done for offerings S2 and S3

7th 

Get A5 done, drive usage as high as possible by offering support discount for customer defect queries 

8th 

(and next positions for S4 and S5) Get A6 done for offerings S4 and S5

9th 

Get A11 and B13 done.

10th 

(and next position for S1) Get B13 and B12 done for S1.

11th 

(and next position for S2 and S3) Get B13 and B12 done for S2 and S3

12th 

(and next position for S4 and S5) Get B13 and B12 done for S4 and S5

13th 

Get A14 and B15 done

14th 

(and next position for S1) Get B15 done for S1

15th 

(and next position for S2 and S3) Get B15 done for S2 and S3

16th 

(and next position for S4 and S5) Get B15 done for S4 and S5, get B13 and C16 done

17th 

(and next position for S1) Get B13 and C16 done for S1

18th 

(and next position for S2 and S3) Get B13 and C16 done for S2 and S3

19th 

(and next position for S4 and S5) Get B13 and C16 done for S4 and S5, get C17 done

20th 

(and next position for S1) Get C17 and C18 done for S1

21st 

(and next position for S2 and S3) Get C17 and C18 done for S2 and S3

22nd 

(and next position for S4 and S5) Get C17 and C18 done for S4 and S5

 

Did you keep track of all the moves and complexity in the 22 sprints? Pretty difficult but if you do tick off the Themes and Epics, you see that by year end, S6 is in good shape to fulfill the outcome.

Now, try to imagine a situation anywhere above where we are unable to deliver our next move. Having work partially complete (WIP) does this. Then imagine the accumulation of this WIP preventing other pieces from moving. See how much more complex the sequencing becomes. Therefore DoD-PR and small increments must be reached and maintained across the Strategies and Scrum Teams.

Now let’s see how much you were following.

Did you notice that A7 was not implemented? As we laid out the steps, the plan was modified to no longer allow the customers the ability to query for updates (the feature usage was expected to be short lived, and the feature wouldn’t drive any incremental customers to sign up). Not doing A7 is not a failure, rather, it is a saving. Doing something unnecessary is a form of waste. Seeking these refinements during the year means retiring Strategy outcomes faster. 

Did you notice that measurement of the Strategy outcome A11, was not completed until the 9th move? While critical to management and/or the outcome, it was deemed less valuable until enough of the SaaS offering was completed with the S1 to S5 offerings’ work was integrated before work on measures was taken on. If necessary, the A11 work could have been moved out in time as needed.

Equally, you can imagine that as we started to work this plan, that the competitor of the S2 offering makes a change, putting pressure on the business to bring our S2 offering to market sooner, even to the point of delaying other offerings to the following year.

Also, you could imagine that while we’re clocking away incrementally, that S5 work is always highly problematic due to its extreme complexity. The plan could be re-worked to move all S5 work to beyond the S6 outcome period to isolate this risk. We could even go further by deciding to stop all work on S5, effectively, sacrificing S5 to the market forces in order to ensure S1 to S4 and S6 outcomes.

Next, imagine that the other Strategy outcomes have an equally detailed sequence of moves, internal difficulties and competitors moves to consider. You can see why as we’re engaging the marketplace competitor, we must continuously reconsider the moves, reconsider the ordering, and/or reconsider the Strategy outcomes.

What makes this all possible is that the ordering is thought through and written down, moves are small production increments, and when change is needed, the context and impacts are readily understood. The changes can be communicated with the rationale across all Scrum Teams consistently, so everyone knows the state of play.

Equally, you can see why the Executive MetaScrum (EMS) review of strategy and Strategy outcomes is both constant and on-going. 

The EMS role is to reconsider with each sprint, the validity of keeping Strategy outcomes unchanged and the Theme outcome priorities. This does not mean changes with each sprint. The EMS must even be open to retirement of a Strategy when there is sufficient progress made, and the business needs another Strategy outcome started. 

The metametaScrums’ reviewing Strategy outcome fulfillment is equally engaging for their level of work. Same for the metaScrums at the Epics and User-Story level. You can see why each Scrum Team reaching production-ready for each User-Story within a sprint helps the business’ flexibility. Equally, incremental progress of Epics aids the understanding of progress on Themes, which aids the understanding of progress on Strategies so each level of metaScrums make the right decisions on retirement, changes and on bring forward new outcomes.

While in our example, we set the Strategy S6 outcome to be ‘80% adoption’, you could see that goal raising or lowering during the year, based upon strategy and/or other Strategy outcome changes. Additionally, had we hit 90% adoption with just Themes A and B, we might have delayed the work on Theme C and moved out the associated discounts to help profit margins in the current year. 

This raises the point that often Strategy outcomes are ‘gray’ because of the time horizon (a year out) and unknown nature of the game play during the year. While 80% is concrete, the EMS retains the ability to adjust the goal and/or outcomes as the year plays out. 

Does this mean that Annual Planning cycles are meaningless to the business?  Annual Plans remain critical to set annual goals and align various functions like Sales to reduce on-going thrashing and churn. Annual Plans do change, albeit infrequently, as the year progresses, and new understanding of reality happens. You can imagine that while Annual Plans may change infrequently, that Strategy outcome changes might occur a bit more frequently, that Theme outcome changes might occur much more frequently and that Epic outcome changes happen very frequently. The key is constructing a systematic and meaningful way of assessing, controlling and communicating the changes. 

Finally, let’s head back to tic-tac-toe and checkers. While these games are simpler and the strategies to win are easier to master, there is less flexibility to tolerate mistakes or to overcome obstacles as they materialize. The challenge of chess is its flexibility is derived by its complexity to bring about the outcome. Chess requires a deeper comprehension of the game, the pieces, the strategy and each move. Winning in a multi-billion dollar marketplace requires a similar deep comprehension. 

Every move must count!

2 comments:

  1. I am thinking, did you consider the difference or the coliving of the strategy together with Objectives? For me the Strategy is quite close to the Key Results which leads me to ask about the objectives than. Basically I am trying to challenge this strategy usage with the OKR framework.
    Another question - maybe I missed it - who creates the strategy? Are the team members involved to feel the ownership over there?

    ReplyDelete
  2. Strategy, at its simplest level, is the why and how a company approaches the market. As part of the how, a company plans a series of outcomes that can be expressed as OKRs, or, as this paper uses, strategic outcomes (80% of customers using aaS offering). Some OKRs will be product development oriented and expressed as theme outcomes for the highest-level product backlog outcomes.

    As to how a strategy and OKRs (strategic outcomes) are generated, I agree that using a participation approach yields the best outcomes and highest ownership.

    ReplyDelete