Planning is a polarizing topic in software development. The reality is that all different types and amounts of planning will get the job done, and software made it into production long before people were arguing about when and how a plan was created.
In more traditional waterfall organizations, every bit (or so we thought) of the work is planned out ahead of time, sometimes months ahead of time. Before the programmers go to work, something akin to a small novel will be handed over explaining each little detail of how the software should look and work.
At the opposite end of the spectrum is the agile crowd where the perception is that no planning occurs at all.
Planning comes in a few different sizes — plan, strategy, and tactic. The closer you get to tactics, the closer you are to the specific details of how work the work is actually getting done.
Regardless of what level the planning is happening at, the goal is to better understand the work ahead — what is important, what is not important, how and who should be doing the work. I’ve worked on projects at both end of the spectrum. Some of the projects were painful, some I enjoyed a lot.
What Didn’t Work Out
At one point in my career, I was working for a company building a software as a service platform. We were building features fast and releasing once a week. That part was pretty cool. There was a lot of planning involved, really, a lot. Detailed requirements were developed with the client 6 months or more before development started. Most feature work was preceded by a long prescriptive document telling the programmers how to program and the testers how to test.
We had a plan on paper and we executed on the plan.
Often by the time a feature was a tangible thing in the product, the customers goals had changed and any nuance was long forgot so questions that come up couldn’t get answered well if at all.
Our plan wasn’t very helpful for the customers.
What Did Work
At another company using a slightly slower release schedule, every other week instead of once a week, we used a mishmash of planning techniques. Sometimes we got information in a long format, sometimes there was a sentence or two in the bug tracking system, and sometimes it all happened through conversation.
The point is that there was always a plan, or strategy, or whatever. It just wasn’t always documented. The emergent parts, the stuff that came out of conversation, was sometimes only kept in our heads. That didn’t make it any less of a plan though. It may have made the plan more relevant.
I think not fussing over ceremony and writing things down and having a final version of requirements that were ‘signed off on’ was a significant advantage.
The Map or The Territory
That saying ‘the map is not the territory’ exists for a reason, probably because someone got lost. When we create a plan, it is an approximation of what we want to do. That plan might based on similar projects we have worked on in the past, or information from someone in or dev groups or maybe the client, or it might be mana from heaven.
Regardless of where the information comes from, a plan is imprecise, it is a series of interpretations (that may or may not be right) of what we’ve learned from someone else.
If you want precision, write it down when the project is done.
Having something down on paper doesn’t mean that the plan will be useful in any way at all. Not having something documented doesn’t mean there is no plan. The real value is found when we can adapt and change based on what we’ve learned about the needs of our customers.