|So a few days ago I added a "Person to Blame" field to our bug tracking system and this decision has attracted a lot of attention from outside of our organization. I totally welcome the debate and love the passion from everyone. Given the interest, I thought I'd share how the "Person to Blame" field works for our team.|
We are a tight-knit dev team, part of an almost-3-year-old startup. As a team, we spend a lot of time together and just like other startups, we probably spend more time with each other than with our families. We only hire people who we respect and take pride in the team that we have built. We are a shop that believes in peer code reviews, unit testing and open debate. We also hold each other accountable when we do silly things. For instance, if you break a continuous integration build you drop a $1 in the jar for our beer fund. Oh, you also get a nice dose of tongue-in-cheek lashing from the team if you write a time bomb into our unit test suite. All in all, we have fun together, we push each other to be great and we respect each other enough to be direct and honest.
About 6 months ago, we made a conscious effort to reshape our software development process in preparation for Continuous Deployment. We promote an environment where developers are in charge of a story from start to finish. This includes understanding the problem, thinking about how a story needs to be tested, implementing the solution, writing the necessary unit tests and functional tests, and ways to measure the effect of the story once in production. As soon as a developer okays the story, it's included in the next release. In short, we want to be a continuous deployment shop and we think that we have the right developers to do it. (to be clear, we are still a few months away from the true continuous deployment process like the one installed at Etsy)
More than just tools and process, continuous deployment requires a different kind of mentality. While the throw-my-stuff-over-the-fence mentality never existed on our team, we do need to introduce a higher level of responsibility and accountability from everyone on the team. Since the shift about 6 months ago, we have seen an increase in the number of hot-fixes going out between deployments. And that's okay, bugs happen. We anticipated the increase in production bugs when we moved away from having a dedicated QA team. But, as we get closer to having a true continuous deployment system in place, we need to start treating production bugs as the exception rather than the rule. Bugs are inevitable and are accounted for in the world of continuous deployment, but bugs should still be avoided if possible. So a few weeks back, I started talking about keeping metrics on production bugs: count per sprint, per developer, per team, etc. I mean, you have to start tracking these things so that you can improve, right? And to keep the accounting simple, I added a "Person to Blame" field to Jira a few days ago. Could I have named the field something more politically correct, so that feelings don't get hurt? Sure. But what's the fun in that? The point was to bring awareness to the number of production bugs after each release so why not throw in a small dose of public shaming for good measure? And to be clear, the purpose of the field, and ultimately the purpose of the metric, is not to pinpoint the cause of the bug. Shit happens and we have better things to do. The ultimate purpose of the metric is a reminder for each developer to be better everyday.
Like I said in the beginning, I welcome the debate on the matter and appreciate the passion from everyone.
The "Person to Blame" Boss :)