100% found this document useful (1 vote)
204 views

Agile Org Guide en

This document provides an introduction to a guide for implementing Agile practices in legacy organizations. It discusses how Agile has been adopted by many legacy companies based on theories and examples from startups, but implementation has often been difficult and a source of friction. The guide aims to help management establish the proper context for Agile, set up effective Agile teams and projects, and provide operational guidance on managing Agile in a practical way that works for both Agile and legacy teams. It also explores the core principles of Agile, including focusing on individuals over processes, creating prototypes, collaborating with customers, and being responsive to change.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
204 views

Agile Org Guide en

This document provides an introduction to a guide for implementing Agile practices in legacy organizations. It discusses how Agile has been adopted by many legacy companies based on theories and examples from startups, but implementation has often been difficult and a source of friction. The guide aims to help management establish the proper context for Agile, set up effective Agile teams and projects, and provide operational guidance on managing Agile in a practical way that works for both Agile and legacy teams. It also explores the core principles of Agile, including focusing on individuals over processes, creating prototypes, collaborating with customers, and being responsive to change.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 88

A PRACTICAL GUIDE TO

IMPLEMENTING AGILE IN LEGACY ORGANIZATIONS


‘IT’S NOT ALL UNICORNS AND RAINBOWS’

In collaboration with Angeliki Papachroni


A Practical Approach To
Implementing Agile In Legacy
Organizations While Eliminating
Tensions And Potential #Fails.

In collaboration with Angeliki Papachroni

2
Welcome

ABOUT THE AUTHORS

LHBS Consulting Berlin is a Strategy and


Innovation firm based in Berlin with offices
in Vienna and Moscow. We work with legacy
organizations to make them more custom-
er-centric and Agile in order to deliver and
capture greater value in the digital age. The
hands on experiences of LHBS in develop-
ing strategies and launching strategically
guided innovation initiatives, have provided
valuable insights on how to balance future
growth opportunities with the effective
exploitation of the core business.

Dr. Angeliki Papachroni is an Associate


Fellow at Warwick Business School, UK.
Her research focuses on strategy and inno-
vation from an organizational perspective
(organizational ambidexterity, strategy
implementation, leadership of innovation).
Angeliki has trained or advised executives
on organizational ambidexterity and stra-
tegic agility.

www.lhbs.com

3
Contents

CHAPTER 1

PROLOGUE 05
CHAPTER 2

AGILE MYTHS 24
CHAPTER 3

THINK. SET. GO. 27


CHAPTER 4

EPILOGUE 80

BIBLIOGRAPHY 86

4
CHAPTER 1

PROLOGUE

5
CHAPTER 1 – PROLOGUE

Why have we written this guide?

6
CHAPTER 1 – PROLOGUE

Over the last few years, Agile has received a lot of attention
and lip service from very ideological perspectives.

Agile has successfully crossed over from the software devel-


opment community to the legacy, non-development commu-
nity. Many legacy organizations have experimented with this
relatively new way of working. They have applied Agile to their
overall business strategy, service innovation, marketing and in
some cases, the framework has also drawn interest from HR.

In the last few years, we have worked hands-on with some of


the leading organizations in Europe to help with their Agile
Transformation. We have designed transformation strate-
gies and approaches to help set up, guide and coach Agile
teams. This has been done with a view to align teams on what
Agile actually means within an organization. We have had
the chance to lead these projects across a wide spectrum of
industries, yet the patterns of issues are quite similar across
the board.

Most companies have been inspired by books, speakers, theo-


ries and examples from the start-up world. Only a few orga-
nizations, however, have had practical cases and examples
from the non start-up world to draw on as inspiration. In our
experience, the process of implementation has often been
painful and a source of friction amongst teams, functions and
leadership.

7
CHAPTER 1 – PROLOGUE

The thing that passes for “Agile” today


is too often a watered down version of
the original dream. Worse still, we don’t
have a word to describe that shining
city we all want to get to. Russians have
an expression for this:

“We wanted the best, it turned out like always.”

Viktor Stepanovich Chernomyrdin,


Prime Minister Russia, 1998-1999

That is why we have developed the Agile Org Guide. This guide
is not about how to run Sprints. We have a separate ‘how-to
guide’ for that called The Agile Sprint Guide (see page 85 to
download the Agile Sprint Guide.)

It is intended to provide a practical approach for manage-


ment to be better informed on how to:

•• Establish the context for the implementation of Agile


(Think).
•• Set the stage for Agile projects and teams (Set).
•• Run the successful operational management of Agile
teams (Go).

8
CHAPTER 1 – PROLOGUE

THINK. SET. GO.

Equally important, the Agile Org Guide intends to provide


ideas and best practice for Agile and legacy teams to live
symbiotically and play-to-win together.

This guide is filled with personal experiences, pitfalls and


best practices. We believe it will put Agile into a more practi-
cal, manageable and valuable light. It will help management
and transformation teams who may be both excited and
challenged by an Agile implementation journey.

9
CHAPTER 1 – PROLOGUE

What is Agile:
Putting theory into practice

“The highest priority,” as the Agile Manifesto states, “is to


satisfy the customer by delivering customer value.”

SIDE NOTE

Customer value is at the center of Lean. Lean goes


hand-in-hand with Agile and is often misunderstood.
It has often been thought to represent the elimina-
tion of resources to the point that you have the bare
bones required to achieve results. The truth is that
Lean ensures that you eliminate anything that does
not generate customer value. Contrary to the initial
impression, it may mean that additional resources
such as people, funds and effort, should be added to
generate customer value.

Agile is a mindset that is drastically different from the tradi-


tional organizational mindset and approach. This is outlined
by the four Agile principles:

10
Focus on individuals and Create working prototypes over
interactions rather than processes comprehensive documentation.
and tools.

INDIVIDUALS WORKING
AND INTERACTIONS PROTOTYPES

