Every software development methodology is, at its core, a shame delivery system. Scrum uses standups to surface what you didn't finish yesterday. Kanban uses the board to make your stuck tickets visible to everyone who walks by. Code review exists specifically so other engineers can leave comments on your life choices in writing, permanently, attached to your name.
Shame-Driven Development doesn't hide this. It optimizes for it.
"You don't need a sprint velocity metric. You need to feel bad enough about last sprint that you work harder this sprint. SDD makes that feeling the product."
The SDD Standup Format
Traditional standup: "What did you do yesterday, what are you doing today, any blockers?"
SDD standup: "What did you promise to do and didn't, what are you promising now and may not do, and what is the one thing you are most ashamed of in the current codebase?"
The third question is the load-bearing one. Engineers who cannot answer it are either very good or very comfortable, and in our experience those are different problems requiring different interventions.
- What went well? (5 minutes, then move on, dwelling on success breeds complacency)
- What could have gone better? (45 minutes)
- Who specifically could have gone better? (name them. yes in the retro. yes out loud.)
- Action items: assign shame owners per item
- Close with a group reading of last quarter's estimates vs actuals
Metrics
SDD teams track Shame Velocity: the rate at which engineers convert accumulated shame into shipped features. We have been running SDD for two quarters. Feature output is up 22%. Engineer happiness surveys are down 67%. We have stopped running happiness surveys. Shipping is up 22%.
Ticket: SHAME-847 Title: Brad's TODO comment from 2013 is still in production Priority: Shame-Critical Assignee: Brad K. Status: In Shame Comment: Brad, it says "// TODO: fix before launch." It is 14 months after launch. Comment: The TODO is now older than one of our engineers. Comment: We are all thinking about it.