I came across Cedric Chin’s excellent piece today: You Aren’t Learning If You Don’t Close the Loops.
It centers around the PDSA loop, a version of the scientific method applied to business, which I found fascinating – but a particular aspect of the article I loved was the challenging of the sunk cost fallacy.
Like most things from rational choice theory, the sunk cost fallacy assumes you can make reasonable guesses about payoffs, which isn’t as easy to do in real world business. Let’s say that you have a four month execution loop that’s not going well (i.e. you have a bad feeling about it) and it’s just two weeks away from completion. Should you burn the loop and focus resources on something more likely to be useful? Or should you just eat the two week cost in order to get the maximum amount of learning from the data generated? (Bear in mind the data generated may well cause you to update your feelings about the execution).
I just finished up my first year at my first in-house product design job (coming from an agency background), and of the many many things I’ve learned, one of them is that the goalposts be shiftin’. Agile is a powerful framework, but I’ve watched it empower PMs to scrap projects, mercilessly trim (what they see as) the fat, and pivot sometimes in circles. Not to say they’re not right most of the time, but as someone who runs his life from a to-do list — a never-ending backlog — it saddens me to see so many loops getting burned before they can be closed and learned from.
It seems a little ridiculous that you can forget to do something, but consider: certain loops in business takes months to execute. A new SEO strategy, for instance, takes at least six months before results show up. A lot of things can happen in six months. Your most important customer may cancel. You start losing deals to a previously harmless competitor. Your head of engineering tells you she’s quitting. In the mess of business execution, you ignore the fact that you’ve just spent six months on an experiment, and then you … forget. You don’t ‘harvest’ the learnings from that project, and those months of execution go to waste.
In theory, any team operating on good PDSA loops should be accumulating good information like compounding interest. The trade off, it seems to me, is the drag you generate by keeping projects going longer than an Agile-ist would be comfortable with.
Imperfect analogy alert: You know how sometimes you start a house project and it ends up stalling halfway through? I started building five wood picture frames for a gallery wall in our living room six months ago. I’ve built two. I haven’t picked up the project in months. Other projects superseded it – like building shelves for a closet and new doors for our shed. But I know damn well I’ll build those last three frames some day, because it’s still on the kanban board I use for our home projects. I’m not willing to give up the benefits of the completed project – not just the improved decor, but the lessons I’ll learn in the woodshop – just because it was deprioritized.