PROCESSES AND COMPREHENSIVE


TOOLS DOCUMENTATION

Customer collaboration over Responsive to change over


contract negotiations. following a plan.

CUSTOMER RESPONSIVE
COLLABORATION TO CHANGE

CONTRACT FOLLOWING
NEGOTIATIONS A PLAN

11
CHAPTER 1 – PROLOGUE

12
CHAPTER 1 – PROLOGUE

Focus on individuals and interactions


rather than processes and tools.

Individuals who collaborate, interact and contribute comple-


mentary skills, will self-organize to solve a challenge in the best
way possible. The cross pollination of ideas without process
and tool related constraints leads to this. Each individual can
bring their own expertise to the table and experiment with
diverse approaches.

13
CHAPTER 1 – PROLOGUE

14
CHAPTER 1 – PROLOGUE

Create working prototypes over


comprehensive documentation.

The development of working prototypes will allow customers


to test things they can give real feedback to. This form of feed-
back will be generated based on usage, utility, attractiveness
and other attributes. Teams might start with simple proto-
types such as concept boards, wireframes, mockup landing
pages and then progress to more advanced test versions. This
eventually results in Minimum Viable Products that are ready
for a market launch. The idea is to continuously test tangible
‘products’ and learn as much as possible along the way.

15
CHAPTER 1 – PROLOGUE

16
CHAPTER 1 – PROLOGUE

Customer collaboration over contract


negotiations.

Agile encourages teams to build things based on an assess-


ment of demand and customer expectations. This is done
through the use of smart research and observation as the
basis for product development. The focus here is to find out
what people need, first-hand, to help build something. This
contrasts f rom traditional approaches which involve the
creation and sale of a product based on assumptions.

This is best captured in the sentiments shared below:

“Life is too short “Making things that


to build things people want is better
nobody wants” than making people
want things”
Ash Maurya, author of
the book: Scaling Lean The Smithery
(https://medium.com/smithery/
making-things-451aacaec170)

17
CHAPTER 1 – PROLOGUE

18
CHAPTER 1 – PROLOGUE

Responsive to change over following


a plan.

Many projects start with the daunting request to create “the


next big thing.” A team can only assess whether a project
was a success, failure or marginal failure after the initial build,
launch and post-launch analysis. Agile assumes that things
change and that at any one point, teams work with real-time
knowledge. Agile teams progressively build multiple iterations
and test their assumptions on an ongoing basis before they
launch the product. This mitigates the risk of huge invest-
ment on ideas “we think might work” at the end of the long
development cycle.

19
CHAPTER 1 – PROLOGUE

CASE

In 2014 WhatsApp, a company with over 417 million


users and only 55 employees, was acquired for $19
billion by Facebook. WhatsApp has now become
a utility application in both emerging and mature
markets. After the company successfully disrupted
the SMS messaging platform of telecom companies
worldwide, WhatsApp turned its attention to voice
calls. As a result, telecom companies were forced to
adapt, and phone plans were changed to offer more
data and unlimited calls for less money. This became
the new norm across the industry.

Q – Why did the industry not react to the increased preference


for messaging even when it was clear that customer prefer-
ences were shifting? Why did they not simultaneously exploit
SMS technology and at the same time conduct experiments
that explored new ways of delivering a new, more contempo-
rary and monetizable messenger offer?

A – These companies did not have the right balance of exploita-


tion (making money now) and long term experimentation
(securing future revenue streams).

20
CHAPTER 1 – PROLOGUE

Remember that Agile is not an end in


itself. It is an embedded mindset of
innovation, whether it be incremental
or disruptive. Agile is about focused
experimentation within the right
context.

Chapter 3 discusses in more detail how to balance the


exploration of new opportunities for innovation (Innova-
tion Engine) and the exploitation of its well-establish core
business model (Performance Engine).

21
CHAPTER 1 – PROLOGUE

PRO TIP

Don’t let the future catch you by surprise: innovate


without killing the Performance Engine. That being
said, don’t let the Performance Engine choke the Inno-
vation Engine. Today’s imperative is to build ambidex-
trous organizations that manage both exploration and
exploitation simultaneously.

22
CHAPTER 1 – PROLOGUE

PRO TIP

How not to design the balance

Agiles Projekt

23
CHAPTER 2

AGILE
MYTHS

24
CHAPTER 2 – AGILE MYTHS

Agile is just about speed. No, it’s about


customer understanding, flexibility and
resourcefulness. It‘s about the delivery of
more value with less work.

Agile is a sprint. No. It’s actually a marathon.


It’s an ongoing way of working to continu-
ously deliver customer value.

Everybody will like you. Not necessarily.


You might piss people off! But never your
customers!

If you’re doing Scrum, you are doing Agile.


Not quite. Scrum can be a part of Agile but
it will not transform your organization.

Agile means no governance. Wrong. With-


out proper governance projects and teams
will fail.

25
CHAPTER 2 – AGILE MYTHS

If we follow the Spotify model we will be


fine. Hmmm...every organization needs to
find their own unique way to start and scale
Agile. One size does not fit all.

Agile means no planning. Well, no. High-


level planning is completed at the begin-
ning of an Agile project and is continuously
elaborated upon throughout as new infor-
mation becomes available.

Agile means tearing down what we have


and starting new. That would be crazy.
There is a reason why the Performance
Engine exists. It’s a building block of the
organization.

“In preparing for battle I have always


found that plans are useless, but
planning is indispensable.”

Dwight D. Eisenhower

26
CHAPTER 3

THINK.
SET.
GO.
A Practical Approach
To Implementing Agile

27
CHAPTER 3 – THINK. SET. GO.

THINK.

28
CHAPTER 3 – THINK. SET. GO.

29
CHAPTER 3 – THINK. SET. GO.

THINK. SET. GO.

Think Before You Act.


