How Planning Meetings Can Endanger Your Software Developer Career - Part Two
This one gets wonky.
Let’s unpack what the definition of planning meeting means for your career.
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.
You’re responsible
See part one of this series for a higher level take on agile and responsibility.
The Product Owner proposes how the product could increase its value and utility in the current Sprint.
You will be judged by whether your engineering team produces value. A product owner might be measured by the results of many teams, but his role is to make proposals to engineering.
This is problem #1 for planning meetings - they obfuscate who is responsible for what. The artifacts, if any, produced by a planning meeting don’t state anyone’s opinions or reasons for approving the assigned stories.
You might think there is a division of labor where product owners and managers are responsible for what you do, and you only need worry about implementation. The reality is that you will be held responsible no matter whose idea it was and team responsibility is a primary reason for moving to agile.
Even though you’re responsible, your ideas won’t be heard
The Sprint Goal must be finalized prior to the end of Sprint Planning.
Another failing of meetings is that they need a simple agenda. This is problem #2 for planning meetings - planning all stories for the next X weeks in a day is unreasonable, so the first proposal probably carries even if it’s inferior.
There is rarely any shortage of technical debt that we know needs doing. Plus implementing an unsuccessful feature can negatively impact a product’s usage complexity and maintenance.
Yet instead of rational offline debate the team re-enacts a scene out of ‘12 Angry Men’ except worse because
Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint.
Even with choosing the wrong proposal affecting your career are you going to be the lone dissenting voice that keeps everyone trapped in a room with time running out?
Groomed backlogs won’t save you
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
Since you’re responsible and there’s not enough time to introduce your ideas, your only hope for avoiding career damage is to influence the product backlog ahead of time.
This is problem #3 for the planning meeting - grooming backlogs well ahead of time creates detailed plans that are the opposite of agile. (Sometimes referred to as waterfall.)
So you need to put your perfect story onto the backlog immediately before the planning meeting and then have meetings right before the meeting to get it on the agenda!
Even then your perfect story might not be so perfect once the Sprint starts, and it’s a long way till the next planning meeting.
Planning meetings hurt your reputation
Because a planning meeting only occurs once every X weeks a lot of extra care must be taken.
You need more detailed estimates to make sure you don’t run out of stories before the next meeting. You need control of story size to make sure they can be finished before the next meeting and everyone has enough stories.
These meeting driven practices can damage the trust relationship your career needs.
Pre-estimating
If you’re a plumber asked for an estimate you won’t give one until you go under the house. How can you? Without knowing anything about the pipes you were asked to fix, any estimate you give will be meaningless.
If a story has high enough value then it should be worth it to have a developer investigate until he’s comfortable giving a real estimate. Otherwise, you’re giving out estimates that are mostly wrong and that’s going to hurt your reputation.
There are “spike” stories that let you do investigation, but it’s better to just start a story with a budget in mind. Pure investigation, like grooming and waterfall, will slow you down on overhead that makes it difficult to explain why things are taking so long.
Story splitting
In terms of your career you want to be assigned to as large a story as possible, and it so happens that’s what’s best for your product and customers as well. For instance if a story has a back end and front end component the best case is it’s assigned to a full stack developer or developers who can do both.
If the resulting assignments are not independently valuable then try to avoid splitting the stories. The communication overhead of doing so is prohibitive and there is no way to avoid blame for the delays caused by that overhead.
What to do about it
Historically planning meetings did have value. Compared to a single manager handing out assignments without a meeting, a planning meeting where developers could help control what they work on is a huge step up.
The problem is that for an agile organization planning meetings can never be more than a stepping stone towards developers, story by story, truly taking more responsibility for the work they do. Unfortunately the only model many organizations have for story by story responsibility is to have senior developers work by themselves.
Team of one certainly solves many of the planning meeting problems we’ve described but, in the ever more complex world of software, it limits the kinds of projects you can safely tackle. It also limits your perceived value as you are no longer helping guide others.
So if you want a lasting career with a better organization, you have to move beyond planning meetings without going solo. Uclusion offers project management software to help do that and encourages all developers to find solutions.
