Wednesday, November 19, 2008

A Project Manager’s Survival Guide to Going Agile

When software development project teams move to agile methodologies, they often leave project managers behind. Traditionally trained project managers are confused as to what their new roles and responsibilities should be in an environment that no longer needs them to make stand-alone decisions.

This paper focuses on re-defining the job of project manager to better fit the self-managed team environment, one of the core agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an agile software development approach.

The Movement to Agile Methodologies
Agile software development methodologies such as Extreme Programming (XP), Scrum, Crystal, Lean, etc., are becoming more prevalent in the industry. What is it about these approaches that have companies all over the world casting out their traditional plan-driven methods in favor of an agile process? And how do project managers fit into the new archetype, which favors self-managed teams?
Companies are moving to agile processes because the technology marketplace demands its suppliers be highly responsive to change. In order to compete in the global economy, companies must move quickly to provide solutions to a client base that has more and more choices available to them. Agile approaches promise faster delivery of working code, higher quality, and an engaged development team that can deliver on its commitments. Traditional waterfall, with its long phases and heavy investment in “big up-front design,” lacks the flexibility to swiftly respond to the market.
It’s also about the money. Agile processes can provide a larger return on investment by decreasing the investment in inventory, decreasing operating expenses, and increasing throughput (Anderson, 2004). In other words, by eliminating the time and money spent on designing an entire system – a design that may be outdated before it is implemented, a design that may have numerous pieces that are never even coded – and by eliminating the waste that accompanies heavy process, software development teams are able to provide rapid delivery of value to customers, resulting in greater profits.
Agile methodologies aren’t going to be a fad. The transition to agile processes is a growing trend that will have lasting effects on the industry and the people involved. It’s a different way to work, one that requires greater communication and cooperation from its participants and greater leadership from its managers. In fact, the job titles in use today – manager, director – are illustrative of the traditional command-and-control approach that are now giving way to the new guidance and mentoring method of working with teams. It will be a challenge for many of these managers to release control, as they begin to make the transition to being leaders.

Agile vs. Plan-driven Development

Both agile and plan-driven development recognize the triple constraint: cost, schedule, and scope. But whereas plan-driven development advocates locking down the requirements so that schedule and cost can be estimated, the agile approach says that scope is always changing and therefore schedule and cost should be fixed. This way projects don’t become death marches, and the product is developed in a fashion where it’s in a perpetual releasable state.
This basic shift in focus has a cascading effect on each subsequent practice in both approaches. Planning, executing, and controlling disciplines move from more directive, command-and-control tactics to facilitative, collaborative support. The idea being that if you give the team the tools they need, help them to understand the business problems they’ll be solving, and give them the space and time to complete the job, that they can then be self-directed and self-organizing, and become a fully engaged and motivated team that produces high-quality products at a faster clip. Clearly, for many organizations, this change in tactics also leads to a shift in the culture and in the ways success is measured.
Project managers will find themselves learning how to guide their team in responding reliably to change instead of conforming to plan, and learning how to do this in a completely new environment where the team makes decisions instead of being told what to do. It means more individual responsibility for team members, and more facilitation skills required for the project manager. Most are uncomfortable with their new roles at first, and it is the project manager’s responsibility to build team cohesion and foster good communication. Not everyone is willing to make this paradigm shift, project managers included. But for those who are willing, they’ll find both the process and the new skills they’ve learned to be richly rewarding and well worth the effort involved.

No comments: