The Plan is Dead, Long Live the Plan

Tell me if this sounds familiar:

An hour(s) long meeting, involving an entire cross functional team, discussing work to be done. Questions are asked, assumptions are challenged, all in service of having consensus on The Plan. At the end of the meeting, everyone goes their separate ways and gets to work. And it quickly becomes apparent that there isn’t consensus. Not all the questions were asked or answered. Not everyone interpreted things the same way. The Plan is open to interpretation…thus, the plan is dead.

Kind of makes that long ass meeting seem like not the best use of everyone’s time. So if getting the full team into the same room (virtual or otherwise) at the same time to discuss the same challenge doesn’t result in clarity regarding upcoming work, what the heck does?

The best answer I have is one many folks won’t like, and capitalism doesn’t really encourage: patience. A mature team - one that meshes well and works effectively together - is your strongest chance of success. Period. And, unless you get reeeeallly lucky, a mature team just takes time and persistence to build.

So, try again. And again. And again and again. One bad planning meeting doesn’t necessarily mean it’s time to abandon ship and become a pack of lone wolves. It means you haven’t figured out how to effectively plan as a team, yet. Maybe the planning meeting was too long and folks tuned out. Maybe not everyone needs to attend at the same time. Maybe the scope was too broad or just too large to have a meaningful planning session around.

Please don’t do literally the same exact thing - think critically about what went wrong, and try to do something differently next time. Bonus points if the new approach is devised with direct input from the team. Practice makes it a habit, but participation makes it perfect. When something doesn’t go as expected, it’s a learning opportunity. Try not to get bogged down with guilt or shame or frustration - they’ll help you feel bad, but that’s about it. Instead, focus on the lesson(s) you can take away, and do your best to internalize them.

My most vivid example of this comes from a startup I worked at a while back. The team was pretty small, about a dozen or so people. I joined at a point when the founders realized their breakneck pace combined with lack of process was becoming a bottleneck.

The team was feeling the pain, and was on board with trying some flavor of agile. Many - if not most - of the team had little prior experience with agile (or indeed, any other framework), including the person who had been acting as project manager to that point. So we did a brief internal roadshow to explain how we anticipated agile working for us, then scheduled our very first sprint, beginning with our first planning meeting.

The meeting included literally the entire company and was scheduled for an hour. I don’t remember how many tasks or features we had anticipated reviewing, but suffice it to say, there were a lot. Most had extremely bare-bones requirements - usually a vague title, and nothing else.

That meeting dragged on for at least 3 hours, and by the end of it, I don’t think we were any closer to having any tasks planned out and ready to build. It was extremely frustrating, for all involved.

I was told in no uncertain terms by senior management we could not repeat that experience. So, I started thinking about what and where we went wrong:

• the acting PM at the time spearheaded the meeting, and leading a meeting - especially of a type they hadn’t experienced before - was not their strong suit. There needs to be an arbiter present who can help guide and clarify conversations to keep things on track, and this person could not command a room. No fault of their own, just not something they were good at.
• we had Way Too Many tasks lined up to discuss. Especially given that a lot were very large features, and hadn’t been mapped out or discussed in any depth prior to the meeting. We were coming up with the requirements live, rather than prioritizing and deciding on a reasonable set of work for the about-to-start sprint.
• there were too many people. I get why we had the whole company present - we were fairly small, and it was a “big new thing” we were trying. And while I lean towards inclusivity, sometimes a smaller, more focused group is more efficient. For sure, the CEO and COO got nothing (but frustration) from being in that room.
• honestly…we rushed into it. Our backlog was nowhere near in good enough shape to start planning against. Most tasks had a title, and that was it. All the details lived inside someone’s head. We should have been spending time extracting those details and spelling them out before getting the whole team in a room to ask “so how many of these completely ambiguous tasks can you get done this Sprint?”
• and, finally, a culmination of all of the above: the meeting went Way Too Long, and everyone could feel it. I wouldn’t wish it on my worst enemy.

So here’s what we did to improve:

• I led our sprint meetings from then on - planning, standup, retros. The acting PM was instead able to focus more on research, testing, and documentation.
• We did spend a lot of time working to make the backlog meaningful. That meant a lot of smaller, more targeted backlog review meetings. We’d meet with just the backend developers and CTO and break out & clarify their tasks, then do the same with frontend, and design. We did this a LOT up front (at least two or three 1hr sessions per week), but were able to pare back to a more sustainable cadence (a single 1hr session every other week) after a few sprints.
• Doing the above allowed us to conduct actual planning meetings - as in, reviewing well-defined & already prioritized tasks, adding any additional detail needed after a quick review with the team, then estimating and agreeing to the workload. This let us focus the session on reviewing and assigning until our sprint was full, without exhausting ourselves with discussions about work falling beyond that sprint’s capacity - we knew we'd get to 'em next time.
• We pared back on the required attendees for all our meetings. Planning usually did involve the entire Sprint team (though not always), but the executive team and supporting roles like business development, marketing, and so on rarely attended.
• And, lastly, related to all the above: we were able to keep planning meetings to an hour or less (once we got into a groove, it was often 30min or less).

Obviously, that all took some time to implement. Time, experimenting, and patience. But we did get there, and never suffered through a 3+hr long flail session again.

If your team is struggling, take some deep breaths. You're not going to have one shitty planning meeting, reflect on it overnight, and arrive with a perfect solution the next day. As we did, you'll need to spend time learning about your team and trying new and different things until you gradually find what works. So keep planning, keep iterating, and maintain patience.