The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders

The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders

TL;DR: The Big Picture of Agile

Let’s face it: While your enthusiasm for the big picture of agile practices is admirable, your stakeholders will most likely be moved by one thought only at the beginning of the transition: “What’s in for me? How will I now have my requirements delivered?”.

Read on and learn about one way how to kick-off the transition to a learning organization by pitching a simplified version the big picture of agile practices to your stakeholders first.

There Is Just One Spotify

Being a part of the team that builds and scales an organization from scratch over several years is rare privilege. Ben Linders pointed out recently that There Is No Spotify Model, and that you „shouldn’t copy it in your own organization“.

According to Henrik Kniberg, scaling Spotify…

…wasn’t a big re-make, more like a continuous stream of small iterative improvements to our organization and process. We have been growing for three years, and the way we work today has evolved naturally over time.

(Note: He is talking about an organization that has been carrying an agile mindset in its DNA from the start.)

You—on the other side—are more likely to be a member of a corporation that decided to become more agile to improve its standing in the innovation game. (Remember Marc Andreessen’s “Why Software Is Eating the World”?)

In your case, there is an established organization with its own flavor of structural particularities. There are hierarchies, there is politics and probably one form or another of silo thinking, or local optimization attempts. And cross-departmental communication has long been an issue.

There are likely people who will lose with the move to an agile organization. An organization that is build on top of formulating hypotheses, and running experiments. An organization that embraces failure, self-organization, and the acceptance of accountability. (To my experience, command & control structures can be comfortable, too, at least for some people. Read more in: Why Agile Turns into Micromanagement.)

The Hands-On Approach to Pitch the Big Picture of Agile to Your Stakeholders

No matter the kind of organization, “going agile” cannot be accomplished by an edict from the CEO. It needs to be sold, hearts and minds need to be won, and that is a journey not a destination.

A successful first step in pitching the benefits of agile principles and processes to stakeholders—at least to my experience—is starting the educational process with the following kind of “flowchart”, the big picture of agile:

Agile Transition: The Big Picture of Agile – by Age of Product

The flowchart is admittedly handling “agile” at a simplified, reduced level. However, it is designed that way intentionally. There is the huge number of available agile frameworks and methodologies that cover everything from product discovery to continuous product delivery.

If you start with a too detailed version of this new universe, you might lose stakeholders early in the transition process to cognitive overload. The flow diagram does not intend to dumb it all down but prevent stakeholders from being driven into their own, possibly negative, confirmation bias of “agile”. Keep it simple, if you want to preserve an open mind among your stakeholders.

I am using the flow diagram for organizations with an existing product management organization that utilize Scrum to deliver the product. The diagram is intentionally combining several different agile and lean practices to compensate for Scrum’s Achilles heel—the missing product discovery part.

Therefore, it starts with the competition of ideas for scare (development) resources on the product discovery side, and ends on the (Scrum-based) product delivery side. (Without specifying the technical nature of the delivery process, e.g. DevOps practices.)

The diagram addresses the following steps in a simplified agile process:

  1. The ideas and “requirements” long-list, competing for engineering resources
  2. The application of the “valuable, feasible, and usable” filter…
  3. …thus identifying the short-list of test-worthy hypotheses
  4. Running (lean) experiments to…
  5. …validate hypotheses, representing how the learning organization is mitigating risk
  6. The Product owner as the gatekeeper of the product backlog, visualizing the hand-over from product discovery to product delivery
  7. The product backlog, representing at any given time the most valuable set of tasks for a Scrum team
  8. The continuous product backlog refinement process…
  9. …leading to the next set of user stories, tech tasks, spikes, or bugs for the Scrum team.

This initial coaching works well together with a follow-up workshop with stakeholders, during which the stakeholders actually build a clickable prototype of an app. (Read more here: App Prototyping with Absolute Beginners.)

Such a workshop greatly improves the future collaboration with those stakeholders that embrace the agile way of thinking—your future change agents.

And the workshop also identifies all those stakeholders that are opposed to the idea—the ones who will try to impede the progress of the transition to preserve their current position.


Any transition to agile practices needs to be sold to an organization, it cannot simply be ordered. A proven first step to do so, is pitching a simplified big picture of agile practices to visualize the process from product discovery to product delivery, and communicate its benefits to the stakeholders. Ideally, you follow up with a hands-on stakeholder workshop that teaches beginners to build a clickable prototype of an app.

What is your best practice to communicate the benefits of an agile mindset to stakeholders?

Related Posts

How to Kick-off Your Agile Transition (Part 1)

Product Backlog Refinement — Agile Transition Part 2

10 Proven Stakeholder Communication Tactics during an Agile Transition

6 thoughts on “The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders”

  1. Don’t jump to conclusions, Dev. I start with the “why”, too. But there are organization, where appealing to common sense does not have the expected outcome, as egos, politics and personal agendas may be driving forces. Bait the hook, feed the fish…

  2. Hi Stefan,

    My best practice is to…
    – Start by saying there is no Best Practice 😉

    You simplify the how and what.

    I start from the why.

    Agile is a very short value-set (the manifest), so I start by these four, explain them a bit with my examples, and ask if they agree.

    If not, probably not worth the effort (if they search profit but value process as much as people, or insist on documentation without convincing me it has value, we are not a good match)

    After that, the what and how are simple.

  3. Totally agree John, it is — in the true sense of the work — teamwork, including all levels of the organization. If the C-level is not fully committed, you actually can skip the whole idea… (The approach from the post only works with the support of the C-level.)

    I keep you posted on my current project.

  4. Great article as usual Stefan. I would like to expand on your comment that no matter the kind of organization, “going agile” cannot be accomplished by an edict from the CEO. This is true. What is also true is that “going agile” cannot be accomplished without the direct involvement of the CEO in the transition. I’ve managed a few agile business change project and the companies that get the most out of it are the ones where the CEO attends the Retrospectives and even involves themselves in the Scrum of Scrums. The hands on approach puts out the message that this is the way to work and also encourages new agile teams to break old boundaries. Having the CEO listen to impediments and lessons learnt sessions demonstrates to the ‘old guard’ better than any words that they need to be ready to respond to the challenge of agile quickly or they risk losing their CEO’s support.

Leave a reply

Your email address will not be published. Required fields are marked *