profile

Juani Villarejo

Planning for failure

This is essay is part of my Adventures with Shape Up. If you are into learning more about this methodology or how I manage projects , this might be interesting for you.

During one of our working cycles last year, we couldn't deliver one of the projects we planned to do.

The project couldn't be fulfilled. We found what in Shape Up is called a time bomb, a big risk that made us stop the project.

Having to stop a project in common managed companies can be a big loss. But for us, it's part of the plan. We plan for failure. Our expectations are that our projects can fail at any time.

In my company, Nulinga, we work with Shape Up in 6-week cycles, and just to give some context about this particular project, what we wanted to do was an integration with a Chilean state API called "Código Sence". This external integration provides a subsidy for companies that pay for their employees training.

But in this case, we had to put the whole project on hold.

During the middle of the working cycle, we learned the hard way that the documentation we had for the API was deprecated. When we tried to test our implementation, it didn't work. And when we consulted the API provider, they told us that we had to use a new API.

Usually, when we find a time bomb that leads to putting a stop to the project during the working cycle, we try to apply the swarming technique. We retreat two steps and think together to find a solution.

The team sets up a meeting with the technical leader and the product manager, and together they try to find a workaround for the problem. This is what we call "to defuse the time bomb."

But with this specific project, we couldn't find a workaround that would solve the problem within the time that complied with new information that emerged. The shaping we wrote was completely invalidated by this new information. So the project had to be canceled for the ongoing cycle. Nothing about it could be shipped.

In an ideal world, defusing the time bombs happens during the Shaping Cycle in a step that we call "de-risking". Here is where we try to find possible things, as a pre-mortem, that can go wrong with the project and try to specify a solution (or a workaround) for them.

And with this API integration, I can say that we failed at the de-risking phase. We didn't test the API before starting the cycle of the project. There wasn't any spiking regarding that. If we had, we could have made a decision before the working cycle had started.

It was a very certain risk. If the API doesn't work for the integration, there is nothing we could do on our side. It was the classic high interdependency with an external provider. And yet we didn't test it.

The sad thing is that we know a lot about the Shape Up methodology, and building software. We help other people to implement and learn about Shape Up.

But as the saying goes in Spanish, "En casa de herrero cuchillo de palo". A literal translation would be "in a blacksmith's house, stick knife." But the English expression is "the cobbler's children have no shoes."

We know how to shape, we know about finding risks and removing them, we know about interdependencies, and we give ourselves time to do the required spiking. But still, we missed this shot.

Maybe we didn't have enough time for de-risking during the shaping phase. Maybe we were very confident. Those root causes might remain obscure, but it doesn't matter. We know we can have blind spots, and we will certainly have them in the future.

We can't always hit the bullseye.

Although I am sad that we made this common mistake, I am not sad for not being able to deliver this project. As I said, in common companies, a leadership team or executives would be furious about this situation. But in my company, we don't.

And why is that? Well, an important part of this "planning for failure" premise is to not consider every project as a must-have. We don't have a specific project that it's a "need." They are all just "wants." There are multiple reasons for that.

First, as I said, we work in 6-week cycles. The number of weeks isn't strictly important. What is important is that we plan our work to be delivered in each cycle. There is no additional time. By the end of each cycle, the planned projects have to be shipped to production, adding value to our customers.

Of course, this last part of adding value isn't guaranteed. We aim for a high chance of success of the output delivering it, but the outcome is still uncertain.

Sometimes the appetite (budget) for the project is a 6-week full cycle, but other times it is 3 weeks only, just half a cycle. And a squad (a 1-2 person team allocated to a project) that's assigned to a project with a 3-week appetite can work on two of these per cycle. If one of those projects fails, as it was in this case, we can still aim to deliver the other one.

And another more important thing about working in cycles is that we can always try again on the next one if we still want to bet on the project at that time. We live to fight another day. If one of the projects fails, with the new knowledge that we gathered, we can shape the project again.

In our situation, as I said, when trying to test the integration, the service provider told us we were using the old deprecated API, and we needed to use a new one. We tried to save the project, but the new API was very different. It required a whole different user flow from the one we shaped, and this required more careful thinking about the consequences.

Second, we consider all our projects a bet. And this has huge implications.

A bet means that there are always risks. You can clearly define some of the risks and untangle them, but you can't foresee everything.

And thinking of your projects as if they were bets prepares your mind for the uncertainty, not only in outcome, but also, for being shipped.

Knowing that there can be unknown unknowns, blind spots, and that not every bet will be successfully delivered changes the way to plan and design the work.

It directly leads you to always look for alternative paths. To think and design your product and its projects to not have any strictly dependent trajectory. To not have any critical segment or destination.

There is no such thing as the one project to rule them all. No Silver bullets.

When we detect a problem for our customers (and we want to solve it), this bet mindset leads us to think of multiple ways we can solve it. So we don't have to bet an all-in on something.

If a project fails, either because the outcome wasn't successful or we failed to deliver within the assigned appetite, we can always try again with other ideas in the next cycle, conditional that the problem is still relevant for the next cycle.

Knowing that you can (and will) miss some shots changes the way you make plans.

Instead of roadmaps, bet on projects.
Instead of estimations, set a budget.
Instead of details, remove risks.
Instead of failure, acquire knowledge.
Instead of ruin, live to fight another day.
And... instead of destinations, embrace the unknown paths.