The title alone should generate imagery ranging from destructive rumors to the macabre. Who are these dead, and who is speaking ill of them? "The dead" are former team members, the ill speakers are those who blame problems on them, and we are taking a critical look at this complaining with just a touch of irony. We are talking about the culture of blaming current problems and challenges on team members who are no long with the team for whatever reason. Almost anyone who has been involved in the software development life cycle has experienced this behavior, and very possibly taken part in it even with the best intentions in mind.
However, what I want to discuss here are the reasons and ramifications of the blame game. I have myself seen teams hampered by this kind of behavior, even in small quantities. By the close of the this discussion I would like to share some tactics I've seen that are effective in preventing and solving this problem behavior that work well for both leaders and individual members of any technical team.
First of all, what does this behavior look like and how can you identify it? How can we differentiate this kind of behavior from honest and constructive feedback and ideas that should be encouraged and embraced within any agile team? You may be surprised to find that identification is easier than you might have imagined!
It often starts with frequent complaints to peers and to managers about all of those difficult to follow and fuzzy little bits of code all over a project or system. These complaints quickly become common place jokes or derisive comments about the work of former team members. These complaints and jokes quickly begin to move into team settings such as scrums, team meetings, or working social situations. This progression is where the danger starts; this is where the mindset begins to seep into the culture of the team.
Many years ago I worked with a young developer; we will call him Rich here for our purposes. Rich had several years of experience under his belt, and was a very smart engineer. He had passion and an eagerness to improve things and leave a positive mark on the project. These were all positive traits that I encouraged.
However, I noticed him slipping into the behavior of blaming previous members of the team for issues we currently had with the project. It was clear that while he was very smart, his lack of long term project experience led him to make black and white judgments. I often explained to him that these fuzzy bits of code were often bug fixes or last minute changes to business logic. While they weren't optimal, making those changes had been a business decision at the time.
Often time people don't stop to think that a software project is done because it meets the needs of a business. This means these projects may have different drivers behind them from highly scalable enterprise systems to rapidly developed first to market products. These kinds of drivers will, by their nature, produce differing results depending on the requirements and the amount of resources available. At times folks such as Rich simply didn't realize that the drivers behind the project three years ago may have been different for the company than what was currently driving the project. This eventually led Rich to constantly want to re-factor portions of the code without being able to articulate the benefit.
While positive changes to the code base should be encouraged, when the benefit cannot be articulated this can also be an indicator that the perception of previous work has become negative in a general sense. In general it is always helpful to keep in mind that engineering projects can be very complex with a tremendous number of moving parts and integration points. We should always consider how difficult it is to put ourselves in the shoes of those making decisions or working in years past under differing sets of business priorities and resources.
The Ill Effects
My own experiences have led me to the obvious opinion in this article that the effects of this behavior are not only negative but far more destructive than you might guess.