Scrum Principle : Empowered Teams. Management tells teams what work is important, teams figure out how to do the work.

Once upon a time there was a company that dominated its industry. Others had noticed the profitability of this industry and were attempting to get market share. Tactics included better customer service and advanced use of technology.

One day the management of this company noticed that one of the most successful new competitors had introduced a new way of interacting with customers that was based on the successful application of an advanced telephone and computer technology. These managers were outraged, because they knew that they also could put this support in place … the competitor had simply stolen their thunder.

A crash project was formed to offer the next step of customer support using an even more advanced form of this telephonic and computer technology. The application required the best thinking of staff knowledgeable in the customer support application and the technology, working together to iterate the solution as soon as possible.

Scrum, with its iterative approach, daily status checking, and team empowerment, was investigated for use on this project. In particular, Scrum immediately solved the problem of trying to control the project using pert charts. Since the progress of the project required empiricism based on what was discovered, pert charts would be difficult to maintain and probably require a lot of the time of the project manager.

The project kicked off using the Scrum approach. However, it was soon apparent that Scrum had failed. The project was viewed as of such importance that turning the success of the results over to teams for thirty day Sprints was unacceptable. Management wanted to monitor and control the direction and activities within the project on a day to day basis.

This project was an anomaly for Scrum. On one hand, the complexity and emerging nature of the application seemed perfect for the team process inherent to Scrum. The importance of the project also seemed to require the impediment removal feature of Scrum. On the other hand, the criticality of the project generated the micro-management of all details.

This project pointed out the need for an understanding and acceptance of the philosophical underpinnings of Scrum prior to its application. The team process, impediment removal, and adaptive response to application evolution make Scrum by far the most productive approach to critical, high technology applications. However, these are also the applications where there is the most to lose if they fail. The conundrum is similar to a parents … the more you control them, the less able they will be to have meaningful lives.