Software development is rather predictable
We can't plan because software development is too unpredictable. I hear that a lot.
It seems to be a common sentiment in our industry, and it's easy to see where that comes from. The industry-standard 2-year fixed-price projects have given our field a bad reputation. The rise of capital A "Agile" has brought us fixed-price projects without any upfront analysis. Of course, those will derail. And finally, there is the Silicon Valley caricature of pivoting the entire startup every Monday morning.
But the truth is that software development isn't as unpredictable as we claim it is. Most teams capture feedback that slightly changes the road they're on. It's uncommon to gather new insights that throw the product into complete upheaval. We build software through small, gradual changes, not through big moves. That also means we learn in small insights, not in grand epiphanies.
Predictability doesn't mean we can foresee the future. Planning isn't clairvoyance. A predictable plan doesn’t mean a rigid plan. We can still change our minds. Predictability means we can change the plan because we want to, not because we have to.
In that way, building software is rather predictable. Or rather, we overestimate its unpredictability.
But sometimes, teams really have an uncertain situation. Every time they try to tame the chaos, their plan derails. Every other week, they look at their plan and see that it no longer matches reality. They are behind schedule and forced to pivot. This happens in three common scenarios, each with an entirely different solution.
Estimate-driven Culture
Estimates are a great tool for short-term planning. They are horrible for the long term. If your team relies on estimates for long-term planning, I can guarantee your software journey will feel unpredictable.
Up-front long-term plans are usually rigid and optimistic. As a result, the team will be behind schedule almost immediately.
While teams can get better at short-term estimates, they should ditch the 3-month Gannt chart mosaic ASAP.
Working with Focus Blocks and applying Iterative Buffer Planning is the way to achieve predictable long-term plans.
Too many stakeholders for the team size
The ideal team has a single stakeholder. That way, there's no discussion about who they serve. Unfortunately, some teams need to support multiple stakeholders at once. That requires some planning to keep everyone satisfied. It also requires a reasonable ratio of stakeholders to team members. An engineering department with two devs that serve five stakeholders is spread too thin. Too many stakeholders all but guarantee lots of last-minute changes in priority.
Limit the number of stakeholders and use a shared roadmap to communicate with them.
The team is involved too early
Sometimes, teams join a product way too early. While nobody is arguing for BDUF, there must be a clear vision of what the mission tries to accomplish.
I once joined a team to build the first minimal version of a startup's SaaS product. They had some funding and hired freelance developers to get started. As soon as the contracts were signed, the clock was ticking. We had three months to build the thing.
Unfortunately, it wasn't entirely clear what "the thing" was. The founders were still discussing their vision, market, and MVP. The scope of the assignment changed at every status meeting. We wasted valuable time on rework after rework. It was just too early to assign a team.
In hindsight, it would have been a lot better if they had taken more time to describe the problem they wanted to solve rather than rushing into implementing a solution.
All in all, software development is rather predictable if we pick the right planning tools, limit our target audience, and start with a good problem description.
While unexpected stuff will always happen, a good plan gives us the tools to steer the product. It acts as an early warning system that allows us to choose the next steps rather than having our hands forced by reality.
Teams that feel they can't plan because life is too unpredictable are not planning. They're trying to predict the future instead.