PiP Speak

Our mission is to achieve lasting, impactful, continuously improving results

Is ‘Agile’ right for your enterprise?

For businesses facing disruption, agile ways of working can deliver great customer and business outcomes – in the right teams. However, force-fitting ‘Agile’ structures and tools isn’t a cure-all and may increase risk. We’ve found agile approaches work best when they are applied in the right teams, carefully tailored to the opportunity at hand, and with critical roles in place to take accountability for delivery and interfaces with the broader organisation.

Even before the pandemic, we often saw ‘Agile’ touted as the cure for every business woe. As the disruption wrought by COVID-19 increases uncertainty and the pace of change across industries, agility has become even more desirable as a business capability. Every leader wants to feel that their organisation can respond quickly as the market shifts, and it’s true that agile ways of working, implemented well, can help build that capability.

The irony we have noticed with ‘Agile’ implementations is that often, they don’t deliver agility – or any of the other promised benefits. Instead, misapplication can create a distraction from what matters, undermining effective processes, and blurring accountabilities – in turn slowing down teams that were already working well, and potentially increasing risk1.

Agile enterprise PiP Speak

In this article, we explain why there’s no ‘one size fits all’ approach to getting the most out of agile ways of working in large organisations. Instead, it’s critical to identify which parts of your organisation are most likely to benefit from the approach, take a tailored approach to setting those teams up for success, and build in accountability for delivery. The focus throughout needs to be on the conversations and behaviours that improve performance, not the artefacts that get all the attention in the press.


Our observations – click below to jump to each section

#1: Not everyone means the same thing by ‘Agile’

#2: Agile ways of working aren’t useful for every team

#3: Truly agile teams need empowerment, not buzzwords

#4: Your leadership approach will need to change

#5: More autonomy doesn’t mean less accountability




Observation #1: not everyone means the same thing by ‘Agile’

One of the challenges with agile ways of working is that while everyone understands the word agile, there is no guarantee that any two people will understand the same thing by it. It’s useful to be precise, though: it accelerates alignment and focus.

Originating in 2001 out of frustration experienced by enterprise software developers, the term was intended to capture a fundamentally different way of working from the approach that was standard at the time. Rather than attempting to document every user requirement, plan the project to the last work-hour and spend years working in rigid silos before delivering a usable output, the authors of the Agile Manifesto2 proposed a much more iterative approach.

It’s an approach that empowers cross-functional teams to progressively improve customer outcomes, by frequently seeking and quickly responding to important new information to deliver something of value to the customer – who could be internal or external to the organisation – over short timeframes.

As the agile approach has grown from a first-principles idea into the multi-billion-dollar ‘Agile’ industry, the term has also come to mean a collection of methods intended to operationalise the agile approach, characterised by small, self-directing teams who work in rapid iteration cycles.

Back to index

Summary of the most common ‘Agile’ terms
Common tools and practices
  • Sprint: Time box, usually of one month or less, during which an agreed outcome is delivered
  • Backlog: Prioritised list of tasks to complete in order to achieve the target outcome
  • Daily stand-up/scrum: Short, daily meeting to set expectations about what will get done and where help is required
  • Demo/showcase: Demonstration of outputs to sponsor and/or customer
  • Retro/retrospective: Regular review in which the team agrees how to improve their processes and outputs
  • Ceremonies/rituals: Meetings commonly used in ‘Agile’ settings, to drive alignment, visibility and action within the team or squad
Common teams and roles
  • Squad/scrum team: Small, cross-functional team accountable for a defined customer outcome
  • Tribe: Group of squads doing related work
  • Chapter: Cross-team group of people who share skills and often belong to the same function
  • Product owner: The person in each squad responsible for agreeing target outcomes and prioritising work required to achieve them
  • Chapter lead: The person in each chapter responsible for
    supporting professional development of the people in the
    chapter
  • Scrum master/Agile coach: Supports and develops ‘Agile’ skills and processes, prevents or addresses distractions

We’ve found it’s useful to get the approach clear first, and then choose the methods that best support it, given the unique business context. We’ve seen genuinely agile organisations that use no ‘Agile’ terminology; and increasingly, we’re seeing organisations with plenty of terminology, but no appreciable agility.




Observation #2: agile ways of working aren’t useful for every team

A specialist in financial services begins a scoping meeting with a new senior team looking to tighten their data management practices. As the meeting kicks off, a late arrival sweeps in, introduces herself as “the Agile coach”, and begins writing up actions on post-it notes. The rest of the participants, who already have a clear agenda and a designated note-taker capturing key discussion points and agreed actions, are initially perplexed, but then get on with the meeting. The Agile coach is left with a pile of post-its that no-one has any use for.

