I’m currently reading Ken Schwaber’s latest book The Enterprise and Scrum. While reading it, I came across this passage
It was so compelling that the Vice President of Sales talked to the CEO, who told Stan to make it happen. Stan then told the developers, “Make it happen, no matter what.” In the software industry, this means to build the additional functionality into the product and keep the same date. Just do it.
Three weeks before the scheduled release date, I [Ken Schwaber] visited Litware to check up on its progress. When I got off the elevator at the development floor, I knew something was wrong. There was no noise. A characteristic of an enterprise using Scrum is community, people working together on ideas, collaborating over different approaches, sharing in work. No noise was not good noise.
In the work areas, the team members all had their heads down at their workstations, looking grim. There was no joy, no excitement, no sharing. I gathered a group of the developers and asked what was going on. They replied that the overtime was killing them. I asked how this could be since Scrum called for sustainable pace. They told me that the additional $14 million dollars from Woodgrove Bank would make the financial year. Without the new functionality for Woodgrove Bank, the target release date was December 1. With the new functionality, the release date should have been changed to January 15, but it had been ordered to be done by the target date. Stan had told them to do whatever it takes.
I became irritated. I asked the developers how this was different from release 3.51, when they were exhausted, the product was shabby, and the dates and functionality were missed. Had they forgotten? The developers said that they hadn’t forgotten, but Stan had told them to do it, so they had no choice.
I knew Stan well by this time and was surprised. When I went to see him, he was stunned. He hit his forehead with his hand and said, “I absolutely forgot! When the CEO and VP of Sales came to me, I knew that we needed to do it for the business, so I reverted to old form. My old habits took over, and I did what I used to do. Now we are building this release with poor quality and exhausted developers just like before.”
In this comment, Sami says “They all say they understand the benefits. But once i quit controlling, they are off the road.”
This also ties into David’s observation that “My fear with many of the enterprise scale transitions now taking place is that they will suffer the same fate. When the management that led the change is gone, the teams will gradually atrophy back to a traditional way of working. Unless a fundamental change in the organizational culture is achieved and the new culture is institutionalized from top to bottom in the organization, then I fear that the benefits of agility – even they are recognized as hyper-productivity in some teams – will be short-lived.”
My experience is that this is not limited to enterprises alone. Even smaller companies with a fixed mindset of “this is the way we do things” have a hard time sustaining agile practices.
The big question for agile adoption is not how productive any particular practice like TDD or continuous integration is, but how to sustain the productivity. My take on this is that a team or organisation with an agile mindset will automatically pick the practices that help them. On the other hand, when the practices are done without an understanding of the agile mindset, the practices will be short lived, even if the team is productive. Agile is not a set of techniques.