The Role Of Strategic
Alignment.

Evolution Revolution

Corporate Start-up
Ambidextrous

Control & Monitor Trial & Error

Scale Speed

Cause & Effect Cause an Effect!

Optimize Create

Cost Breakthrough

30
CHAPTER 3 – THINK. SET. GO.

When you embark on an Agile journey, you will often stumble


upon some key misconceptions about what Agile is and what
it entails.

Agile is not only about change. Contrary to dominant think-


ing, Agility is not only about change, speed and variation. Agil-
ity without stability and consistency leads to chaos, inertia and
the waste of valuable resources. The incorporation of change
within a stable environment however, is rarely a smooth and
frictionless experience.

Agility is not merely about the disruption of your business. It


is about the discovery of a way to create new, customer-cen-
tric, value-adding products and services while at the same
time ensuring that the organization exploits its existing core
business.

SIDE NOTE

Ambidexterity:
Being able to use both your right and left part of your
brain equally well. In business settings, ambidexter-
ity is defined as an organization’s ability to be both
innovative and efficient at the same time.

31
CHAPTER 3 – THINK. SET. GO.

The response to this dual demand is often referred to as ambi-


dexterity; to be equally dexterous in both exploration and
exploitation. Tensions do however arise between different
parts of an organization when trying to be both efficient and
explore new opportunities in the business environment.

Synergy between Performance & Innovation Engine

EXPLORE & REINTEGRATE


BACK INTO THE BUSINESS

EXPLORE &
PERFORMANCE EXPLOIT & INNOVATION DELIVER NEW
ENGINE SUPPORT ENGINE BUSINESS
VALUE

SUPPORT & FUND

32
CHAPTER 3 – THINK. SET. GO.

Agility Tensions Due To Different


Operating Systems

Innovation Engine Performance Engine


Operating System Operating System

Customer Driven Strategic Orientation Business driven


Exploratory Innovation exploitation of effi-
ciencies

Flexible, cross-func- Structure Centralized, top-down


tional teams structure

Iterative, empirical, Processes Rigorous, comprehen-


cross-functional sive, linear

Collaborative, having Decision Making Top down, hierarchical


senior managers with
multiple roles, respon-
sibilities, goals

Taking advantage of Strategic Planning Planned, structured,


opportunities as they clock-based
emerge, continually
improving, adapting,
event-based

Thriving on change Culture Thriving on stability


and variability and control

Building on new and Core Competencies Building only on exist-


existing skills and ing skills and compe-
competencies tencies

33
CHAPTER 3 – THINK. SET. GO.

Some academics and even practitioners have expressed


doubts whether companies can successfully manage both
exploration and exploitation. They suggest focusing on either
the Performance or the Innovation Engine. We believe that the
two can and should coexist as drivers of the current and future
business. The remainder of this guide outlines some thoughts
on making this coexistence as frictionless and mutually bene-
ficial as possible when implementing Agile as a methodology
for experimentation.

34
CHAPTER 3 – THINK. SET. GO.

Agile Theatre

How to avoid “Agile in name only”


or “Agile theater”

Agile Transformation is not a project, a set of processes or a


new structure. It is a dynamic balancing act to:

•• Build, protect and empower the space for experimentation,


i.e. your Innovation Engine
and
•• Support, align and grow the space for exploitation, i.e. your
Performance Engine

35
CHAPTER 3 – THINK. SET. GO.

Success Trap & Failure Trap

Performance Engine
Innovation Engine

N
IO
AT
LOR
P
EX
CH
MU
O
TO

Failure Trap
LEGO

CASE

Remember the failure traps: Between 1993-2003 LEGO


went on a spiral loop in pursuit of a far-reaching spec-
trum of innovations. This diluted the brand, alienated
the customers and wasted valuable resources. Only
after it returned to its core value proposition did LEGO
manage to innovate successfully again.

36
CHAPTER 3 – THINK. SET. GO.

TO
O
MU
CH
EX
PL
OI
TA
TIO
N

Success Trap
KODAK

CASE

Remember the success trap: Does anyone remem-


ber KODAK? While they focused on protecting their
competitive advantage, the world changed.

37
CHAPTER 3 – THINK. SET. GO.

Avoiding success traps and failure traps.


Exploitation and exploration are often regarded as contradic-
tory demands. However, too much exploitation can lead to
success traps whereas too much exploration can cause failure
traps. The key to avoiding such strategy traps is to shift from
an either/ or to a combined approach.

PRO TIP

Agile is not easy. It is based on the balance of contradic-


tory demands at all levels of the organization (formal
structures, work processes, belief systems). It also
requires senior management to act as the corporate
glue that fosters synergies and links between the differ-
ent parts of the organization.

PRO TIP

Innovation includes the acceptance of failure at a quick


pace. It’s about making many small bets and learning
what works. Focusing only on ‘cool things’ leads to
forgetting about the core business. In order to have a
sustainable strategy, make sure to consider when and
how new offers will be integrated back into the Perfor-
mance Engine for scale.

38
CHAPTER 3 – THINK. SET. GO.

Building Agility into your


organization is based on the
continuous alignment between:

Strategy:

•• Setting a strategy for both exploration and exploitation


•• Making difficult choices and challenging dominant
thinking
•• Ensuring Agile projects are not treated as a side project
but as a key component of the business strategy

Operations:

•• Changing and/ or adapting the organizational structure,


processes and systems to align with changing strategic
priorities
•• Identifying dependencies, complexities and bottlenecks

Leadership:

•• Engaging in ambidextrous, combined thinking


•• Coordinating strategy and operations to changing,
interdependent conditions to ensure consistency

39
CHAPTER 3 – THINK. SET. GO.

Effective Agility

Strategy

Operations Leadership

40
CHAPTER 3 – THINK. SET. GO.

Strategy Diagnosis:
How to build an Innovation Strategy.