Stories like this are becoming common in large organisations: agile ways of working have been applied indiscriminately, wasting time and creating distraction. Many leaders we’ve spoken with have an instinctive feeling for where agile ways of working are likely to be useful for them, but struggle to articulate objective boundaries that help to focus the effort (and counter evangelists). We’ve found it’s useful to think about the work done in an organisation along two dimensions.

Back to index

Agile ways of working won’t add value, and may increase risk if applied to the wrong teams

agile-enterprise-1-4

Agile ways of working are best suited – in fact, required – at the top right of this map, while at the bottom left they add no value. There is little reward for the kind of risks that teams can realistically take, and the systems they operate in are relatively stable and predictable. In fact, in this space, agile methods may increase risk by undermining established operating protocols.

These two extremes shouldn’t be contentious: agile ways of working don’t create value for a production line or a power generator beyond what an effective Continuous Improvement programme should already be delivering. The challenge for leaders seeking agility arises in the wide zone between the two extremes. We’ve found that a tailored approach, anchored in the unique problems and opportunities the organisation is facing – both its risk and reward profile and the potential value of very fast adjustment – is the best way to ensure the agile approach delivers value.

Back to index



Observation #3: truly agile teams need empowerment, not buzzwords

A network innovation team, broadly tasked with improving customer experience, has a long list of potential new technologies to test. The team selects one option and undertakes a two-week sprint, testing the new technology with customers from a high-priority segment. Their customers don’t notice any meaningful difference, compared with technology currently in use, and the team now believes there are better options on their list. When the team proposes deprioritising the new technology for the quarter, a senior leader asks them to find another way to demonstrate customer value, as the investment decision has already been made.

Even when teams apply agile ways of working in areas that seem well placed to benefit from the approach, leaders need to be wary of AINO – ‘Agile In Name Only’. Here, the team was using agile tools and methods, but the core principle of empowering them to progressively improve customer outcomes was missing.

Building empowerment, particularly in an organisation that has traditionally worked in a top-down manner, requires actively creating three critical elements:

  1. A clear, pragmatic customer outcome for the team to achieve
  2. The ability for the team to make its own decisions on how to achieve that outcome
  3. Support from leaders to get the work done

In this example, none of these elements were in place. The investment decision was a bigger bet than this team could make, with implications well beyond the very loosely defined “customer experience improvements” the team was trying to achieve in the short term.

Although trained in agile methods, the team wasn’t set up for success. We have found that working from first principles with each team helps to mitigate the risk of AINO. Supporting each team to agree on the measurable outcomes they will achieve and to develop their own agile working principles, then enables them both to choose the best methods and tools for now and to adjust over time as circumstances change. They understand the why, not just the what and how, which means they can also quickly identify when they’ve been asked to work on the wrong thing – not everything will be an agile nail to hit with the agile hammer.




Case study

A fuel distributor and retailer lifts speed to market

Context

Our client regularly identified innovative improvement ideas and customer experiences but struggled to implement them quickly. They had experimented with new ways of working, including ‘Agile’ and Human-Centred Design, but were encountering challenges with teams using different methods and terminologies, making it difficult to achieve the desired velocity.

Client achieved
  • Faster delivery among teams working with new principles, e.g. one agile team produced six concrete customer-relevant outcomes in six weeks whilst lifting people engagement vs. previous performance, where six weeks without concrete outcomes would have been acceptable
  • An agreed set of ‘fit for purpose’ working principles drawn from Lean, Design Thinking and ‘Agile’, tailored to their unique starting point and opportunities
  • A tangible set of practical tools and behavioural guidelines, based on these principles, to guide team formation and activity: in particular, visualising their work and learning by experiment
  • A coaching capability and roadmap to scale, adapt and integrate the agreed new working principles into other parts of the organisation
What we did
  • Worked with the executive team to define which teams would benefit from the new ways of working
  • Ran workshops to develop the new working principles, building from the best of what was already in place, adapting other principles as required, and using simple, jargon-free language throughout
  • Developed a set of practical tools and behavioural guidelines and refined with the teams, including how to work in short iterations and visualise work
  • Designed a flexible coaching approach and adoption guidelines to support transition to the new ways of working at different speeds for different teams, depending on context and maturity

Back to index



Observation #4: your leadership approach will need to change

The innovation team example above also illustrates the mindset and skills shift that leaders need to make to get value out of agile ways of working. Choosing priority outcomes for agile teams, defining boundaries for decision-making, securing the right resourcing and clearing barriers become the critical jobs for a leader. This contrasts with more traditional tasks like top-down decision-making and direct KPI management. In other words, the agile approach shifts the emphasis strongly from management tasks towards leadership tasks.

