We are all doing high-frequency waterfall. Agile won’t save us
More often than not, I see software companies being stuck in what I call Design, Build, Ship. They are so focused on making their ideas come to life, that they forget to test whether the ideas were any good in the first place.
Product builders often neglect to test whether their customers actually have the problem they are trying to solve and whether there are enough customers to make up a market.
There are several things to test before any development efforts make sense. First; are we trying to solve a real problem? Second, if users actually agree on the problem being worthwhile solving: are there enough of them to make up a market for your product? Next, if the problem actually exists for a decent amount of people; does your solution actually solve the problem? And finally, are people actually willing to reach into their wallets to pay for your product?
There are so many unknowns that need to be checked off, before it even starts to make sense to initiate any development work.
Agile to the rescue
We tell ourselves that agile development will come to the rescue. That if we part our development work into short sprints, we give ourselves the option of changing paths along the way. Afterall, doing agile should make us agile, right?
Agile was originally about reducing uncertainty and maximizing learning, but it seems that the original true version of agile didn’t survive its growth and popularity. Agile today often ends up being high-frequency waterfall.
The original promise of agile make sense. One of the key values of agile; responding to change over following a plan1, is exactly what we are looking for.
However, Scrum, XP, and other agile implementations fail to answer what changes we should respond to. Agile fails to ask “why”. All Scrum ceremonies – planning, refinement, daily stand-ups, review, and retrospectives – all focus on answering when, how, and what to build. There is no ceremony in Scrum that asks “why?” Why are we building this in the first place?
Scrum and agile aren’t bad. They just are not delivering on being agile in every respect. Scrum is great for letting teams focus on executing incremental change. But it often struggles to accommodate for learning and taking action along the way.
Why is that?
You cannot eliminate uncertainty by building a backlog
At the start of a development project, everyone involved in bringing an idea to life puts their effort into building up the backlog in an attempt to grasp the entirety of what they are trying to accomplish.
As humans, we naturally try to avoid ambiguity and uncertainty and have a bias toward seeking closure and completeness2. Not knowing better, many teams try to avoid uncertainty and succumb to this bias, by hurrying to establish a full backlog of what needs to get done.
As works is broken down into sprints, it starts to resemble an actual plan. The problem with plans is that the intention is to implement them. It is just too easy to see the backlog as a massive pile of “work to be done”. When you see it as work to be done, you tend to focus on what and when to build. The result is product tunnel vision.
Too much focus on what and when to build without asking why, creates tunnel vision.
To escape the tunnel vision, we need to find a way of regularly asking “why”? Why are we building this?
Too often, teams look at the massive pile of work to be done and start imagining solutions in their head. They visualize in their head how to implement the pile of work, telling themselves “I don’t think that will be too hard.” However what happens too often, as teams gets their hands dirty and start building, is that reality turns out to be more complicated. Suddenly a problem comes out of nowhere, leaving teams asking “why didn’t we catch this earlier?”. They get stuck. During implementation.
You need to do more than thinking to build successful products
Teams get stuck in implementation when the planned solution, only visualized in their heads, is only imaginary. Thinking about how you are going to execute on something is not the same as doing actual work to figure out what the best solution is.