Agile is not a strategy. However, you need one to make sure


that you unlock your true potential for innovation. Before
you embark on an Agile Transformation journey, these are
the questions you should ask:

• Have we defined what business we are really in or could


potentially be in? Are you an auto manufacturer or a plat-
form for mobility? Many businesses underestimate the
deeper power of their offering. Stretching it up to a more
open concept can help drive the core business as well as
open the possibilities for new innovation playgrounds.

• Who are our main competitors? Where do we expect


disruption to come f rom? With that understanding in
hand, you can clearly identify innovation opportunities.
For example, telcos no longer compete with other telcos
exclusively for market share but with Google and OTT’s
(Over-The-Top content) for a share of revenue of new busi-
ness models.

41
CHAPTER 3 – THINK. SET. GO.

• Do we have a guiding principle for our Innovation Strat-


egy? Are we identifying the best playgrounds for sustain-
able and profitable innovation?

Defining the key strategic orientations and business hori-


zons is a critical success factor for an Agile transformation.
These include: supporting your existing business, growing
your existing business and finding new opportunities for
growth through disruptive innovation. A rigorous analysis
of the above will help identify the playgrounds with the
highest potential.

PRO TIP

Strategic planning may not necessarily be attached


to an annual calendar. Strategy should reflect the way
consumers and markets behave and unfold. Consider
doing emergent Road Maps that plot the dynamic
evolution of the company’s vision rather than explicit
3 or 5 year plans.

42
CHAPTER 3 – THINK. SET. GO.

PRO TIP

Budget allocation and consideration is critical. Differ-


ent problems require different solutions. A well-defined
innovation scope sets clear boundaries and opportu-
nities between the PE and the IE. You can select and
support a few ideas that represent blue sky innovation
opportunities (10%), have a portfolio of midrange ideas
that expand your core business (20%) and a broader
range of ideas that focus on supporting your core busi-
ness (70%).

10% NEXT
PE IE BIG THINGS

20% EXPAND
IE THE CORE

70% SUPPORT
IE THE CORE

(Thickness of lines represent dependencies on the


organizational structures & processes).

43
CHAPTER 3 – THINK. SET. GO.

PRO TIP

To explore ‘the next big thing’ give passionate people


areas to explore, a budget and 6-10 Sprints to develop
a working prototype and a business case. If the idea is
solid, devote sufficient resources to fully develop the
product or service. If they fail, you have learned fast and
can move on to the next area to explore.

44
CHAPTER 3 – THINK. SET. GO.

What capabilities do we have, do we need to evolve or do


we need to build in order to make it all happen?

Once you have defined your innovation playgrounds you need


to take a long and hard look at the capabilities of your organi-
zation that are relevant in each case. Some capabilities might
already be there, others might need to be evolved. In some
cases, new innovation playgrounds will need a completely new
set of capabilities alongside the existing ones. As capabilities
are not built overnight, a solid Innovation Strategy will help
you anticipate and manage hurdles successfully.

45
CHAPTER 3 – THINK. SET. GO.

So now you have a Strategy. But what


about implementation? Conducting
an Operations Sanity Check

In order to put your strategy into action, here are some critical
questions you should consider:

•• Are we prioritizing innovations and resource management


in the best way possible?

•• Is innovation strangled by the same tight planning,


budgeting and reviews applied to the existing business?

•• Are managers rewarded for doing only what they are


committed/ used to doing? Are they discouraged from
making changes as circumstances change?

•• Do we have a system of governance?

46
CHAPTER 3 – THINK. SET. GO.

Strategy implementation is also


about Leadership: Taking the
temperature of leadership and
leadership styles

Aligned and supportive leadership is key to successfully build-


ing an Agile Organization. Some key questions to consider
and answer include:

•• How aligned are we on the meaning of customer centric-


ity and the key principles of Agile? What is the impact on
organizational values?

•• How good is management at knowing when to step back


and when to step up and empower teams?

•• Do we have the most efficient way to communicate inno-


vation scope and success internally to galvanize further
support? Are we transparent in our internal communica-
tion in general?

•• Have we chosen the right leadership with proper HR


engagement?

47
CHAPTER 3 – THINK. SET. GO.

SET.

48
CHAPTER 3 – THINK. SET. GO.

49
CHAPTER 3 – THINK. SET. GO.

THINK. SET. GO.

Set The Scene For Success

By now, you have asked the right strategic questions to make


sure that your organization aligns with the Agile philoso-
phy: you have a better understanding of your competitive
landscape and core competencies and have reconfirmed
your commitment to customer centricity. You have identi-
fied your innovation playgrounds and business horizons and
have agreed on an Innovation Strategy. Congratulations! Your
planning is complete.

Implementation of your strategy and implementation of Agil-


ity is however the most difficult part. Poor strategy execution
is the key reason why strategies fail and often this is due to a
lack of clear and well defined implementation steps. In order
to avoid the trap of “failed strategy due to failed implemen-
tation” this section provides a step-by-step guide of how to
put your strategy into action.

50
CHAPTER 3 – THINK. SET. GO.

From Innovation Strategy


to Implementation

STEP 1
Set the Project Strategy.

In order to start your Agile project you need to have clearly


defined a business need or a vision that your project will be
addressing. A straightforward way is to use what’s called the
Elevator Pitch. Key questions to answer include:

•• Who is our target customer?


•• What need are we servicing?
•• What will the product potentially look like?
•• What is the potential key product benefit you will provide?
•• How is your product or service different from competitors?

At this stage, the leadership team and key stakeholders should


be aligned to have a common understanding of the strategy.

51
CHAPTER 3 – THINK. SET. GO.

STEP 2
Map your strategic objectives to specific initiatives.

After the strategy is confirmed, this needs to be translated