Day-to-day leadership behaviour must also create and continuously support an environment that fosters experimentation, learning and self-management. Leaders will need to encourage team members to hold each other to account for what they’ve committed to contribute to the team’s objectives, significantly reducing the leader’s own role in actively managing performance.

Agile execution requires faster iteration cycles that rely on autonomous teams; this changes the role of the leader
As the operating model shifts…

Agile execution requires faster iteration cycles that rely on autonomous teams; this changes the role of the leader

…so does the leader’s role

agile-enterprise-2b

Back to index



Observation #5: more autonomy doesn’t mean less accountability

Even organisations that were ‘born digital’ find they need to create hybrid operating and organisational models as they grow3, introducing the need to manage interfaces between agile and more traditional teams. While appropriately resourced and empowered agile teams may choose how they work across these interfaces, this autonomy must come with accountability for delivering results4. The executive team needs to make performance commitments to investors, which agile teams then need to sign up to and deliver against, often without being able to describe exactly how they will do so.

We’ve observed that reliable delivery only happens when accountability is built into the operating model. It must be clear who’s on the hook for concrete, measurable outcomes that link directly to business value. In practice, this works best if accountability for delivery rests with a critical role in each team: the product owner.

A great product owner drives outcomes across two spheres – agile and traditional – bridging the gap between day-to-day team delivery and the longer cycle of more traditional performance metrics. They are not project managers or team leaders in the usual sense; they are excellent problem-solvers, influencers and networkers, tenacious in creatively pursuing the target outcome and they consistently link customer outcomes back to operational and financial measures, ensuring customer value becomes business value. Developing a pool of strong product owners is critical in scaling agile ways of working in large organisations.




Case study

A financial services provider reduces cost and improves customer experience

Context

Our client faced a fundamental shift in their market, which radically reduced barriers to churn for their customer base. This created significant pressure to improve customer experience and to reduce cost to support more competitive pricing. We were engaged to help the team to build momentum and lift their pace of change.

Client achieved
  • Delivery of two major customer experience improvements in record time: an intuitive new-user interface for the website, and new digital forms to replace key paper documents launched in five weeks, where previous comparable projects had been at a standstill after 18 months
  • Creation of an embedded core digital programme for lasting capability: integrated, cross-functional transformation team to continue identifying, prioritising and delivering user experience improvements, with improved transparency and processes for managing resources across functions
What we did
  • Developed and drove alignment on the transformation strategy based on the client’s starting point vs. operational and financial targets, and reflecting priorities for customer experience improvements
  • Established a cross-functional transformation team within the business, and new product owner roles tasked with delivering value supported via a structured capability development programme
  • Developed and implemented KPIs, dashboards and action tracking to operationalise the strategy
  • Developed a tailored approach to agile ways of working, and provided training and coaching to product owners and leaders on how to develop and execute on prioritised opportunities
  • Introduced an open, centralised demand management approach for key resources
  • Set a new approach to managing interdependencies, removing approval bottlenecks and enabling multiple streams of work using agreed standards
  • Launched new bi-monthly ideation and prioritisation rhythm, heavily focussed on the customer, directly coaching the team to use these effectively

Back to index




Conclusion

If you are careful about how you apply agile ways of working, keeping the focus on value delivery and behaviour instead of buzzwords and artefacts, the approach can help your company thrive in the face of disruption and ongoing uncertainty. Success depends on applying it with the right teams, firmly anchoring implementation in core principles, and providing the right leadership with the right accountabilities. Without these disciplines, ‘Agile’ will almost certainly fail to live up to the hype.


[1] “Is the Agile Manifesto still a thing?”, Atlassian blog post (click here)

[2] The Agile Manifesto and its 12 principles (click here)

[3] “Failed #SquadGoals”, Jeremiah Lee (click here)

[4] “Balancing Autonomy with Accountability”, Edwin Dando (click here)




Click to download a printable version of this article


About the authors

Tom Schnitker shirt

Tom Schnitker

Director, Partners in Performance

Tom is the Managing Director of our South East Asian region and heads our Organisation Practice globally. He has over 30 years’ experience in consulting and executive line management in diverse environments across South East Asia, Australia, New Zealand, Africa, Europe and Latin America.

Helen Lawson-Williams shirt

Helen Lawson-Williams

Partner, Partners in Performance

Helen manages our global Organisation Practice. She has close to 20 years’ experience in consulting and operations leadership roles, across industries including telco, retail, logistics, financial services and entertainment. Helen holds a PhD in Organisational Psychology and has deep expertise in building excellent organisations.


Gerd Schenkel, Steven Henderson and Patrycja Stasina made significant contributions to this article.