to run on autopilot; besides there were many other demands on his time. He was feeling caught-out when Legal had to come to the rescue. At first he defended the team, understanding their explanation about the test framework. But he became dismayed by their incessant arguing and no longer wanted to be in the product owner role.
Both the product owner and the project manager were starting to wish for the good old days when you just had the analysts write a specification and hand it over to a virtual team - one where the project manager rotated people in and out of a dispersed team and assigned all work tasks. It was getting easy to forget the headaches associated with that, when these new problems seemed so intractable.
Team velocity was steadily decreasing. So managers pressured the team to speed up. With each iteration, the team responded by promising more and delivering less. Often nearly half the stories committed to were not completed in the sprint. In an effort to work faster, they no longer helped each other out, working solo on the tasks they claimed for themselves. Everyone missed the teamwork they used to have but didn't know how to get it back again.
Tony was using the conference to renew his contacts elsewhere. He had decided to leave the company.
It is clear that in this agile conversion this team learned how to operate using agile practices - to an extent - but managers did not learn how to monitor this new Agile system and use the leverage points that could have kept the situation from spiraling downward. Pleased by the agile turnaround, they expected it to just remain on course of its own accord.
Agile systems don't automatically stay on track. No system does; they all need some degree of monitoring and adjustment to counter entropy. In an organization, the "Agile system" consists of the core team, plus the stakeholders  who've chartered that team, and others who manage or interact with the core team. As part of an agile adoption programme, managers need to learn the critical role they must play in fighting entropy by exercising control in a new way.
Let's look at a simple analogy. If enforcement of traffic laws were suspended, it wouldn't be long before there would be chaos on the roads. People who want to follow the laws would have to respond to those who don't and the whole thing would spiral downward. Likewise in an organization it is for managers to understand the laws - the key leverage points - and use them correctly to keep the agile system running with minimal ad hoc intervention.
Let's take it one step further. Suppose there has been a breakdown–as we've seen with the Comet team—what are managers to do? An accident, flooding, or downed trees can create a big traffic jam on a road. Regardless of the cause, the individual motorists are powerless to move their vehicles once they are caught in the gridlock. No amount of pressuring or punishing them makes any sense. The first thing the police do is not to pull cars out of the jam, but to halt the inflow of more cars. They block off the routes into the gridlock, thus preventing it from growing. Next, they free cars out the other side by clearing the blockage.
The jam is a system problem, not a problem of the individual motorists. Although each driver has responsibility for controlling their vehicle properly, that won't prevent or solve traffic jams. Likewise many of the problems that software teams experience