into a set of specific initiatives. At this point you could use a
product roadmap: a high-level view of the requirements for
your project with a rough estimate of when each of them is
developed. The focus should be on the identification, prioriti-
zation and the rough estimation of the effort each component
of your product will require on the way to making a usable
product. For each of these initiatives, you can consider adding
5 key data points: Date, Name, Goal, Features, and Metric.

PRO TIP

Product Management expert Roman Pichler, suggests


that you work with a goal-oriented product roadmap:
“Goal-oriented roadmaps focus on goals, objectives,
and outcomes like acquiring customers, increasing
engagement, and removing technical debt. Features
still exist, but they are derived f rom the goals and
should be used sparingly. Use no more than three to
five features per goal, as a rule of thumb.”

52
CHAPTER 3 – THINK. SET. GO.

STEP 3
Create projects and prioritize them to help achieve
strategic goals.

As an Agile project may have multiple releases, you’ll want to


prioritize the features needed to get you to launch first. This
all depends on the complexity of your project and the lengths
of your “sprints”—the periods of work dedicated to each goal.
A typical release includes 3–5 of these sprints.

So now you have projects that are ready to be allocated to


squads.

A key success factor for any squad is having the right people
with the right balance of skill-sets to succeed. This involves the
different phases of recruitment, training and project briefing.

53
CHAPTER 3 – THINK. SET. GO.

STEP 4
Recruit the right people.

The innovation spirit might be hiding in your organization.


Keep an eye out for employees with an innovative and entre-
preneurial spirit and recruit the passionate ones who embrace
Agility and change. Consider using personas and strengths
assessments to better identify them. Some critical traits
include:

•• Expert skills combined with general knowledge


•• Emotional intelligence
•• Ownership and accountability for work
•• Passion
•• Entrepreneurial spirit

PRO TIP

Consider hiring an external contractor or freelancer to


fulfil a short-term skills gap. For example, an individual
with expertise in communications, packaging or event
management may be needed for a specific project.

54
CHAPTER 3 – THINK...SET...GO

Make sure that the teams are better than the sum of their
parts! That means building balanced teams with the right
complementary skill-sets (product managers, designers,
marketers, operations, developers and testers).

PRO TIP

Make sure each team has a Growth Hacker. A Growth


Hacker is someone who aims to gain as many users and
customers in the least amount of time possible. This
is done through low budget and creative strategies
to acquire new customers and to retain existing ones.

55
CHAPTER 3 – THINK...SET...GO

STEP 5
Train and Support.

Provide employees access to relevant and timely Agile train-


ing. Conduct training workshops to help your team familiarize
with key concepts such as Agile leadership, Scrum techniques,
Design Sprint cycles, research techniques and wiref rame
development. Trust your team that they have what it takes to
get the job done!

PRO TIP

Not everybody is made for Agile. Make sure you give


them a soft, fair and conflict-free exit and a concrete
plan of how they will resume their prior work role.

56
CHAPTER 3 – THINK. SET. GO.

STEP 6
Brief.

For Agile projects to work, teams should know from the outset
what success will look like. Teams can be set up for success by
giving them a specific brief that includes KPIs, performance
targets and project kick-off procedures. This helps ensure
that your projects are organized and scoped well to effectively
monitor performance and measure success.

PRO TIP

Give the team the opportunity and the time to bond


through team building before the project starts.
Teams undergo a process before they gel and work in
a productive manner. They follow the forming, norm-
ing, storming and performing cycle outlined below. As
a rule of thumb, the following formula can help identify
how long it takes for teams to gel.
The number of days a team needs to reach the perform-
ing stage is:

Days = (n-1)n/2 where n=the number of people on the


team.

Example: Your team is 5 people and hence the equa-


tion goes like this: #days to start really performing is:
((5-1)*5)/2 = 10 days

57
CHAPTER 3 – THINK. SET. GO.

Managing the relationship


between Performance Engine &
Innovation Engine

So now you have built the right set-up for your Agile teams
to thrive. But how do these teams operate in relation to the
broader organization? The relationship between the Inno-
vation Engine and the Performance Engine is dynamic and
delicate to handle, as teams need to be given a safe space for
innovation without being isolated or sabotaged by the rest of
the organization. The two operating systems are now actively
in place and that might spark some tensions (see page 32). In
order to avoid these, make sure that you:

Set clear expectations. In order to ensure that Agile projects


are not slowed down due to organizational interdependencies,
you can create a project charter document that outlines the
objectives and resources used for a project and how these
map in relation to the broader organizational operations.

Identify barriers and bottlenecks. Do a value stream mapping


for all the deliverables for the squad. This will help identify the
largest, most restrictive bottleneck and either mitigate the
risk for squad delivery and re-adjust or set reasonable expec-
tations for what the squad can deliver and when. Perhaps
your squad is working towards a solution that depends on an
IT transformation. Is this doable? When and how?

58
CHAPTER 3 – THINK. SET. GO.

PE

Set Plan For Bottlenecks,


Expectations Avoid Overlaps

Collaborative Provide
Teams Updates

Upfront Create Project Charter/


Agreement Document, Discuss

IE

59
CHAPTER 3 – THINK. SET. GO.

Agile Teams Work In A Value Stream


e.g. Value Stream Mapping
SQUAD

MARKETING

FINANCE
LEGAL
SALES

CRM
IT

CASE

An Agile team that LHBS worked with had strong


dependencies on the brand and marketing team.
This involved highly rigid guidelines and processes.
The center of excellence would provide a rigid list of
limitations and brand guidelines. For the project to
move forward, the center had to have a level of trust.
We were successfully able to negotiate a loosening of
the pre-existing guidelines to help get things faster. To
alleviate any concerns, we also provided 1hr updates
after each Sprint that kept them informed.

60
CHAPTER 3 – THINK...SET...GO

SIDE NOTE

Building E2E (end-to-end) Squads: E2E is tricky. It is


