Answer these 9 questions to find out how agile you are…
1. Are you customer obsessive?
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.
2. Do you “say no to 1000 things”?
The Agile Manifesto says, “Simplicity–the art of maximizing the amount of work not done–is essential”.
Steve Jobs said it better: “Innovation is saying no to 1000 things”. He was ruthless about prioritisation.
How do you decide which 1000 things to say no to? Read on…
3. Do you do experiments?
Competitors evolve. Customers evolve. Google changes it’s algorithm every three months. Technology is changing.
In the face of uncertainty, how do you know which features will drives success?
“Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day”
Jeff Bezos
In 2013, Amazon did 1976 experiments. In 2019, Google did 464,065 experiments! Modern Agile embraces experiments.
4. Do your goals describe outcomes?
Google has a framework for setting goals called OKRs. Google says that OKRs “must describe outcomes”.
Sprint goals should also describe outcomes. 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:
“Enable links to Renal Drug Handbook, ultimately to improve the CM tool for users and increase usage of the CM tool by 10%”
It doesn’t mention the real goal, which is to retain/increase sales (which will impact the north star metric). Instead it specifies an easy to measure non-goal (increase CM usage by 10%, which has minimal impact on the north star).
If the team doesn’t understand the goal, how can they have a meaningful conversation about how to achieve it? In your Sprint Reviews, how will you show if the enhancements delivered the intended value? You can’t.
5. Are you hypothesis-driven?
It’s easier to do the right experiments 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. Are you data-savvy?
Hypotheses, goals and experiments all require being data-savvy.
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”.
Scrum is founded on empiricism but doesn’t give any details. The best guide I know to being data-savvy is The Data Detective by Tim Harford.
7. Do you constantly adapt?
Your plan to achieve the sprint goal needs to adapt 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).
The Scrum Guide says, “[developers] often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work”.
8. Does your UX go 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 (see question 5).
9. Are you non-linear?
Does your product development feel a bit messy? It should do, because solving real world challenges is messy. (In my next post I’ll show how to visualise it a neater way).
Is the team creative? Do you seek diverse views? For an example of this approach check out Dual-Track Agile.
- Engineers should NOT just implement a solution, but should get involved in “what problem should we be solving”.
- 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 is why Question 2 is so important: you have to be ruthless prioritising which challenges the team should tackle.
Notes
1. Agility. Sports science describes agility as “involves reactive abilities in unpredictable environments” (see here). It’s actually very hard to find a good definition of agile!
2. Innovation. Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in 1986 (see here). They argued that Scrum is “especially good at bringing about innovation continuously”. This echoes Lean Startup’s “constant innovation”.