Can teams be accountable for delivery of features?

Including delivery/deployment in the definition of done I’m told is unfair because teams aren’t in control of what gets delivered or when.

• “Their work might be completed, but be only a fraction of some larger scatter-gathered effort, so it’s not their fault.”
• “They may be dependent on work from another group, say FE or BE or database, or something, so it’s not their fault the work isn’t done.”
• “They may have worked on a dozen things, but only one was delivered. It’s unfair that it doesn’t represent all of their efforts.”
• “Releases aren’t done every sprint/increment/week/whatever, so it will look like uneven velocity if we only count work actually delivered.”
• “They should be able to count the points for everything they worked on, whether it’s delivered or not.”
• “A manager may decide not to release their feature and leave it in the branch – maybe never release it. It’s not their fault so they should be able to count the work they did that was canceled.”
• “There could be technical issues that make the feature un-deliverable. How will they count their points if the feature can’t be completed?”
• “The testing departments could return their code for rework, and that would keep them from counting all the work that they did on the feature.”
• “It’s up to the customer to accept the work, and if they don’t then none of the efforts will count.”

All of these say “it seems unfair to count accomplishments when the system works against accomplishing things, so we want to honor and respect the busyness of the team members instead.”

 
This is what I mean by “busyness accounting” – focusing on how busy people are, not on whether we’re reaching our goals. It seems more “fair” if we are evaluating people on how much they do instead of what value is delivered.

 
Busyness accounting arises naturally and organically when we’re tracking people in the system instead of tracking the flow of work through the system, and when we’re focused on people “scoring points” of velocity instead of delivering value.

Go back and notice the helplessness in each of the complaints/reasons to not count delivery.

“Our system is dysfunctional and resists our best efforts, so we count how hard we try instead.”

A better system might change everything.

 
If only delivery/achievement counted, how would you rework the way you are doing software today?

What processes would you change, eliminate, or trade out?

What would you do instead?

 
What if it’s not impossible?

Could you work in a world where the rules are different?

this post is recreated from a Twitter thread from December 2021