The Four Pillars of Agile Adoption

Adoption to One Year On
When the consultants completed their work, the eight members of Comet team were running three-week iterations. Their velocity had initially jumped around but was stable and gradually increasing. They were holding retrospectives at the end of every iteration and checking a few days into the next iteration to make sure they were really following the new resolutions they made in the retrospective.

Their product owner was 50% allocated to that role and was meeting with stakeholders a week prior to the end of each iteration to finalise stories for the backlog. The team's ongoing mission was to maintain and enhance risk analysis software for use by the underwriters. The work they turned out was the best quality the company had seen. The team knew that there were still bugs in the legacy code but at least they were not adding many new ones. As they improved their tests they were cleaning out more and more old bugs.

A year later the consultant Scrum Master saw Tony, the Comet team's lead developer, at an industry conference and asked him how things were going. Tony said he wished they had never gotten into agile at all! They were no longer doing real iterations, just moving the work along in a more or less continuous stream. They had dropped doing the retrospectives after Joanne, who facilitated them so well, moved on to other work. They continued them awhile but they were just making a quick list of what worked, didn't work, and what they'd change, without delving into the tougher issues. The biggest problem with the retrospectives was that things they most needed to change required cooperation from another department that was always overworked. So there seemed no point in making the same useless resolutions over and over. The other department was not responding and wasn't going to. They were invited to send someone to the retrospective but they never did.

Dissension Within Team
The biggest letdown in Tony's mind was that agile had opened the door to turning software development into a sweatshop. That's the word he used—"sweatshop". Before the conversion the developers had their own cubicles, and in the enthusiasm of early agile they'd given them up in favour of a team room. But they were happy for eight months with the team room–why the problem now? They were arguing a lot now, and being together all the time in a team room only increased the tension.

Stressors
They were arguing a lot because of disagreements over how much time to devote to cleaning up quick fixes they'd had to put into the code versus getting new functionality in place that their customers needed. At least that's when the arguing began. Now there were many running arguments on all sorts of things. The quick fixes got rushed into place when new features activated a couple latent bugs in the code that their agile test framework didn't yet cover. Those bugs got a set of insurance policies written with incorrect risk assessments, forcing the legal department to sort out a remedy. That brought criticism on the project manager who'd been fine with team autonomy so far. But now he was being criticized by his manager for not having been firm enough with the team.

Repercussions on Team, Product Owner, and Managers
The product owner had cut way back on the time he devoted to his role because the team was delivering so predictably month after month, before the problem with the bugs and the Legal department. He felt that at some point agile should just be able