Following the bread metaphor, if the feature was in the fridge for too long it needs to be toasted first to taste good, i.e. refined, to make sure it's still valid. Or we could specify a goal instead, from the very beginning. Sigh.
I think it was Mary Poppendieck where I first heard that you shouldn't have a backlog and if you do, it should be kept short and purge every so often because the important features/tasks/bugs will always resurface.
What I'm saying is when your loaf turns stale, throw it out and buy a new yummy replacement!
I'd be interested in hearing your list of "incentives that relentlessly push ... in the opposite direction." Or just the top handful if the list is longer than you care to get into.
I believe that Kent meant the evaluation process. Specifically, a retrospective evaluation of results every 6 months.
Slack is bad because your goals may not look ambitious enough. And even if you accomplish them, they may be viewed as too easy, so rewards won’t be high.
Features are “good” because you can get credit for implementing them, even if they don’t serve or accomplish the goal. This is known as a “ship goal”: everything was implemented as requested on the roadmap and shipped on time! If it didn’t work as expected, that’s not engineer’s fault…
And dynamic prioritization is bad because of comparison. Imagine comparing two cases: one engineer implemented and shipped 3 features on time, and another engineer changed direction 3 times and shipped only one thing. The first one clearly did his job. The second one is a much more iffy case: unless there is a major win from the one feature this engineer may get a bad evaluation… because we value things that have landed in that 6mo period.
Following the bread metaphor, if the feature was in the fridge for too long it needs to be toasted first to taste good, i.e. refined, to make sure it's still valid. Or we could specify a goal instead, from the very beginning. Sigh.
All great points.
I think it was Mary Poppendieck where I first heard that you shouldn't have a backlog and if you do, it should be kept short and purge every so often because the important features/tasks/bugs will always resurface.
What I'm saying is when your loaf turns stale, throw it out and buy a new yummy replacement!
That is why I started making frittatas for breakfast. To use up the extra bread. I know, not at all helpful in the analogy to planning!
I'd be interested in hearing your list of "incentives that relentlessly push ... in the opposite direction." Or just the top handful if the list is longer than you care to get into.
I believe that Kent meant the evaluation process. Specifically, a retrospective evaluation of results every 6 months.
Slack is bad because your goals may not look ambitious enough. And even if you accomplish them, they may be viewed as too easy, so rewards won’t be high.
Features are “good” because you can get credit for implementing them, even if they don’t serve or accomplish the goal. This is known as a “ship goal”: everything was implemented as requested on the roadmap and shipped on time! If it didn’t work as expected, that’s not engineer’s fault…
And dynamic prioritization is bad because of comparison. Imagine comparing two cases: one engineer implemented and shipped 3 features on time, and another engineer changed direction 3 times and shipped only one thing. The first one clearly did his job. The second one is a much more iffy case: unless there is a major win from the one feature this engineer may get a bad evaluation… because we value things that have landed in that 6mo period.
I'd recommend to abandon roadmaps altogether and replace them with sea charts. I wrote about it here:
https://alexbunardzic.substack.com/p/replace-road-maps-with-sea-charts-8f0e267468b9
Nice, and now I imagine how much bread you are likely to waste 🤷