Why roadmaps reflect the level of Agile inadequacy
The Penguin Principle for Agile transformations
I was in the fifth and final round for a Product Owner position. I remember being tired of responding to all kinds of questions, often the same I had answered before.
Especially considering I already jumped through quite a few hoops— I had completed a personality test and an intelligence assessment. Didn’t they have enough information to decide if I’m good enough (or not) by now?
Apathy about landing the job was starting to kick in. By the third round, it felt like we’re all wasting our time by beating a dead horse. The sooner all this ritualistic nonsense would be over, the better.
During the interview process, I asked every employee I talked to about the state of the Scrum implementation. All answers I received were along the following lines: ”We do Scrum by the book. This is the first company I worked at where this is the case.”
Being skeptical by having witnessed many weak Scrum implementations, I didn’t take the veracity of this statement at face value.
By asking some simple questions, I quickly discovered their Scrum implementation was still in its infancy (an alternative way of saying it was lacking). Their Scrum Teams were in the Scrum cave, as coined by Max Heiliger — you can’t be aware of what you are incapable of seeing. What you don’t know limits what you are able to see.
After all those rounds, I had a clear picture of what was happening on the team level, but what about the organizational level? Nobody I met was able to tell me anything about the current roadmap. The fact multiple interviewers knew very little about their roadmap was a red flag.
Then in the fifth round, I met with their CTO and asked him to walk me through their roadmap. Within a few minutes and after a few questions, I had a solid picture of how far along they were in their Agile transformation — they had a lot of work to do.
One of the first things I ask during interviews is to see their roadmap. Before I explain why I do this, let’s take a slight detour to discuss the magnificent world of birds, but I promise to tie it all back to roadmaps in the end.
What avians can teach us about roadmaps
Adélie penguins mainly inhabit the continent of Antarctica and nearby islands. You often see these penguins huddled together in dense groups near the water. Every penguin is reluctant to enter the water and waits until an unlucky individual falls in the water, either by accident or by being pushed by another penguin.
When the water surface stays calm and doesn’t turn red, the coast is clear. Other penguins rush to jump into the water to hunt for food. When the sea turns bloody red, it means sharks, leopard seals, or killer whales are around. The penguins decide it is better to stay on the ice and to wait until the coast is clear.
Miners used to practice a similar strategy to the penguins in coal mining, also involving birds. Well into the 20th century, it was common to carry a caged canary with you while descending into the coal mine.
Birds, because they take in oxygen both when they inhale and exhale, are way more sensitive to toxic gases than humans. The death of a canary in a mine would be an early warning sign of poisonous fumes being present such as carbon monoxide.
The first penguin to leave the coast is a litmus test of the safety of the waters. The canary being alive or not was an early warning signal of the air's toxicity for miners.
The state of your roadmap is a reliable indicator to assess the extent of your Agile transformation. The roadmap is where business and tech meet. Or in the world of penguins: where the sea and the coast collide. Where there are potentially dangerous sharks and killer whales lurking in the water who do not understand nor care about being Agile.
By viewing the roadmap, you can easily detect if the Agile transformation stopped at the team level or if it went beyond. You can assess if sharks are hiding in the waters capable of halting the Agile transformation dead in its tracks.
Let’s explore why roadmaps are reliable indicators of the extent the Agile transformation has spread in the organization.
Why do roadmaps reflect the level of Agile inadequacy?
In management, the Peter Principle, coined by Laurence J. Peter, is a concept that explains why people get promoted to positions they are incapable of successfully handling. The theory behind the Peter Principle is easy to explain.
You get promoted to the next level based on your performance in your current job. However, what makes you successful in your current job, doesn’t necessarily make you successful in your next job.
You could be a fantastic analyst who gets promoted to be a manager of analysts. But what took you to the next level — analysis, and communication — might not be good enough to make you a great analyst manager. You could be a terrible, bullying micro-manager who makes all other analysts feel miserable.
At some point, you are promoted to a level where you cannot succeed. You’re too competent for the previous level but not capable enough to go to the next level. You’re stuck at the level of your inadequacy.
The Peter principle in simpler terms:
“Employees rise to the level of their incompetence” — Laurence J. Peter
In light of the Peter Principle, I’ve decided to coin an Agile counterpart I call the Penguin Principle:
The Penguin Principle
“Roadmaps reflect the level of Agile inadequacy.”
Good roadmaps require buy-in from many different levels in the organization. When the Agile transition stops at the team level, you will immediately notice this in the roadmap. Stakeholders don’t understand Agile and inflict their waterfall mindset on the Scrum Teams.
To illustrate some of the signs of waterfall behavior in a roadmap, let’s circle back to my final interview with the CTO and what exactly opened my eyes to how far along they were in their Agile transformation.
The CTO's roadmap shown to me in the fifth round was an inflexible, feature-based roadmap stretching a year into the future. After I asked how features were added to the roadmap, I discovered all features had to go through an extensive pitch process. It contained many different steps and required extensive effort by creating detailed business cases. Except, as I later found out, if you were part of the leadership team, then waving your wand and saying that it had to happen was good enough.
Every team had its own roadmap, and if there were dependencies, you had to go through the same pitch process as everybody else. In practice, this meant inflating your business cases as much as possible to bully other teams into helping you out.
Team roadmaps had no room for learning, experimentation, and flexibility. This is what you get when you project Tayloristic assembly line thinking onto a roadmapping approach.
After I joined the company (I am a foolish person who thinks he can change things), I saw that all teams were busy not helping each other. Delivering as promised on your team roadmap was more important than making a difference for customers and the company.
Once something was delivered, nobody gave a damn about the business case or looked back on how it actually performed. The business cases were ceremonial and hollow— only meant to give others the impression we knew what we’re doing. “Look! Trust us. We cooked up some fancy numbers!”
With a single glance at such a roadmap, you can immediately sense the presence of a Feature Factory running at full speed.
Delivering features doesn’t mean you are delivering value, just like telling a joke doesn’t mean people will laugh. It’s all about how customers receive your feature and if it helps them to meet their goals.
Here are important questions to consider when you examine a roadmap during an interview process:
- What is the Product Vision for the overall roadmap?
- What is the Product Strategy? What is the biggest challenge we’re facing, and what’s the most effective way to overcome this obstacle?
- How was the roadmap created? Who was involved in the creation?
- How were the different elements of the roadmap prioritized?
- Is the roadmap feature-based or goal-based? Is it rooted in customer problems, pain points, wants, needs, struggles, or jobs-to-be-done?
- How are timelines represented? Is it now, next, later? Is it in quarters? Or is it per month?
- How were these timelines estimated? How much time is spent to achieve this (less is better)?
- How far into the future does the roadmap cover?
- Does every team have its own roadmap? Or is there an overall roadmap for the different teams?
- How are prioritization conflicts between teams handled?
- What features or goals did not make the roadmap? How was this decided?
- How flexible is the roadmap? How will you deal with emergent understanding, failure, and learning?
- Is the roadmap focused on delivery, or does it include discovery and validation?
It is possible to come up with even more valid questions to ask to assess the Agile maturity. I’m not going to tell you what the right answers are, but I will tell you how you can evaluate the answers you are given. Scrum, and Agile, are about learning and doing.
What you know before starting isn’t good enough. There needs to be flexibility, emergence, and adaptation. As Todd Lankford writes, roadmaps are the map, not the terrain. The Scrum Teams are self-managing, which means they should have a strong say about whatever is on the roadmap (note: the Scrum Team includes the Product Owner).
Use the Penguin Principle for roadmaps
Roadmaps are a bloody battleground where the Agile world locks horns with the waterfall world. The Agile world often draws the shortest straw in this inevitable encounter. By examining and discussing the roadmap, it is easy to assess how far the Agile transition has reached. Is there a lot of organizational friction between the teams and the layers above with the appearance of bloody waters? Or is there crystal-clear alignment between the different levels of the organization?
Roadmaps are difficult to do right. The paradigm of analysis, planning, and up-front design is strong in many organizations. We know this paradigm is suboptimal in a complex environment. Predicting what will be finished when is difficult when you do complex work. Because it is easy to measure if we succeed at our predictions, it is often what we focus on. Instead, we should try to figure out and measure the difficult things that actually predict our success.
The ability to predict when a feature will be completed has absolutely no bearing on your ability to deliver. Companies often conflate the inability to predict when a feature will be completed with being clueless about what you’re doing.
Ask someone working in sales to predict how many deals they will have closed exactly one month from now, with which customers, and how much money every deal represents. You can be confident they will be wrong too.
Being wrong about predictions doesn’t mean a salesperson is bad at sales. They are just poor at predicting when those deals are closed exactly and the specific amount they will represent. It could be that they ultimately close all deals in their pipeline. As we all know, customers can be quite finicky, even if they ultimately do decide to sign.
The next time you’re in a job interview, don’t be shy and ask to see their roadmap. You’ll have an easy litmus test to assess the stage the organization is at in their Agile journey and what you will be up against if you decide to start working there. I’m someone who is up for challenges, but if you’re not, you can easily tell if it’s time to run away or brace yourself to fend off the sharks.
Do you want to write for Serious Scrum or seriously discuss Scrum?