often assumed that Agile teams should and will take
on E2E responsibilities from inception to go-to-market.
In our experience, squads enjoy a level of autonomy up
until the final working prototype or even MVP and then
dependencies kick in and autonomy ends. They often
then face barriers related to strict marketing process,
brand guidelines or resource restrictions which creates
frustration. This impairs their autonomy and speed of
execution. Sometimes the squad simply needs to hand
over the MVP to the Performance Engine to scale it
within existing constraints and limitations.

PRO TIP

Before you begin, make sure there is an understand-


ing of the current projects in play and how they are
sequenced. These will help you best integrate your
innovation projects in your organizational pipeline.

61
CHAPTER 3 – THINK...SET...GO

Give your squads open access to information.


Working on rapid cycles (Sprints) requires teams to have full
and uninhibited access to information that they can use, such
as data on customers, products and finance. Making sure that
this information is quickly and easily accessible when needed
creates a collaborative, open and transparent working envi-
ronment.

PRO TIP

Agile teams that have to work with centers of excel-


lence can be better aligned with a workshop. This
involves the anticipation of any dependencies, exam-
ination of work processes and a shared expectation
session.

62
CHAPTER 3 – THINK. SET. GO.

Ensure that squads conduct high-level release planning to


show tangible demos or wireframes to stakeholders along
the way.
This will not only maintain momentum but also ensure that
projects receive the visibility and support they need. Your
squads should not be working in isolation from the rest of the
organization. Timely communication through regular updates,
information radiators and mini product releases ensures that
there is a common understanding in terms of what Agile
teams are working on and how their work contributes to the
larger organization.

PRO TIP

Plan some Growth Hacking Days. While squads are


building products they can deliver some quick wins.

63
CHAPTER 3 – THINK. SET. GO.

GO.

64
CHAPTER 3 – THINK. SET. GO.

65
CHAPTER 3 – THINK. SET. GO.

THINK. SET. GO.

Go.
How To Minimize The
Possibility Of Sudden Or
Slow Death

This section is intended for leaders to understand the oppor-


tunities as well as the pitfalls of supporting Agile teams, their
goals and deliverables. It’s intended for the stakeholders and
most specifically the Sponsor and/ or Business Owner to
avoid saying ‘we tried it but Agile does not work for us’.

The key to a successful Agile Transformation is to work in a


way that reduces friction for all parties, because if momen-
tum and enthusiasm for Agile are lost, these are nearly impos-
sible to regain. According to research and experience, there
are 8 critical reasons that may contribute to the failure of an
Agile project. These should be specifically referenced when
designing a system of governance.

66
CHAPTER 3 – THINK. SET. GO.

What Causes Agile Projects To Fail? What Impedes


Agile Adoption?

44%
Lack of experience
with agile methods 42%
Company philosophy
or culture at odds with
38% core agile values
Lack of management
support 37%
External pressure to
follow traditional water-
36% fall processes
Lack of support for
cultural transition 33%
A broader organiza-
tional or communica-
33% tions problem
Unwillingness of team
to follow agile 30%
Insufficient training

*Source: https://www.agilealliance.org/8-reasons-why-agile-projects-fail/

67
CHAPTER 3 – THINK. SET. GO.

1. Lack of experience with Agile methods

This is especially true for legacy organizations that are busy


running and optimizing their core business (i.e. the Perfor-
mance Engine). It is critical that senior leadership partici-
pate in relevant training on how Agile works and where it will
be applied. This will create a common purpose, vision and
goals but also help with the management of expectations.
Agile principles have to be endorsed from the top down and
supported through action. This means that there is:

•• Understanding and endorsement of the Agile Principles


and their effect on the organization.

•• Allocated budget to support Agile training.

•• Active support from HR.

•• Empathy and understanding of the change journey.

68
CHAPTER 3 – THINK. SET. GO.

2. Culture at odds with Agile values

According to a famous quote by P. Drucker,“Culture eats strat-


egy for breakfast” and this could not be more true than during
an Agile Transformation. In cases where the organizational
culture clashes with the core principles of Agile, this often
results in passive aggressive sabotage and internal hostility.
In order to avoid this consider:

•• Creating a common Agile language across the organiza-


tion through tailored communications, revision of internal
documents and company-wide workshops.

•• Delivering customer value should not only be the focus


of your squads but also reflected in your organizational
culture. A company should not be constrained by the clash
between the internal politics of a business (we want) and a
commitment to the delivery of customer value (what they
need). Have in mind that “Life is too short to build things
nobody wants.”

•• Fostering a “Fail Friendly” environment where it is okay for


squads to fail but also know when it’s time to end a squad.
Remember that Agile is all about sensing and adapting.

69
CHAPTER 3 – THINK. SET. GO.

3. Lack of management support

Agile teams need strong and decisive support from leadership


in order to succeed. This is particularly relevant for executive
level managers who will be asked to make critical decisions
and allocate resources. Remember that managers should
practice what they preach and model the thinking and actions
they want from their Agile squads:

•• Be honest and listen at the Sprint Reviews - if expectations


are not being met, talk, explore reasons and try to develop
solutions - be Agile in management as well. KPIs can and
should be set upfront, however management should also
be open to aligning these with the squad where appro-
priate.

•• Be present. If conditions change, management needs to


be open to the squad making a case for renegotiating their
KPIs. Often managers discover issues by simply being on
the ground.

•• Be transparent. It’s okay to amend or change KPIs of the


squad but be transparent and open. Most importantly,
avoid creating a wish-list of deliverables.

•• Delegate power. A key component of an Agile mindset is


delegating the decision making power and maintaining
a swift and flexible management style. Allow teams to
self-manage and collectively decide the best approaches
and performance metrics.

70
CHAPTER 3 – THINK. SET. GO.

PRO TIP

Beware of SCOPE CREEP, where little by little KPIs


are sneaked into the squad’s scope and the outcome
morphs into an impossible wish list.

