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!
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.
ReplyDeleteAnother question - maybe I missed it - who creates the strategy? Are the team members involved to feel the ownership over there?
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.
ReplyDeleteAs to how a strategy and OKRs (strategic outcomes) are generated, I agree that using a participation approach yields the best outcomes and highest ownership.