Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. Adopting an agile process does not let you magically have a more successful product. What makes agile powerful is also makes it dangerous.
Triage and Urgency
One tenet of agile is to make decisions at the last responsible moment.
Following this powerful and easy-to-remember mantra reduces the risk that you are wasting time on unnecessary work. This approach also maximizes the opportunities to better inform your decisions and actions. By delaying when you do any particular activity, one of two outcomes is created. Either the activity is never done, or the urgency of the activity grows until the penalty for delaying is larger than the risk of wasted effort.
There is always more work to be done, than can be done. Product managers and product owners know there is always more work to be done. Either implicitly, or explicitly, a product roadmap is a plan built on a series of hypotheses. There is always an opportunity to validate or refine every one of those hypotheses. The art of good product management includes having good instincts about which hypotheses embody too much risk, and which ones are solid (enough).
Every day’s work, when you’re being agile about it, should start with the question – “what is the most important thing for me to work on, today?” There’s a problem, not with the concept, but with the application. Most people conflate urgency with importance. There’s even a matrix to help people deal with this. Combine this with the “last responsible moment” mantra, and urgency becomes the trigger in their triage process.
The weakness of an urgency-driven triage-based approach is that it only looks at one side of the coin. Triage helps you avoid wasting time on unneeded activities. It does not prevent you from skipping needed activities. That’s the other side of the coin – important stuff which gets ignored because it never develops enough urgency until it is “too late.”
Ever heard of a team who deferred creation of an automated test harness because everyone is too busy fixing bugs? What about a team which has too much on their plate to consider refactoring? Too busy grooming the backlog for the next sprint to invest in developing a strategy?
This happens because our intuition about urgency is not good enough to balance the immediate with the long-range. Evolution wired us to respond to hungry predators – urgent problems. It seems reasonable to me to expect us to be weak at estimating the “actual urgency” of activities with limited immediate benefits and very immediate costs. The expression dig your well before you’re thirsty keeps coming to mind for me.
Game Theory
So, it turns out you can play a variant of the prisoner’s dilemma with your future self, by looking at the benefits and costs of your actions, both today and in the future. You do this by imaging the cost-benefit to your present self versus your future self.
Paul Young’s recent (and good) article about the conflict between agility and strategy is what inspired me to explore the following scenario.
Consider the bi-weekly choice you have to make as a product manager / owner: Do I fill up the backlog (Scrum process) with the best stories I can today, keeping the development team busy; or do I spend two weeks improving my strategy by getting and processing information about the market?
[Note: I know I’m creating a false dilemma to amp up the drama. Pretend I’m being reasonable and talking about changing the proportion of time being spent on each activity]
If I fill up the queue of work for the team – to the best of my present ability, based on what I know right now – I incur a small immediate cost – increased angst and worry about the quality of my strategy – and I receive a large immediate benefit – a content development team. My future self risks a large future cost – the strategy was wrong – and a small future benefit – the development team has been busy the whole time.
If I make the other choice – to invest in understanding my market, here’s what happens. My present self receives a small immediate benefit – satisfaction in an improved or validated strategy – and incurs a large immediate cost – my boss complaining about an idle development team. My future self will receive the large future benefit of a successful product and an ultimately successful and happy development team, if he doesn’t get fired first.
The immediacy and visibility of “wasting” the team is obvious*. In the grand scheme of things, it is also a very small cost. The uncertainty and abstractness of having the wrong strategy is vague and nuanced.
*I don’t really accept the premise that not building product is always waste. If you’ve got a tree to chop up for firewood, how much time do you spend chopping, and how much time do you spend sharpening your ax? If I need to understand my market better, I can ask the team to sharpen their axes. Their time won’t be “wasted.”
Rich Mironov offered a great tip to me too – have the team pick what they work on for the current sprint. If you’ve shared your insights with them, they are likely to make on balance good choices, so the “waste” of any bad choices is further reduced. Thanks, Rich!
There’s a pretty good analog in how we approach diet and exercise. The small (but visceral) sacrifices we make in the present determine the large (but presently intangible) results we realize in the long run.
In reality, this is not an either-or decision, but a time-allocation decision. What percentage of your time do you spend on understanding your market? Or how much time do you “steal” from the tactical urgent stuff, to work on the strategic important stuff?
Because we under-appreciate the value of improving the strategy, and over-index the cost of immediate issues, product people (owners, managers, champions, presidents) will be biased towards addressing the urgent. Behavioral economists have a term for this – hyperbolic discounting .
This is what makes any process which amplifies or leverages urgency a bit dangerous. It biases us towards further under-emphasizing the not-visibly-urgent, yet still important.
Conclusion
Agile can be fantastic for your company. Agile is not, however, magic – if you do it wrong, and under-invest in strategic thinking, you could actually be worse off than if you had stayed in the waterfall.
Thanks to @RichMironov for review & insights on this one.
Regarding “idle” development teams (while product managers work on strategy): helpful suggestions – both yours (axe-sharpening) and Rich’s (trusting your teams to choose the stories you might have selected). Two more: Give your teams a sprint to work on bugs (if your teams are like mine, we have a backlog of ignored “minor” bugs). A corollary: give your teams a sprint to work on paying down technical debt; they’ll thank you for it! (Before agile, when product managers were consistently “distracted” from giving us new projects by getting the current project shipped, smart engineering managers used the “down time” for team-building and technical-debt-paydown activities.)
Thanks Ron, and welcome to Tyner Blain!
Both bug-hunting and refactoring are great uses of time. I put them in the axe-sharpening category, because they make future work on the project easier, more enjoyable, more productive. Thanks for calling those out!