71
CHAPTER 3 – THINK. SET. GO.

4. External pressure to follow traditional processes


(aka ‘waterfall’)

Incorporating a new operating system (squads) that follows


different principles and modes of working within an exist-
ing one is a challenging task. Without the right processes,
Agile teams often spend more time dealing with administra-
tive problems and project management issues rather than
focusing on delivering customer value. In order to ease these
constraints:

•• Organize a team kick-off meeting that outlines any bound-


aries, dependencies, available resources and risks.

•• Ensure that the right rituals are in place to let Agile teams
thrive. Examine the organizational rituals related to current
individual workflows, meetings and other day-to-day activ-
ities. Establish daily stand up meetings to communicate
key findings, address any concerns and track progress.

•• Ensure that there is adequate supporting infrastructure


to facilitate an Agile team. This includes the provision of
adequate IT infrastructure. A company may want to use
scalable modern IT architecture where appropriate. This
extends to the creation of a physical working environment
that gets the best out of Agile principles (Refer to Agile
Sprint Guide, download details available on page 92.)

72
CHAPTER 3 – THINK. SET. GO.

5. Lack of support for culture transition

Ensure that there is an organization-wide commitment and


alignment with Agile. As Agile is a way of working and behav-
ing, it’s benefit can only be seen if it is fully embraced by every-
one across the organization. The transition towards an Agile
way of working can be quite difficult for some.

“If everything is “People don’t resist


under control change. They resist
then you are being changed.”
going too slow”
Peter Senge
Mario Andretti
Formula 1 Driver

This journey can start with endorsement by senior leader-


ship through the:

•• Active participation of executive level management in


culture change initiatives.

•• Establishment of clear rules and practices for Agile squads


to operate.

•• Development of a well thought-out and clear communi-


cations plan to keep people informed of successes, chal-
lenges and key milestones related to the Agile journey.

73
CHAPTER 3 – THINK. SET. GO.

6. Broader organizational communication problem

If your organization has pre-existing silos that are not willing to


collaborate or communicate, Agile cannot save the day. There
have to be clear lines of communication and a collaborative
spirit for every project. This can be achieved through:

•• Assignment of points of contact (POC) for each value


stream silo, to stimulate communication and prevent
bottlenecks.

•• Inclusion of business units from the Performance Engine


in the change process.

•• Provision of multiple layers of communication and touch-


points to provide feedback across the organization. This
includes reviews of team behaviors and practices, not just
documentation and processes.

PRO TIP

Remember, if politics and the need for control over-


comes trust between teams, this will generate fear and
resistance towards Agile. This can often occur due to a
lack of communication.

74
CHAPTER 3 – THINK. SET. GO.

7. Unwillingness to follow Agile

Individuals within teams may still see themselves as highly


specialized functions that operate as mini-silos. This leads to
resistance and an unwillingness to follow the core principles
of Agile and can be addressed through the:

•• Assignment of Agile champions across different levels of


the organization to embody and spread the principles.
These are individuals who have high potential and have
the right traits to embrace Agile.

•• Encouragement of cross-functional collaboration through


careful selection of balanced teams. It should be clear to
each team member that they can comment and provide
input in areas that are not within their field of expertise.

75
CHAPTER 3 – THINK. SET. GO.

8. Lack of training.

Often organizations provide the basics of the principles of


Agile but do not adequately support the ongoing journey.
These organizations often:

•• Do not provide any sort of training.


•• Provide limited training to only a select few people. Often,
the executive leadership team is overlooked.

This can be overcome through:

•• The allocation of an adequate budget to support employ-


ees, across the organization with their Agile journey.
•• Provision of a wide array of training materials and tools
across multiple touchpoints.

“Squads are a group of volunteers who are here to


work on something they are super passionate about”

Joanna Bakas, Managing Partner LHBS Consulting Berlin

76
CHAPTER 3 – THINK. SET. GO.

PRO TIP

Quick health-check of your squad’s Agile journey. Do


these regularly to ensure that the project is not nega-
tively affected by one of the 8 #fails.

The table below is a quick and easy diagnostic tool you can
use to do a health check for your Agile journey.

77
CHAPTER 3 – THINK. SET. GO.

Example of Awesome Example of Not So


Awesome

Easy to release Releasing is simple, safe, pain- Releasing is risky, painful,


less & mostly automated lots of manual work and
takes forever

Suitable Our way of working fits us Our way of working suck


Process perfectly

Tech quality We’re proud of the quality of our Our code is a pile of dung,
code! It is clean, easy to read, and technical debt is
and has great test coverage raging out of control

Value We deliver great stuff! We’re We deliver crap. We feel


proud of it and our stakeholders ashamed to deliver it. Our
are really happy stakeholders hate us

Speed We get stuff done really quickly. We have no idea why


No waiting, no delays we are here, there is no
high-level picture or focus.
Our so-called mission is
completely unclear and
uninspiring

Mission We know exactly why we are We have no idea why we


here, and we are really excited are here, there is no high
about it level picture or focus.
Our so-called mission is
completely unclear and
uninspiring.

Fun We love going to work, and have Boooooooring.


great fun working together

Learning We’re learning lots of interesting We never have time to


stuff all the time! learn anything

Support We always get great support & We keep getting stuck


help when we ask for it! because we can’t get the
support & help that we
ask for.

Pawns or We feel empowered and have We lack support and power


Players control over the product we are to influence or build the
building. product.

*Source: https://labs.spotify.com/2014/09/16/squad-health-check-model/

78
CHAPTER 3 – THINK. SET. GO.

Good luck, and remember...


Agile is a marathon, not a Sprint!

79
CHAPTER 4

EPILOGUE
Agile Strategy And Ongoing
Experimentation

80
CHAPTER 4 – EPILOGUE

So, your Agile journey has begun, how is it going?

