INTRODUCTION Throughout the last 40 years software development projects have continued to be over budget, overdue and lacking in both level of quality and desired functionality (McDonald, 2001). Various potential reasons have been cited for this lack of success, but there is one point of agreement. Something definitely appears to be "broken" in the software development process indicating that there may be a better way to engineer software. Some believe the answer lies in the host of new "agile methodologies" that have arrived on the scene in recent years. These methodologies emphasize people over process, software over documentation, customer collaboration over contract negotiation and responding to change over following a plan. While there is still much debate over the effectiveness of these new agile methods, there is general agreement that they are quite different from the traditional process oriented approaches. For example, in an agile environment, the overall project is not planned up front, but in small iterations and developers are "self-organizing" in that the teams determine the best way to handle the work. (Boehm & Turner, 2004). One major implication of these differences is the need for a less rigid and formal approach to project management. A very rigid and controlling type of manager, with a successful track record managing process driven software projects, may not be the right candidate to manage an agile project.
