Blame Driven Development – finally a methodology that works

The development can be driven by a lot of things: TDD (Test Driven Development), MDD (Model Driven Development), FDD (Feature Driven Development), BDD (Behavior Driven Development) and much more. Do we really need a new kind of development? Yes! All other forms are describing the workflow during the development. With Blame Driven Development just the result is important! How a single team member reaches the result is not defined and can individually be chosen. Blame Driven Development encourages the competition between coders. The goal of BDD is to frighten programmers not to be the worst one with the most mistakes and bugs.

How does Blame DD work?

Here are the rules:

• Every developer has a personal account of finished story points.
• There is just one developer responsible for a user story. The finished story points per sprint gets added to his account.
• If somebody finds bugs in a finished user story some points got subtracted from the authors account.
• Instead of planning the sprint with an average velocity of the last sprints the team plans double as much points for the next sprint. That encourages people to work harder and most likely someone can be blamed at the end of the sprint for not reaching the goal.
• The developer with the least amount of points at the end of the sprint has to explain at the next board meeting why the development is so slow.

 Here is how you implement Blame DD

• The customer or product owner is just allowed to write the story with just 140 characters. If the story hasn’t been implemented to the customers satisfaction story point got subtracted from the programmers individual account. This encourages the coder to be creative and he need to think more like the customer. Developers that are practicing Blame DD are understanding the customer much better. In addition to that, the coder fears to do something wrong and that pushes him to a better performance.
• The Scrum Master reads out loud the reached points for every programmer during the daily stand. That motivates the individuals to become the best developer in the team. Pro Tip: Doing the Stand Up in military style let the team members understand that it’s not a game and the development is a critical part of the business.

Reduction of Points

• Testers are called inspectors. They maintain a checklist and are subtracting a point for every found bug.
• You can also use one person as a code inspector. He is allowed to subtract points for bad variable naming, not folling coding conventions etc.
• A good ratio of inspectors to developers is 1:1
• It is also possible to have negative points (this is actually the norm in Blame DD)
• Every subtraction of points should be discussed in the daily stand up. It should be possible to blame somebody else for the mistake.

Additionally

• If a bug is found in the production system, everybody has to stop working and find the guy who is responsible for the bug. He will be blamed on the web page publicly. It is not so important in Blame DD when the bug actually will be fixed.

Pro tips for Blame Driven Development

• If you reached a certain amount of story point for a sprint you should concentrate to find bugs in team members code.
• Use a tool that checks in the code under a different name. Just implement an infinitive loop and merge it into the main branch with the name of a team member. It’s so much fun to see people trying to defend themselves in the daily stand up.
• Don’t do pair programming. It has been shown, that the pair programming partner will smuggle in buggy code when you just visit the toilet for 5 minutes.

Fear is such a good motivator for pushing people to better performance. Let’s blame the ones, that are not performing! I love to hear your experience or ideas about Blame Driven Development. Use the comment function to give me feedback and share your thoughts with the big Blame DD community.