A PRACTICAL GUIDE TO IMPLEMENTING AGILE IN LEGACY ...€¦ · Agile has successfully crossed over from the software devel - ... pitfalls and best practices. We believe it will put

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

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

A B O U T T H E A U T H O R S

Welcome

3

Contents

PROLOGUE 0 5

2 4

2 7

8 0

8 6

AGILE MYTHS

THINK. SET. GO.

EPILOGUE

BIBLIOGRAPHY

C H A P T E R 1

C H A P T E R 2

C H A P T E R 3

C H A P T E R 4

4

PROLOGUEC H A P T E R 1

5

Why have we written this guide?

C H A P T E R 1 – P R O L O G U E

6

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

“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).


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:

8

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.


T H I N K . S E T . G O .

9

Agile is a mindset that is drastically different from the tradi-tional organizational mindset and approach. This is outlined by the four Agile principles:

What is Agile: Putting theory into practice

“The highest priority,” as the Agile Manifesto states, “is to satisfy the customer by delivering customer value.”

S I D E N O T E

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.


1 0

Focus on individuals and interactions rather than processes and tools.

Customer collaboration over contract negotiations.

Create working prototypes over comprehensive documentation.

Responsive to change over following a plan.

W O R K I N G P R O T O T Y P E S

R E S P O N S I V E T O C H A N G E

I N D I V I D U A L S A N D I N T E R A C T I O N S

C U S T O M E R C O L L A B O R A T I O N

C O M P R E H E N S I V E D O C U M E N T A T I O N

F O L L O W I N G A P L A N

P R O C E S S E S A N D T O O L S

C O N T R A C T N E G O T I A T I O N S

1 1

C H A P T E R 1 – P R O L O G U EC H A P T E R 1 – P R O L O G U E

1 2


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.

1 3


1 4

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.


1 5


1 6

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 from 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 to build things nobody wants”

Ash Maurya, author of the book: Scaling Lean

“Making things that people want is better than making people want things”

The Smithery (https://medium.com/smithery/making-things-451aacaec170)


1 7


1 8

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.


1 9

C A S E

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).


2 0

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).


2 1

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.


P R O T I P

2 2

How not to design the balance


P R O T I P

Agiles Projekt

2 3

AGILE MYTHS

C H A P T E R 2

2 4

C H A P T E R 2 – A G I L E M Y T H S

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.

2 5

C H A P T E R 2 – A G I L E M Y T H S

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 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.

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.

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

Dwight D. Eisenhower

2 6

THINK. SET. GO.

C H A P T E R 3

A Practical Approach To Implementing Agile

2 7

THINK.

C H A P T E R 3 – T H I N K . S E T . G O .

2 8


2 9


Think Before You Act. The Role Of Strategic Alignment.


Evolution

Corporate

Control & Monitor

Scale

Cause & Effect

Optimize

Cost

Revolution

Start-up

Trial & Error

Speed

Cause an Effect!

Create

Breakthrough

Ambidextrous

3 0

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.

S I D E N O T E

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.


3 1

EXPLOIT & SUPPORT

EXPLORE & DELIVER NEW BUSINESS VALUE

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

SUPPORT & FUND

EXPLORE & REINTEGRATE BACK INTO THE BUSINESS


PERFORMANCE ENGINE

INNOVATION ENGINE

3 2

Innovation Engine Operating System

Performance EngineOperating System

Customer Driven Exploratory Innovation

Strategic Orientation Business driven exploitation of effi-ciencies

Flexible, cross-func-tional teams

Structure Centralized, top-down structure

Iterative, empirical, cross-functional

Processes Rigorous, comprehen-sive, linear

Collaborative, having senior managers with

multiple roles, respon-sibilities, goals

Decision Making Top down, hierarchical

Taking advantage of opportunities as they

emerge, continually improving, adapting,

event-based

Strategic Planning Planned, structured, clock-based

Thriving on change and variability

Culture Thriving on stability and control

Building on new and existing skills and

competencies

Core Competencies Building only on exist-ing skills and compe-tencies

Agility Tensions Due To Different Operating Systems


3 3

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.


3 4

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 Engineand

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

Agile Theatre


3 5

Success Trap & Failure Trap

Performance Engine Innovation Engine

Failure TrapLEGO

TOO MUCH EXPLORATION


C A S E

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.

3 6

TOO MUCH EXPLOITATION

Success TrapKODAK

C A S E

Remember the success trap: Does anyone remem-ber KODAK? While they focused on protecting their competitive advantage, the world changed.


3 7

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.

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.


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.

P R O T I P

P R O T I P

3 8

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


3 9

