You're not doing Agile right if you're not addressing your biggest risks this way
Oct 13, 2020 · 10 min read
You're not doing Agile right if you're not addressing your biggest risks this way
Every so often a debate flares up on the internet about the value of agile software development. My response is usually to look at my screen with an eyebrow raised and think "What's the alternative? Wasting a load of time building something and then learning that nobody wants it?"
The arguments against Agile tend to sound something like: "there's no planning involved", "there's less predictability", "it takes longer to finish a project", "there's no strategy", etc. At the heart of these is a clear sign that their company– management in particular– probably doesn't understand how to effectively use the agile process to bring about better results. Many people in the industry are exposed to these poor and/or incomplete implementations of Agile, and end up soured on using it in the future.
There are, however, a growing number of companies that have been using agile processes very effectively, and there are a number of brilliant evangelists out there, in particular Marty Cagan, who have promoted more effective product development processes for years. To restate one of Marty's phrases: at its heart, Agile is about validating assumptions as early as possible so you can address and reduce the risks of your investment. That is, address the things you don't know, the parts that seem difficult, whether users are able to use your solution, and whether it will successfully meet their needs.
Getting the most out of your agile process means understanding and breaking down the risks of all the ideas on the table so you can find the right piece of work to do in the very next iteration.
At each step you want to focus on the work that will teach you the most and cost the least; work which can address that risk and deliver value. A few examples of what that next most cost effective step might look like are:
Before you've decided to work on a problem, you can validate through user research that the problem is one that's worth spending time on.
Before you've decided on a solution, you can verify that your potential customers would understand it and find it useful.
Before you scale out a solution for everyone, you can build a prototype and verify that it's feasible to build and truly solves the problem for your target users.
Before you've built out every bell and whistle, you can validate that the core of the solution solves the main problem at hand.
As product developers, we're rarely likely to get it right the first time. Releasing the first version of a solution isn't the end– it's just the beginning of a new learning cycle. Once your initial solution is in the hands of real users, you'll have more feedback coming in that will help to inform your next steps.
Agile provides a framework for this iteration to happen continuously, but following an agile process alone doesn't guarantee that anything of value will be produced.
The purpose of an agile process is ultimately to "de-risk your investment" as much as possible. Good poker players don't pray for a miracle and place all their chips on one bet; they weigh the odds that their cards are a winning hand, balance it with the odds that they're wrong, and place a bet that they believe is worth the risk– as in, not losing more than they can afford in a single hand. Although you might win a hand in poker by bluffing, bluffing won’t win you anything when you're building a product (I guess it could win you something in marketing, but that's a different blog post!). In an agile process the trick is to identify the right batch of work that successfully reduces your risks for a cost (i.e. one sprint’s worth of time) that you can afford to lose.
Our team's preferred way of figuring out the right work to do– work that reduces risk and moves us toward our end goal– is to build a simple effort/value matrix with all our options, then spend time debating and moving the options around on the matrix as we develop a more accurate sense of what they will cost and what they could lead to. We chose effort/value because the two axes help to break down where the main risks are in ways that a flat prioritized list doesn't. If you're used to using a prioritization method like RICE, that could work too, however we prefer effort/value since it allows us to easily visualize where everything falls on a simple grid.
With product, design, and engineering at the table, together we can come up with a fair assessment of what the relative effort and value is for each idea. Once we complete this exercise we'll have 4 buckets of work which we can follow a specific playbook for:
Low Effort / High Value
These are the obvious quick wins. You probably don't need much debate there– just do them if they're truly cheap to do.
There could be some risk that you've overestimated the value or underestimated some of the effort– we all like to be optimistic after all. These risks are easily mitigated though. If a piece of work takes much more time than expected, you can timebox it and re-assess the risks that remain to be addressed. If you overestimated the value, you’ve still only invested a small amount of work in it, and you’ll also gain some learnings from seeing it in use.
Low Effort / Low Value
These may be fair to do if you have the time. There's always a chance that you've underestimated the effort or the value, and end up learning that something is going to be harder than you thought (timebox it and cut it out early), or it may be more valuable than you expected.
High Effort / High Value
This is where careful deliberation is needed to determine how to proceed. Some of it may be table-stakes work you need to do, others may be big opportunities you see that may bring value down the road.
One crucial step you can do here is break down where the hidden costs are. Is it high-effort because there are a lot of unknowns on how to solve the problem? Is the underlying technology complicated? Will it be an uphill battle to get users to understand or adopt it? The answer to these questions will inform the next step to prioritize. You may need to focus on research, design work, or prototyping, etc.
Another thing that may be happening is that the value of these ideas was overestimated. Is it really going to impact the number of users you think it is? Will it solve their problem as effectively as you believe? Will it really lead to activity that impacts your metrics / KPI’s? Answering some of these questions may require more research, or rapid prototyping to prove that the core of your solution will provide the value you think is there.
High Effort / Low Value
Any items that fall into this bucket will likely be things you want to cut from your docket of work. Any time you can validate putting something in this bucket, you’re helping your team focus more on work that matters; prioritizing effectively is as much about figuring out what not to do as it is about figuring out what to do.
I will say that sometimes there are disagreements about what falls in this category. Sometimes a team member or stakeholder has a strong hypothesis that there’s more value to an idea than others believe. After all, some of the most innovative products may have sounded downright mundane when they were just a sentence scribbled on a post-it note (A telephone with a camera built in? Who needs that!).
Ultimately, your product, design, and technical leads need to determine what the right number of “chips” are to spend on these long-shot ideas. Maybe some are worth a quick prototype to explore, and maybe others need some additional research.
Doing Agile right
By doing this effort/value exercise together– populating the matrix and then negotiating each item’s placement through discussion– we’re able to figure out how to use our time most effectively in each cycle of our agile process. Once we see where each idea on the table sits on the matrix, we’re able to talk about the hidden costs we see and determine what our goals should be in the next sprint, what work needs to be done to reach those goals, and who on the team is best suited for that work.
Many companies today treat agile development as a conveyor belt for getting features out the door. But simply breaking up your development roadmap into 2 week chunks doesn’t ensure that you’re effectively solving the problems your team’s being tasked with (really all that will do is make it take longer to do what you would have done anyway). By deliberating on the risks associated with each piece of work and choosing the most suitable piece to address that risk, you ensure that your team is on the path to solving those problems more effectively.
Agile development touts itself as a process for delivering continuous incremental value. A team will only deliver value if they’re focusing on the right stuff in each iteration. The right work to do is something that addresses your risks up front– the risk that users won’t use your solution, the risk that it’ll take a long time to build, the risk that there are design or business concerns to solve, etc. When your team can easily discuss and debate the effort and value of their options they can self-organize and be better equipped to spend the right amount of effort on the right work at the right time.