However, how do these manifest themselves within a technology team and what kind of impact does this have on projects and team culture? The overarching problem is that this kind of behavior tends to undermine focused and accountable team structures.
Firstly the general level of paranoia and mistrust in the team is increased. If the work of previous members of the team isn't respected, then very quickly the work of current team members isn't respected either. Team members know that when they leave their work is likely to be attacked and possibly viewed in a negative light, this damages motivation and personal work ethic.
As team members become less interested in the standards of their own work the work of previous members of the team becomes more and more of a crutch for current issues or defects. This then feeds back into the cycle and the willingness to accept this becomes greater and greater. Mistakes should be an accepted part of the culture and well understood, only then can mentoring and process be put in place to ensure they don't happen again.
As with Rich in the above example, the results in his behavior were very clear from his continued attitudes toward previous members of the team. This very quickly led to divisions within the team; personal relationships were quickly affected as the previous members of the team still had friends in the current team. Rich began to blame delays in his deliverables on having to deal with poor code previously written in the project. His requests to re-factor code continued to increase and the justifications for doing so become less and less well defined.
As the negative culture spread to several of his peers, Rich began to feel more justified in his attitudes. While his longer term goals suffered the spreading change in culture validated his desire to effect change. This led to unapproved re-factoring of code in several areas of the project to impress his peers and leave his mark on the project. The results of which were nearly disastrous to the project itself. The time he took in refactoring caused his other deliverables to slip badly.
In addition the areas of code he re-factored were areas for which he didn't understand the requirements well. This led to features and business logic being accidentally dropped from the product and new bugs introduced in areas we weren't planning on changing. This was even harder to detect as those areas hadn't been on the plan for deep testing, which led to overall project slip and impact to the QA portion. This seemingly simple change in Rich's behavior led to a material impact to the project and the business which the rest of the engineering team had to pick up and cover for. This only fed into a cycle that increased the lack of trust amongst the engineers.
Clearing the Air
The core of agile development is about being nimble and building teams which can produce effective results quickly. This requires solid teams built on mutual respect with the kind of work ethic that is created when members of teams trust each other and that must include respect for previous members of the team. Without this, teams can quickly become bogged down in finding fault in previous code with less personal accountability leading to the wide range of potential problems we've discussed above.
Does this mean that innovation and a desire to constantly improve the code base must suffer? That is absolutely not the case at all. It is a primary responsibility of the leadership of any engineering team to promote