Strategy

Operations Leadership

Effective Agility


4 0

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 from? 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.


4 1

• 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.

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.


P R O T I P

4 2

PE

20% IE

70% IE

10% IE

NEXT BIG THINGS

EXPAND THE CORE

SUPPORT THE CORE

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%).

(Thickness of lines represent dependencies on the organizational structures & processes).


P R O T I P

4 3

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.


P R O T I P

4 4

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.


4 5

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?


So now you have a Strategy. But what about implementation? Conducting an Operations Sanity Check

4 6


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?

Strategy implementation is also about Leadership: Taking the temperature of leadership and leadership styles

4 7

SET.


4 8


4 9

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.



Set The Scene For Success

5 0

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.

STEP 1

From Innovation Strategy to Implementation


5 1

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.

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 from the goals and should be used sparingly. Use no more than three to five features per goal, as a rule of thumb.”

STEP 2


P R O T I P

5 2

STEP 3Create 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.


5 3

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

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.

STEP 4


P R O T I P

5 4

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).

C H A P T E R 3 – T H I N K . . . S E T . . . G O

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.

P R O T I P

5 5


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.

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 wireframe development. Trust your team that they have what it takes to get the job done!

STEP 5

P R O T I P

5 6

STEP 6

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

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.

P R O T I P


5 7

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?


5 8

Set Expectations

Collaborative Teams

Upfront Agreement

Plan For Bottlenecks, Avoid Overlaps

Provide Updates

Create Project Charter/ Document, Discuss

PE

IE


5 9

SQU

AD

MA

RK

ETI

NG

SALE

S

IT

CR

M

LEG

AL

FIN

AN

CE


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.

C A S E

Agile Teams Work In A Value Streame.g. Value Stream Mapping

6 0


S I D E N O T E

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.

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.

P R O T I P

6 1


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.

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.

P R O T I P

6 2

Plan some Growth Hacking Days. While squads are building products they can deliver some quick wins.


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.

P R O T I P

6 3

GO.


6 4


6 5

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.



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

6 6

44%Lack of experience

with agile methods

What Causes Agile Projects To Fail? What Impedes Agile Adoption?

36%Lack of support for cultural transition

38%Lack of management

support

33% Unwillingness of team

to follow agile

42%Company philosophy or culture at odds with core agile values

37%External pressure to follow traditional water-fall processes

33%A broader organiza-tional or communica-tions problem

30%Insufficient training

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


6 7

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.


6 8

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.


6 9

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.


7 0

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.


P R O T I P

7 1

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.)


7 2

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.

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.

“If everything is under control then you are going too slow”

Mario Andretti Formula 1 Driver

“People don’t resist change. They resist being changed.”

Peter Senge


7 3

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.

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.


P R O T I P

7 4

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.


7 5

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


7 6

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.


P R O T I P

7 7


Example of Awesome Example of Not So Awesome

Easy to release Releasing is simple, safe, pain-less & mostly automated

Releasing is risky, painful, lots of manual work and takes forever

Suitable Process

Our way of working fits us perfectly

Our way of working suck

Tech quality We’re proud of the quality of our code! It is clean, easy to read, and has great test coverage

Our code is a pile of dung, and technical debt is raging out of control

Value We deliver great stuff! We’re proud of it and our stakeholders are really happy

We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us

Speed We get stuff done really quickly. No waiting, no delays

We have no idea why 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 here, and we are really excited about it

We have no idea why we are here, there is no high level picture or focus. Our so-called mission is completely unclear and uninspiring.

Fun We love going to work, and have great fun working together

Boooooooring.

Learning We’re learning lots of interesting stuff all the time!

We never have time to learn anything

Support We always get great support & help when we ask for it!

We keep getting stuck because we can’t get the support & help that we ask for.

Pawns or Players

We feel empowered and have control over the product we are building.

We lack support and power to influence or build the product.

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

7 8

Good luck, and remember... Agile is a marathon, not a Sprint!


7 9

EPILOGUE C H A P T E R 4

Agile Strategy And Ongoing Experimentation

8 0

C H A P T E R 4 – E P I L O G U E

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.

8 1


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.

8 2

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.


8 3

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!



8 4

Download your copy of the Agile Sprint Guide

www.agilesprintguide.com

D O W N L O A D N O W

8 5

• 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.

Bibliography

B I B L I O G R A P H Y

8 6

B I B L I O G R A P H Y

• 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

8 7

Documents

A PRACTICAL GUIDE TO IMPLEMENTING AGILE IN LEGACY ...€¦ · Agile has successfully crossed over from the software devel - ... pitfalls and best practices. We believe it will put