Martin Fowler long ago popularized the metaphorical “Strangler Pattern” (since updated to “Strangler Fig Pattern”) as a more graceful and less risky way to rewrite an existing system. He wrote of the Australian strangler fig plant:
They seed in the upper branches of a tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host. This metaphor struck me as a way of describing a way of doing a rewrite of an important system… An alternative route [to all-or-nothing big-batch replacement] is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.
When introducing organizations to probabilistic forecasting — which I simply describe as answering the question “When will it be done?” with less effort and more accuracy — the move from traditional estimating can often seem like a similar problem to that of Fowler’s legacy application swap: It’s a big change, fraught with risk, affects a lot of people, and we’re not entirely comfortable with or sure about how it works.
For these reasons, and because most sustainable change is best effected via gradual, safe steps, I guide teams to apply what is essentially the strangler pattern: Keep what you have in place, and simply add some lightweight apparatus around the edges. That is, continue to do your legacy estimating process — estimation meetings, story points, fibonacci numbers, SWAG and multiply by Pi, whatever — and alongside that, let’s start to track a few data points, like commit and delivery dates.
Kanban Method encourages us to “start with what you do now,” and one of the benefits of this approach (besides being humane and not causing unnecessary emotional resistance) is that it helps us understand current processes. It’s quite possible that a team’s current estimating practice “works” — that is, it yields the results that they’re seeking from it. If that goal is to provide a reliable sense of when something will be done, doing the simple correlation of upfront estimate to actual elapsed delivery time will answer that question (spoiler: Most teams see little to no correlation). That in itself can help people see whether they need to change: It’s the Awareness step of the ADKAR model. Continuing existing practice while observing it also helps us decouple and filter out the stuff that is valuable, such as conversation that helps us understand the problem and possible solution. NoEstimates, after all, doesn’t mean stopping all of the high-bandwidth communication that happens in better estimating meetings.
Meanwhile, we’re collecting meaningful data — the no-kidding, actual dates that show the reality of our delivery system. These are the facts of our system, as opposed to how we humans feel about our work, and as one observer famously noted, “Facts don’t care about your feelings.” But facts and feelings can “peacefully” live alongside each other for a time, just as the strangler fig and host tree (before the fig kills the host, of course). You can then start running Monte Carlo-generated probabilistic forecasts in the background, which allows you to compare the two approaches. If the probabilistic forecast yields better results, keep using it and gradually increasing its exposure. If for some reason, the legacy practice yields better results, you may choose to “strangle the strangler.” Most groups I work with end up appreciating the “less effort and more accuracy” of probabilistic forecasts, and after a time start asking “Why are we still doing our legacy estimating practice?” At that point, the strangler fig has killed the host, and all that remains is to safely discard the dead husk.
So to summarize the strangler pattern for estimating:
- Keep doing your legacy estimating practice.
- As you do, track delivery dates (commit point through delivery point).
- Run a correlation between the two sets of numbers (upfront estimates and actual delivery times).
- Continuously run probabilistic forecasts alongside the legacy estimates.
- Check the results and either keep the new approach or revert to the legacy.
As with most knowledge work in a VUCA world, whether it’s coding a new system or introducing new ways of working, reducing batch size — of which the Strangler Pattern is a type — offers more flexibility and reduced risk. If you’re interested in a better way of answering the question “When will it be done?” but need to do so incrementally and safely, the strangler pattern for estimating may be an idea to plant. (Sorry, couldn’t resist.)