How Planning Meetings Can Endanger Your Software Developer Career - Part One
I wish the title were clickbait.
In a fully non-agile environment the developer is responsible for transcribing specifications written in human language to machine language. If that human language has ambiguities then the developer goes back and asks questions but there is no need for a planning meeting with everyone on the team understanding each other’s stories.
All popular definitions of agile support the view that self-organizing is what differentiates this approach.
The original 1986 paper on agile development explains pre-agile development
The project went sequentially from phase to phase: concept development, feasibility testing, product design, development process, pilot production, and final production.
and the new way
we learned that leading companies show six characteristics in managing their new product development processes
where three of the six, built-in instability, self-organizing project teams and subtle control, all talk about a hands-off approach to product development. A team operates under only a broad vision similar to the way venture capital funds startups today.
Scrum, which started in 1993, advocates the same for teams in its guide
They are also self-managing, meaning they internally decide who does what, when, and how.
Same for the agile manifesto signed in 2001
The best architectures, requirements, and designs emerge from self-organizing teams.
And here’s McKinsey’s 2018 paper on agile transformation on what an agile organization is:
They are open, inclusive, and nonhierarchical, evolving continually without the frequent disruptive restructurings required in more mechanistic organizations; and they embrace uncertainty and ambiguity with greater confidence. Such organizations, we believe, are far better equipped for the future.
In short, if you stick to transcribing, your projects will likely fail, and you won’t have the skills necessary for the future.
Why Planning Meetings Are Dangerous
Part two of this series goes into more detail on how the mechanics of a planning meeting can set you up for failure.
Here in part one we argue that a meeting is simply the wrong vehicle for a development team to self-organize and take responsibility.
Whether it’s open source and pull requests or the IETF and RFCs, engineers prefer an asynchronous propose and approve model of self-governance.
So for an agile project developers would prefer to asynchronously propose and approve individual stories.
Planning meetings destroy that preferred form of self-governance in two ways:
- They are synchronous
- They approve batches of stories instead of individual stories
The reason for the departure from self-governance is that many planning meetings have devolved into mini-project deliverable sign ups.
Mini-projects are not agile
Each Sprint may be considered a short project.
It’s easy to understand how agile came to be associated with mini-projects. If the goal is quicker feedback then it seems at first like a mini-project allows that. (Unless you need to ride the horse.)
As I go a long way to establish above the main finding of agile is that getting a team to take responsibility and self-organize to solve a problem is the fastest, best way. Instead, mini-projects just command and control transcribers to produce mini crap.
Potentially even old style phased development with its clearly defined roles will outperform mini-projects where no one takes responsibility.
The only safe part of a planning meeting
If your team wants to meet together with a product owner occasionally to ask questions that’s okay. Though it would be better if that discussion were offline, or the meeting at least recorded.
All the rest of a planning meeting risks reducing a team’s ability to think for themselves and adapt and change.
At some point your organization attempted to adopt a system to give developers more responsibility. So we suggest discussing with your team what would best work (and seeing what Uclusion offers).
