In the first part of this article series, we learned about a Melanesian tribe that started to practice a Cargo Cult. In this second part of the article series, I want to provide some advice on how you and your team can avoid becoming Cargo Cult.
After observing the military during World War II flying in supplies via airplanes, the islanders adopted a belief system in which they performed magic rituals that they believe will cause a more technologically advanced society to deliver goods (Cargo Cult).
Many software teams around the globe also practice a Cargo Cult when it comes to adopting Agile practices. These teams never understood the underlying principles, and now they waste precious time and project budget by poorly imitating Agile teams without yielding any meaningful output.
The Cargo Cult Agile syndrome is the reason why most Agile transformations fail.
Let’s look at some questions that can help you judge whether your investment into Agile was or will be worth it. Then let me explain the four steps you can use to avoid becoming a Cargo Cult.
Questions you can ask to avoid becoming a Cargo Cult
These questions can help you judge whether your training or coaching is or was a good or a poor investment:
Does it sound too simple?
Is sending your three Project Managers to a two-day Scrum training for $999 a seat sufficient? Can you really expect to turn the ship around with just $2,997?
It’s called Scrum Master and Product Owner. Neither Project nor Manager is a popular term in Agile, and there is a good reason for that.
If it’s cheap and takes only a couple of days, it’s probably too good to be true.
Also, be careful with Scrum Masters and Product Owners on the market. Ask yourself if their certificate can really mean anything.
Does it sound too complex?
Some larger companies consider the Scaled Agile Framework (SAFe).
Here’s a “simple” diagram explaining how it works:
In this diagram, trying to find the end-user or the customer is like playing Where’s Waldo?
If you consider SAFe, I recommend reading this article first.
Do you see results (or at least improvements)?
If you’ve already started your Agile transformation, how do you know it’s working? How do you know that your ability to ship better software faster has improved?
A common mistake is not to measure at all. And the danger with tracking progress is to measure the wrong thing.
A bad measurement of your ability to ship software is User Story Points. This metric, suggested by Agile methodologies like Scrum, has a very different purpose. And in most organizations I have seen, this metric is mutilated anyway (another manifestation of Cargo Cult Agile).
So what to measure instead?
In the first place, you will most likely be interested in Organizational Success, and the question should therefore be:
Does your Organizational Performance increase?
What that means in your specific case depends, of course, on your individual commercial and non-commercial goals.
The measure of Organizational Performance often correlates with the Return on Investment, and the measure is robust to economic cycles.
Do your KPIs satisfy those criteria? And did your Organizational Performance improve?
Here’s an alternative question you can ask:
Does your Software Delivery Performance increase?
The DORA research program was able to prove scientifically that Organizational Performance and Success correlate with Software Delivery Performance (SDP).
And Software Delivery Performance, in turn, can be measured with 4 simple proxy metrics:
- Deployment frequency
- Lead time for changes
- Time to restore service
- Change failure rate
Depending on how you score in these four metrics (you can do a quick self-check here), you are either a Low, Medium, High, or Elite Performer.
I recommend measuring these 4 Software Delivery Performance (SDP) metrics to answer the question of whether your ability to ship better software faster increases over time.
4 steps to avoid becoming a Cargo Cult
Besides asking the right questions (and answering them honestly), I recommend working data-driven to understand the principles behind Agile and Lean software engineering and to pick practices that actually work.
Here are the 4 basic steps I use for a successful Agile transformation:
- Start measuring
- Create a scoreboard
- Set a goal
- Move the needle
1. Start measuring your Software Delivery Performance (SDP)
Getting these four numbers is relatively easy. There are tools that offer dozens of integrations with issues trackers like JIRA or continuous deployment systems like Jenkins. But in the beginning, you don’t need that.
Suppose your Software Delivery Performance is low, and you deploy only once a month. In that case, it’s sufficient to update the scores manually by asking the teams or departments how often they have, for instance, deployed this week.
As your SDP increases, manually updating the scores might become annoying. That’s a good problem to have. Now you and your employees have an excellent reason to automate getting some of the metrics.
2. Create a scoreboard and make your SDP visible
If there is no scoreboard, you can’t tell if you are winning the game.
It’s actually worse. Without a scoreboard, the game will be boring. That’s because the players on the team will not be compelled to give their best and push their limits.
I recommend tracking all 4 SDP metrics as KPIs and making these KPIs visible to everyone within your organization.
3. Set a goal to impact the SDP
Next, create annual and quarterly OKRs that aim to improve the 4 SDP metrics.
Objective and Key Results (OKRs) provide an excellent framework for improving these metrics.
In this context, the Objective could be about taking the next sprung up the Low-Medium-High-Elite Performer ladder. And the Key Result could have the character of:
“Increase <SDP METRIC> from <CURRENT LEVEL> to <NEW LEVEL> by <DATE>“
4. Move the needle by acquiring SDP Capabilities
The DORA research program has identified about 30 Capabilities that predict Organizational Performance and Success.
That means most high-performing companies mastered practices that support these 30 Capabilities. And the majority of low-performing companies do not have developed these Capabilities (yet).
In this final step, pick one (or more) Capabilities and start working on acquiring or improving these skills as OKR Initiatives.
Capabilities are not Practices
Capabilities are not necessarily concrete practices.
Take the Capability of Continuous Testing, for instance. Acquiring this Capability requires restructuring your departments into cross-functional teams, and it requires all team members to learn about unit, integration, and acceptance tests. High and Elite Performers master, in addition to that, the art of Test-first Programming.
It’s not always immediately clear how to acquire a particular Capability.
That’s why I combine the concept of Software Delivery Performance with eXtreme Programming (XP).
eXtreme Programming (XP) is a little more complex than Scrum (which is merely a framework), but XP is clearly less complicated than SAFe.
What I like about eXtreme Programming (XP) is that it’s much more specific when it comes to Agile practices that actually work. For instance, Pair Programming, Test-first Programming, or Emergent Design.
XP takes everything that works in software engineering and takes it to the extreme.
Scrum has no opinion about what practices to use, and exactly this invites many problems. XP practices, on the other hand, were carefully chosen because they have proven to work and because they help avoid common issues when adopting Agile.
So instead of wasting time with trial and error, I recommend trusting this Agile methodology, which already has most things figured out for you.
Summary
Here are the 4 basic steps again, that can help you avoid becoming a Cargo Cult:
- Start measuring your SDP
- Create a scoreboard and make your SDP visible
- Set a goal to impact the SDP
- Move the needle by acquiring SDP Capabilities
If you want to learn more about eXtreme Programming or Software Delivery Performance Metrics and Capabilities, reach out here. And in case you are interested in mastering the art of Test-first Programming, I recommend checking out my online video course or signing up for one of the upcoming live classes.
See you around,
-David