UPDATE: There is a newer, shinier, quiz version of this post here.
The software industry is obsessed with Agile, but there is a big problem. Agile is very different from what actually drives successful companies.
Let’s look at what Agile is, and then look at what actually drives successful companies. We’ll look at Apple, Facebook, Google and Amazon.
What is Agile?
The most common dictionary definitions of agile are about moving fast. Here’s the Cambridge Dictionary’s definitions of agile:
- able to move your body quickly and easily
- able to think quickly and clearly
The Agile Manifesto echoes this by saying, “Working software is the primary measure of progress”.
Many Scrum teams embody this by calculating their velocity as user stories per sprint.
What drives successful companies?
Let’s look at the four outrageously successful companies and see what they can teach us.
1. Apple launched a product different to anything else: the iPhone. It was the first truly easy-to-use, web-enabled computer in your pocket. Using the iPhone was a totally different experience to using it’s closest competitor, the Motorola Razr.
2. Facebook developed killer features to overtake it’s main competitor, MySpace. In 2007, Facebook launched social games like Texas Hold’Em Poker, while MySpace launched MySpaceTV. In 2008 Facebook become the most popular social network.
3. Google succeeded by developing an algorithm for better search results. Google’s search did pretty much the same thing as other search engines (like Yahoo) already did, but Google’s results were more relevant.
4. Amazon realised that the web changed the rules of retail. Companies like Walmart optimised around limited shelf space, but the web made shelf space infinite. (Detail here).
What do these four examples tell us?
None of the successes were due to moving more quickly than the competition. The iPhone took 2.5 years to develop. Apple wasn’t any faster at developing phones than Motorola.
The key to success isn’t about going fast, it’s about going in the right direction. It’s about innovating.
In a world which is constantly changing, there is a constant stream of new opportunities and risks. Most companies fail to seize the big opportunities and avoid the big risks.
Apple realised that to take advantage of the shift from desktop to mobile, that the user interface needed to adapt.
Facebook evolved from a student directory into a social network, and then evolved further with games like Farmville.
Google‘s famous PageRank algorithm was adapted from an algorithm used to rank academic papers.
The secret is to adapt.
“It is not the product with the most users that survives, not the one with most features that survives. It is the one that is the most adaptable to change.“Charles Darwin
9 ways your team can be more innovative
1. Say no
Steve Jobs said, “Innovation is saying no to 1000 things”. He was ruthless about prioritisation.
But what 1000 things do you say no to? Scrum assumes that the Product Owner magically knows which features will drive success, and that the backlog is well prioritised.
But in reality there is huge uncertainty about what features will drive success. Scrum doesn’t say much about how to prioritise in the face of uncertainty.
The fastest way to reduce uncertainty is…
2. Do experiments
Jeff Bezos says, “Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day”.
Scrum doesn’t mention experiments.
“Modern Agile” does embrace experiments, but too many software people aren’t aware of this yet.
An experiment is a way to find out if a feature will be successful, while avoiding most of the work. The 80/20 rule says that you can expect 80% of the value from 20% of the work.
It’s not enough just to do experiments though. You have to do the right experiments. More on that in a minute.
3. “Customer obsession”
Amazon is famous for having a “customer obsession”.
Jeff Bezos often leaves one seat empty at important meetings. It’s there for the most important person in the room – the customer.
Do your sprint reviews focus on the impact you’ve had on customers and users? Or do they focus on number of tickets and releases? If it’s the latter then you aren’t being customer-centric.
4. Smarter goals
Google has a framework for setting goals called OKRs. Google says that OKRs “must describe outcomes”.
Sprint goals should also be outcome-based. Josh Sneiden explains:
“Mostly, we simply ask teams to build features—but features are the wrong way to go. We often build features that create no value. Instead, we need to give teams an outcome to achieve. Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do.”
Here’s an example of a weak Sprint goal:
“Complete the implementation for CME/CPD enhancements to improve the user journey. This we believe will help increase new and returning usage by 10%.”
The first sentence is a feature, it’s an output not an outcome. The second sentence is an outcome but it has no timeframe – it’s the (long-term) Product Goal not the Sprint Goal.
If the team doesn’t understand what outcome is wanted by when, how can they have a meaningful conversation about how to achieve it? In your Sprint Reviews, how will show if the enhancements delivered the intended value? You can’t.
5. Be hypothesis-driven
Doing the right experiments is much easier if you have a clear hypothesis.
Alistair Cockburn, co-author of the Agile Manifesto says
By 2012, the [Agile] innovators and early adopters, having long experimented with ordinary agile ideas, were moving to Eric Reis’ “lean startup” ideas. By 2015, they have graduated to what they called “hypothesis driven development”Heart of Agile
6. Data is a superpower
Hypotheses, goals and experiments all require being data-savvy.
Data can tell you what your users really care about, and what to prioritise.
That’s why one of Facebook’s slogans is, “Data wins arguments”. Facebook CIO Tim Campos said, “We use data to make decisions on everything”.
The best guide I know to being data-savvy is The Data Detective by Tim Harford. Unfortunately, Agile and Scrum don’t say much about data.
7. UX beyond usability
For Amazon, the most important part of the user experience is having a wide choice of products, low prices, and quick delivery.
For Facebook and Google, the most important part of UX is the content.
For the soft paywall I worked on recently, discoverability (SEO) was the critical factor, not usability.
For scenarios like these, you can experiment on a small number of users with usability being merely “acceptable”. Then, if the experiment is a success, you can invest time in improving it.
Of course, having a clear hypothesis helps you know if your experiments is a success.
8. Iterate within a sprint
Having two week sprints is fine, but adapting needs to happen daily, hourly, whatever it takes.
That’s why standups are every day, but even that isn’t enough. There should be conversations and decisions being made in-between standups. That’s why one of Agile’s principles is “business people and developers must work together daily” (not just talk together for 15 minutes a day in standup).
And someone needs to look at the data whenever is needed, not just every two weeks.
9. Non-linear development
Don’t just accept a challenge, iterate on “what problem should we be solving”. Seek diverse views. Prototype multiple solutions in parallel. Software development is a creative process.
Balance deep collaboration with deep solo work. Balance “fast” and “slow” work. (I’ll post separately about how having rows on your scrum board can help with that).
All this takes time and needs some slack, which leads back to point 1: be ruthless when you prioritise which challenges the team should tackle.
Does all this feel a bit messy? It should, because solving real world challenges is messy. In my next post i’ll show how to visualise it a neater way.
If it feels like your playing “race to the bottom of the backlog” then your doing it wrong.
Scrum does have some value: it places importance on incremental development, self-managing teams, and empiricism. And Scrum says to be laser-focused (one product/sprint goal at a time).
With the nine tweaks outlined in this blog post, Scrum can give awesome results.
Good luck on your journey to awesome!
Notes: interesting links and quotes
(a) Agility. Sports science has a better definition of agility: “a rapid whole body movement with change of velocity or direction in response to a stimulus”. (Source here).
Note that “User stories per sprint” is really speed, not velocity. (Velocity has a direction, speed doesn’t).
(b) How to adapt. The book Adapt by Tim Harford is highly insightful.
(c) Outcomes over outputs. In Jeff Bezos’ 2016 Letter to Shareholders he discusses the importance of focusing on outcomes over process and outputs. Scrum doesn’t mention outcomes.
(d) Prioritizing for impact. Google says, “… small teams can have a MASSIVE IMPACT. They can create new ideas, experiment, fail, and try again, and get their successes to a global market” (from How Google Works).
Jeff Bezos says, “Given a ten percent chance of a 100 times payoff, you should take that bet every time. But you’re still going to be wrong nine times out of ten.”
(e) Innovation. Jeff Bezos’ 2013 Letter to Shareholders said, “Innovation comes from distributed decision-making. Top-down teams are effective at optimizing existing processes and enforcing the completion of work, but only decentralized, bottom-up teams can consistently generate new ideas.”
(f) Non-linear development. For an example, see the Design Council’s Double Diamond framework.
Some boring details
(b) Amazon’s success. Retail is Amazon’s biggest revenue stream.
(c) Experiments. Apple’s experiments tend to be internal with Steve Jobs acting as a proxy for customers. If you are a genius like Steve Jobs then maybe feedback from actual customers isn’t so important!
Facebook succeeded by giving third parties a platform to experiment with content.