I don't like Scrum.
It's an overused, outdated office-centric methodology based around all-hands meetings. It treats software development as synchronous assembly line work while making management impossible. And worst of all, despite its meeting culture and all the estimating, re-estimating, prioritizing, and reprioritizing, it turns out to be pretty useless at answering basic When questions.
But there is one thing Scrum got right. At the start of every iteration, the entire team got together to update the plan.
Back in the days of project-driven development, the Project Manager was the sole owner of the plan. More often than not, he had an Excel file on his laptop that contained the only up-to-date copy. The PM told the developers what to work on. He asked them how much time they needed to complete the ticket. All of that info flowed back into his magical Excel file.
Planning was the manager's domain.
In most projects, there came a moment when it turned out that the plan wasn't feasible. At that point, the manager would involve the team to figure out how to get back on track. Drop some scope, cut some corners, add some team capacity. Halfway through the nineties, developers started to wonder out loud why they were only involved in planning when the project was already behind schedule.
One of the main lessons of agile software development was to include the team earlier in planning activities. Teams developed systems for collaborative planning, allowing them to adapt faster to feedback. Scrum introduced the Sprint Planning, a recurring all-hands meeting to create a short-term plan. While that sounds quaint today, it was revolutionary back then.
We've learned over the years that having a Sprint Planning meeting isn't a guarantee for collaborative planning. In most organizations, the manager still owns the plan and presents what the team will work on.
Collaborative planning seems to be a big hurdle in many organizations. Planning is often still the manager's private domain. A common misunderstanding is that this is somehow a power play by managers. That's far from the truth. There is no power in being responsible for a plan the developers can't deliver. I’ve been there.
Collaborative planning is a tricky balance because of our addiction to Scrum's old-school meeting culture. Involving developers in standups, planning meetings, retros, demos, and backlog grooming sessions takes up time that could be spent coding. Developers complain about having too many meetings and not getting things done. Managers look for ways to optimize their budgets and minimize developers' time spent in meetings.
"Let's increase productivity" and "I just wanna code" find themselves on the same team. It's a tricky trade-off that often sabotages real collaborative planning.
So that raises an interesting question. How many planning meetings should developers attend? Keep them out of the loop, and we'll end up with an unrealistic plan. Involve them too much, and they can't get anything done.
For once, there is a clear answer to this trade-off.
Developers should always be included in short-term planning. At the start of every timebox, the entire team should get together to design and update the short-term plan. That's your typical sprint planning or focus block kick-off.
But developers don't always have to be involved in long-term planning. The entire team doesn't need to be present for every roadmap session. In some companies, inviting only Product to these meetings is OK. In other cases, a team lead or senior developer can act as a proxy for the entire team. Since long-term plans are much more volatile, including all developers doesn't make much sense. That's usually a waste of their time.
But there's a crucial component that's missing in most organizations. Changes to the long-term plan should always be presented to the developers. This can be a blog post, an e-mail update, or, if you really have to, a monthly all-hands meeting. While it's unnecessary to involve all developers in the decision-making of the long-term planning, they should be continuously informed.
Most teams already have some kind of short-term planning meeting. But if your teams have adopted a Kanban-style approach, such a systematic planning session might be missing.
Most organizations already don't invite their developers to roadmapping sessions. But you might want to cut backlog grooming sessions if your teams spend too much time on those.
It is, however, very uncommon to see a formal system informing the developers of changes to the long-term plan. More often than not, they are kept out of the loop until they need to start building. Yet that's the missing tool that ensures developers are involved enough without dragging them into every meeting.
Developers should actively collaborate on the short-term plan and be continuously informed of the long-term plan.
That’s the key to effective collaborative planning.
If one of those components is missing, you’ve got work to do.
It feels like “developers” should be replaced with “programmers” in some parts of the text, if they are really only interested in delivering code and not developing solutions to customer problems.