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.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers.
Join more than 120 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.
There Is Just One Spotify
Being a part of the team that builds and scales an organization from scratch over several years is a 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 are 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 the move to an agile organization. An organization that is built on top of formulating hypotheses, and running experiments. An organization that embraces failure, self-organization, and the acceptance of accountability. (In my experience, command & control structures can be comfortable, too, at least for some people. Read more in: Why Agile Turns into Micromanagement.)
Download the ‘Agile Transition – A Manual from the Trenches’ Ebook
The "Agile Transition – A Hands-on Guide from the Trenches" ebook is a collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people to agile practices. Download it for free:
Cannot see the subscription form?
Please click here
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:
The flowchart is admittedly handling “agile” at a simplified, reduced level. However, it is designed that way intentionally. There is a 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 prevents 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 scarce (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:
- The ideas and “requirements” long-list, competing for engineering resources
- The application of the “valuable, feasible, and usable” filter…
- …thus identifying the short-list of test-worthy hypotheses
- Running (lean) experiments to…
- …validate hypotheses, representing how the learning organization is mitigating risk
- The Product owner as the gatekeeper of the product backlog, visualizing the hand-over from product discovery to product delivery
- The product backlog, representing at any given time the most valuable set of tasks for a Scrum team
- The continuous product backlog refinement process…
- …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 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.
ProductCamp Berlin 2016:
I presented the flowchart at the ProductCamp Berlin 2016, and Sabine Rougk created a great sketch note:
Check out Sabine’s other sketch notes at her Instagram account @duda_draws.
Conclusion:
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
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
View Comments (8)
Hi Stefan - Great high-level thought leadership!
Small typo here:
scare (development) resources
I think you meant to say
scarce (development) resources
Have a great Sunday!
Hi Mike,
Thanks for the hint! 🙏
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.
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…
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.
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.
Excellent article. I can say this is a valuable article to read.
Glad I can help, Sekhar… :)