For the first fourteen years of its existence, Scrum was implemented primarily from the bottom up. That is, a development team would start using Scrum. Its customer would see working software at the end of one month. The customer would be so overjoyed that she would tell a fellow manager. The fellow manager would ask his development team why they weren't using Scrum. That team, in turn, would shift to Scrum. Team by team, customer by customer, the organization would transform itself to use Scrum and become agile. That's all starting to change.
The greatest advantage of bottom-up implementation is that it minimizes the probability of command-and-control interference with the use of Scrum. In a bottom-up implementation, the people who are using Scrum on their project are the same people who selected it, so they are enthused and eager to use it. They also feel comfortable making adjustments so that Scrum works for them. The other advantage is that the value is immediately proven to the customer, who then acts as an internal salesman to help the implementation spread, one customer and one team at a time.
Over the last eighteen months, I have begun to see top-down implementations of Scrum. That is, a "c-level" executive realizes the competitive advantage using Scrum can bring and directs its use throughout the organization. This top-level support is invaluable in securing the authority required to make this type of change happen and stick. Although I am under non-disclosure agreements with most of these organizations, I can say that some of the companies using top-down implementations include CapitalOne, KeyBank, Yahoo, Covad, Siemens Medical, and Siemens Telecommunications. It is clear that Scrum's success has become more visible to the upper echelons of organizations. That's the good news.
The catch is that Scrum, like all agile methodologies, depends on self-managing teams—the exact opposite of most top-down directives. While management may understand that Scrum succeeds largely because the people doing the work define how to do the work, resisting the urge to intervene can be very hard, particularly when someone has stuck her neck out to make the top-down implementation happen. Managers who have initiated the Scrum implementation often feel responsible for its success and revert to command-and-control tactics.
Command and control has two negative effects on a Scrum team. First, developers get in the habit of waiting to do anything until they are told what to do. As a result, they often are afraid to take the initiative and are used to blaming management for stopping them from doing so. Second, management often feels as if it is not doing its job if it doesn't come up with answers and instead waits for developers to figure out solutions on their own, including letting them make mistakes.
I was recently at a company where the developers complained that the VP of engineering said that they could not write one common persistence layer, but instead had to replicate all of the work in two separate vertical products. When I checked with the VP, he was stunned. He indicated that he was all for refactoring; nobody had even asked him about the persistence layer. I then conducted a meeting with all of the developers, the VP, and his management. We discovered that even though management felt they had given them free reign, the developers, in the absence of specific direction from management, were still afraid to do the right thing.
Change is never easy. The greatest paradox of the recent trend toward top-down Scrum implementation is that the senior managers have the authority to make organizational changes, yet commanding that these changes happen organizationally runs counter to self-organization. The change required by Scrum must happen person-by-person, team-by-team—whether the impetus begins at the top or the bottom. Eventually it will spread throughout the organization.
