The following text is the Preface to Scrum Project Management written by Kim H Pries and Jon M Quigley and published by CRC Press from Boca Raton Florida published in 2011

Scrum Project Management Shows how to Apply for other than Software Projects

Product development is becoming ever more complex. The pace of technological change is ever increasing, leaving little time to accumulate expertise before development of a particular product is to start.  Acquiring enough experience to be able to predict the risk, and the courses of action during the development is difficult and often happens in the course of the live fire of the development project. This creates a need taping into all of the players in the development effort and relying less on the heroic figure to save the day and carry the project and product to a successful conclusion. Even when there is a heroic figure, and he does carry the day, the organizations loss of this individual will be detrimental to the organization. The recovery period could be quite long.

We are presenting a modified version of the agile software development tool Scrum as an alternative to traditional program management and even as a tool for standard line management. Both of us have experience deploying and implementing the tool. We understand the pitfalls, which we will illuminate during the course of this book.
This is not to say that we believe the waterfall approach is condemned to obscurity or that we are calling for the death of this model. In fact, we know of very few organizations that take the waterfall method as it is often portrayed in books as a very rigid and one-way pass through the development process. In fact, there are some similarities between the methods, although scrum approach throughput can be much quicker and keeps people focused upon what is deemed important by the project. Additionally, the team aspects of the method – moving toward self-directed work teams, means the actions the team need to be successful are largely in the teams hands. Of course, this means you must have a motivated and skilled team to achieve. It is not possible to condemn the conventional tactics across the board, when frequently the conventional tactics are not executed well. Poor execution does not improve the possibility of delivering a quality product no matter the model or method of execution.

We like to call this style of getting things done “high-intensity management.” We demand and we see acceleration of tempo, focused completion of tasks, and improvement in project backlogs like we have never seen before. With one example, we were able to drop a production test equipment (automated test equipment) organization projects list from sixty items to thirty items to twenty items in less than three months! We had never been able to achieve these kinds of results until we implemented the relevant portions of the scrum approach to accomplishment.

For some time now, organizations have been attempting to empower the employees. Some organizations have moved to self directed work based teams.  This means pushing down much of the decision and execution aspects of organization. In his book, Leading Self-Directed Work Teams, Kimball Fisher provides a comparative list of attributes for self-directed work teams and the traditional organization[1].  Scrum puts the control of how the product gets produced, in the hands of the individuals responsible for delivery. This is within the confines of the organizations philosophies and constraints.

Empowerment = f(Authority, Resources, Information, Accountability)

Empowerment = 0, if Authority = 0; or Resources = 0; or Information=0; or Accountability = 0

Fisher takes the word empowerment from being a business buzzword and puts some meat on it. He also makes it clear what factors must be available for empowerment to take place.