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 of 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 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 in order 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, i.e., an organization that is built on top of formulating hypotheses and running experiments or an organization that embraces failure, self-organization, and the acceptance of accountability. (To my experience, command-and-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. That is a journey, not a destination.
A successful first step in pitching the benefits of Agile principles and processes to stakeholders — at least in 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 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 to 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, i.e., 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 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 for communicating the benefits of an Agile mindset to stakeholders?