Building software products together requires great communication. With so many people involved, success depends on how well these partners collaborate.

In the last two decades, communication regarding software products has improved drastically. Developers used to complain about half-assed requirements documents written by someone who didn’t understand the tech. These days we complain about having too many feedback mechanisms and alignment tools. I’m very optimistic about the progress that has been made here. It’s better to have too much communication than not enough. It’s better to involve too many people than not enough.

Yet one communication tool that used to be central to software development has been lost. At the heart of every software project used to be the plan. No tool has been taking a back seat as much as planning.

What used to be the staple of software development is now a sideshow at best. We had a plethora of dodgy tools and tricks to try to answer the age-old question: “when will it be done and how much will it cost?”. But ever since “agile software development” devolved into “Agile”, the industry has gotten hostile to plans. Developers took its pulse and called it. Time of death: February 2001. We don’t “do” planning anymore. All forecasting is BDUF and Waterfall, don’t you know? If we were to set a single deadline, the terrorists win.

Talking about planning on LinkedIn invites the reply guys. They’ll quote Muhammad Ali. They’ll misquote Eisenhower. Their argument usually boils down to “All plans/managers are dumb.”

Why are we so opposed to planning?

The revolution of agile software development was a counter-reaction to rigid Iron Triangles. Experienced developers found out that they constantly needed to make the damn thing work during the last weeks of the “testing phase”. So they asked the right question: If we still need to wing it after all this rigid planning, why have those phases at all? Somehow, throwing out the expensive “analysis and design” phases has turned into eschewing all plans. I feel we have made the strategic error of putting planning into the same trash can as the Iron Triangle.

The problem with the Waterfall-style approaches of old was never the planning. It was the forecasting based on dubious estimates. It was the separation between thinkers and doers. It was the slow speed and high cost. It was measuring progress through Earned Value estimates of estimates. It was the belief in defining a solution before building it. It was never the plan.

The plan is the single best conversation tool that ties the company together. When a feature turns out to be more complicated than expected, this impacts the entire business. The developers need to allocate more time. That time will come at the expense of another feature. A big customer might be interested in that feature that now has been dropped. This has implications for Sales and Marketing. Maybe we need more budget? Maybe it’s back to the drawing board? When we adapt to the new reality, we update that single source of truth so everyone knows.

Yet in our industry, we’ve come to equate planning with overly detailed rigid Gantt charts and micromanagement. With all the bad stuff of the old world. If you plan, you must be doing Waterfall!

Framing planning as just an evil tool to pressure developers is lazy. Plans are vital when building software products together.

This wouldn’t be a problem if agile software development only impacted developers. Unfortunately, that’s not the case.

Stakeholders need plans. They want to see what will be done by when and how much it will cost. Sure, there is some wiggle room and leeway. Sure plans can change all the time. But stakeholders need to know the ballpark figures and high-level projections. If you are going to spend the limited company resources, you need a business case. Any technical leader worth their salt should be able to help with that. This is an extremely reasonable demand.

A lot of the modern-day management techniques focus on prioritization, rather than planning. We can tell you what we will work on next, but we don’t really “do” forecasting or projections anymore. These techniques are optimized for the product teams, not for their stakeholders.

Putting out a Now-Next-Later roadmap works magic for the product team. But it doesn’t answer the stakeholders’ “When?” question.

A backlog with shifting priorities is the easiest way to agree on what to work next. But it doesn’t answer the “What?” question.

Over the years, I’ve come to see the plan as the number one communication channel for developing software. It’s vital and I hope to convince more technical leaders to see its value.

We don’t need to be able to give a fixed Iron Triangle with detailed scope and tight deadlines. Nobody is asking for that.

But we need to do better than vague priorities and “it’s done when it’s done”.

Let’s help build reasonable, realistic roadmaps that are flexible where needed.

Let’s help our team members and stakeholders in focusing on the right things, so we can guarantee the promises we make to our customers.

As technical leaders, let us build a plan that our business can gather around.

Because if we refuse to, someone else will. And that someone will be far less qualified by definition.