The Fuzzy Front End of a Project

Planning to Plan

Every project has a clear start to its development, like when the repo is created or maybe the Initial Commit in git history. But before any actual coding can begin, there’s a lot of planning. Depending on the complexity of the project planning happens at many levels, each one feeds to the next, lower level:

• Strategic Planning
• Project Planning
• Architectural Planning
• Release Planning
• Iteration (aka Sprint) Planning

Each kind of planning serves a different purpose and has a different audience, going from the high level planning, strategic, to a lower level, sprint planning. But, I want to talk about Architectural planning.

Architectural Planning

Also called Technical planning this is where software architects, tech leads and engineers get together to plan how the goals of the project are going to be achieved. Here the team talks about tools, different approaches, trade offs, pros and cons, etc.

These meetings are super interesting because each engineer has different experience and has value to add to the architecture. There are a lot of diagrams drawn or random boxes with arrows signaling data flow or actions, this is why it’s super helpful to have a whiteboard in the room or excalidraw if it’s a virtual meeting.

For more complex systems, there is an overall design that consists of abstract boxes on the diagram, and each one of those requires its own design. Then each of these might have their one thing that makes it difficult, so more planning… This is a slippery slope. 

The team can spend days or weeks planning trying to cover for all eventualities, delaying when the project development will start. This is why all this planning is called The Fuzzy Front end. 

While the team might have the best intentions to prepare for the upcoming project, there are things that they can’t solve just by planning, after all, the architectural planning is supposed to be high level, all the details can be fleshed out during sprint planning.

At some point the team has to start developing something and find if a solution or approach will work. Make a Proof-of-Concept or any kind of prototyping, otherwise it’s really easy to stay on that planning spiral. 

How to know when to stop planning?

This is a very difficult question. It’s hard to gauge how much planning is too much before the team gets to that point. I’ve been in planning meetings where we are all focused on some minutiae of how something works, which should be outside of the architectural planning, so maybe taking a break when going too deep into details or suggesting to create a prototype. 

When a meeting is getting too long, someone can create action items to conclude the meeting. Another approach can be timeboxing the meeting to create a forced stopping point (this can be enforced by having another meeting right after, which will prevent extended conversations)  then the team can decide if they need to schedule another meeting.

Conclusion

When doing architectural planning stay aware of how much time you’re spending, and how detailed you’re going. Architectural planning is supposed to be abstract, maybe define some contracts or data flow, but things have to be abstract: boxes talking to boxes.