As mentioned in one of the Agile Myths, Agile is not a sprint


but a marathon. During this ongoing process it is important
that you maintain a frequent and honest discussion about
potential pain points, barriers but also successes! During your
Agile journey make sure you take the pulse of your projects
through Agile “health-checks” to ensure you are heading in
the right direction.

Remember that:
•• Not everything happens at once or works out the first
time. The key is to always make sure that there is the
necessary alignment between your strategy (where I want
to go), your operations and structures (how do I get there)
and your leadership (is leadership helping towards this
direction).
•• Each organization adopts Agile at its own pace and to
different extents. It is an ongoing journey which may
require the gradual implementation of change. It does
not happen overnight.
•• Agile is a process that requires ongoing experimenta-
tion and the output can be reintegrated back into the
performance engine. Successful and scalable ideas from
your Innovation Engine can be re-integrated in your orga-
nization to be part of your core business. These ideas have
to be scalable to make them work. Make sure you do not
over-speed the idea to scale and give it space to breathe.

81
CHAPTER 4 – EPILOGUE

When is it time to pull the plug?

It is okay to end Agile projects if they show the telltale signs.


You may have the right intentions and took the right steps,
however Agile projects may fail. The key is to know when to
stop, to learn from your mistakes and apply these learnings to
inform the next project. Here are some indicators of an Agile
journey gone bad:

Vision, scope and goals:


•• The project is misaligned from strategy and people are
unclear on the purpose.
•• Goals keep changing and get added into the project.
•• Scope expands unexpectedly or lacks clarity.
•• Priorities have changed in the organization which affect
the Agile project.

User and business needs:


•• Market need for project may disappear. Trust your data!
•• Competitor releases product that meets this need in the
interim.

82
CHAPTER 4 – EPILOGUE

People:
•• Autonomous teams run up against brick walls due to orga-
nizational inertia. Can-do attitude and energetic spirit of
the Agile team has faded.
•• Stakeholder disengagement - not turning up to scrum
meetings.
•• People ask to leave the Agile project.
•• You are unable to secure the necessary expertise to propel
the project due to a lack of funds or shortage of expertise.

Project management and progress tracking:


•• Teams do not reflect properly or follow processes.
•• Progress reports are not a true reflection with either “all
red” or “all green” projects.
•• Financial resources not available or excessively used.
•• Completion dates are moving, Sprint timings are not made.

83
CHAPTER 4 – EPILOGUE

In closing, there is no single silver


bullet formula for implementing
Agile. Each company and even each
off ice of a global company will have
different needs, approaches and
therefore the need for a bespoke
governance system. Take the time to
THINK and SET before you GO!

THINK. SET. GO.

84
DOWNLOAD NOW

Download
your copy of
the Agile Sprint Guide
www.agilesprintguide.com

85
BIBLIOGRAPHY

Bibliography

•• Blank, S., 2019. McKinsey’s three horizons model defined innovation for
years. Here’s why it no longer applies. Harvard Business Review Digital
Articles, February, 2–5.

•• Birkinshaw, J. & Gibson, C., 2004. Building ambidexterity into an orga-


nization. MIT Sloan Management Review, 45,47-55.

•• Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Cunningham,
W.; Fowler, M.; Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.; Kern, J.;
Marick, B.; Martin, R. C.; Mellor, S.; Schwaber, K.; Sutherland, J. & Thomas,
D., 2001. Manifesto for agile software development.

•• Christensen, C., 2015. The innovator’s dilemma: when new technologies


cause great firms to fail, Harvard Business Review Press.

•• Dalgarno, M. 2017,Nov 13. Knowing when to call it a day — stopping


failing projects. Retrieved from: https://medium.com/@markdalgarno/
knowing-when-to-call-it-a-day-stopping-failing-projects-d3bf1bae1d98

•• Dixon, S., Meyer, K. & Day, M., 2014. Building dynamic capabilities of
adaptation and innovation: a study of micro-foundations in a transition
economy. Long Range Planning, 47, 186-205

•• Heracleous, L., Papachroni, A., Andriopoulos, C. & Gotsi, M. 2017. Struc-


tural ambidexterity and competency traps: Insights from Xerox PARC.
Technological Forecasting and Social Change, 117, 327-338.

•• Joiner, B. & Josephs, S., 2006. Leadership agility: five levels of mastery for
anticipating and initiating change. San Francisco: Jossey-Bass.

•• Levinthal, D.A. & March, J.G., 1993. The myopia of learning. Strategic
Management Journal,14, 95–112.

•• Lewis, M., Andriopoulos, C. & Smith, W., 2014. Paradoxical leadership to


enable strategic agility. California Management Review, 56,58-77.

86
BIBLIOGRAPHY

•• Maurya, A., 2016. Scaling Lean: Mastering the Key Metrics for Startup
Growth, Portfolio/Penguin

•• O’Reilly, C. A. & Tushman, M. L. 2008. Ambidexterity as a dynamic capa-


bility: Resolving The Innovator’s Dilemma. Research in Organizational
Behavior, 28,185-206.

•• Papachroni, A., Heracleous, L. & Paroutis, S. 2016. In pursuit of ambidex-


terity: Managerial reactions to innovation–efficiency tensions. Human
Relations, 69,1791-1822.

•• Prange, C. & Heracleous, L. 2018. Agility.X: How organizations thrive in


unpredictable times. Cambridge: Cambridge University Press.

•• Stein, J. Using the stages of team development. Human Resources at


MIT. Retrieved from: https://hr.mit.edu/learning-topics/teams/articles/
stages-development

•• Taylor, A. & Helfat, C. E. 2009. Organizational Linkages for Surviving


Technological Change: Complementary Assets, Middle Management
and Ambidexterity. Organization Science, 20,718-739.

•• Willshire, O. 2012, Make Things People Want > Make People Want Things,
The Smithery

87

You might also like