The Four Pillars of Agile Adoption

is widely viewed as a "nicety" that can be skipped or, even worse, as a step toward anarchy.

Erosion of "Soft" Skills as First Danger Signal
The first danger sign was the disappearance of retrospectives. Group learning and team unity of purpose must be renewed periodically. This is a very high-leverage activity that solves a great many thorny problems while they are still tiny. The line manager(s) of those on the team should have noted that Joanne was carrying the load for retrospective facilitation, and should have recognized the importance of that skill by helping others get trained to do it well also.

Facilitation is only part of the picture; good data is needed too. Teams should experiment in every iteration with ways to improve their work, recording data on each experiment. Data plus an efficient way to make team based decisions should have prevented the team's arguments from getting out of control. Comet team's first argument was over how much effort to spend cleaning up the quick fixes in the code when customers were clamouring for new features. A wise technical manager knows that new features built on top of quick fixes just creates a bigger cleanup job to be done later. If this wasn't being grasped by the product owner, then it was a point where a technical manager could've reinforced the team's message.

Too often good facilitation is dismissed as a "soft skill" not as important as the technical skills, and something we can do without in a pinch.

Missing Cooperation Between Departments
Failure to act on issues raised in retrospectives is another problem. The team had repeatedly raised issues requiring the cooperation of another department, but it was not forthcoming. By letting this issue sit, managers sent a message to the team that it wasn't important. This contributed to the team's feeling that retrospectives were pointless. A deeper root of this problem is insufficient larger commitment to agile, spanning departments. This is a system problem that the core team cannot solve. Managers need to take the lead here.

In an agile adoption programme, friction between the agile teams and the surrounding organization will occur. The organization evolved to support waterfall teams with handoffs between siloed job functions. It will have to change if the agile teams are to survive. Management's chief job in an agile adoption programme is to watch for the friction points and then adapt the organization to the agile teams.

Misalignment of Accountability and Control - ‘Blame' culture
The organization was trying to hold the project manager responsible for the team's actions. The team has to be responsible for its actions. There was nothing the project manager could've done to make the team avoid those bugs. When things go wrong there is often an impulse to place blame. The need to deflect blame is what lies behind much of the overly-detailed planning in waterfall projects. Deming placed "Drive Out Fear" as one of the principles in his fourteen Points for Management. The project manager needed support from those sponsoring the agile adoption programme. By allowing others to place blame on him they let fear grow.

In the case of the bugs that occurred, they were unforeseeable since they were latent in the existing code. Probably the only way to have prevented them was if the company had invested in more thorough testing designed to catch a scenario of that type. But it is very common (and possibly justified) for companies to decide not to invest in doing that. In that case, the team were operating within a system that had set this trap