“Only those general principles and attitudes that result from clear and deep understanding can provide a comprehensive guide to action.” [1]
Agile Program Management contains practices found in traditional program management, delivered through the principles of agile. For the traditional program manager, this description is likely meaningless. Before these principles can have value to an IT organization some background on the problem and the previous approaches is needed to show how these gaps are addressed by the Agile Program Management practices.
There are several official descriptions of agile. † These descriptions fall short for the traditional program manager, not because the principles of agile are lacking, but because the practices of program management are not directly addressed using the software development focused methodologies presented by these authors. ‡ As well the distinction between project management, program management, and software development management is not clearly drawn in these approaches. Add to this the variety of different drivers for the development or acquisition of software systems and the practices of agile program management become lost in the vocabulary of software development. [2]
Where Does the Problem Start with Traditional Program Management?
Traditional management disciplines start with a retrospective approach that measures variance against the plan, rather than providing performance forecasting information that can be used to guide projects in a chaotic environment. [25] These traditional systems measure work accomplished through cost and schedule variance rather than technical and business accomplishments. These principles make use of linear, ‡ stepwise refinement, of the project management processes based on a planning–as–management paradigm.
Plans made in this way and adjusted by linear feedback methods cannot cope with the multiple interacting and continuously changing technology and market forces. The success rate of applying traditional methods to complex software development projects over the years has been underwhelming. There are a number of critical issues with IT projects that suggest better attention to implementation procedures and management processes to deal with change is needed. These approaches start by avoiding the application of linear processes found lacking from past experience.
The impact on a project from external forces or from problems within the project is given little attention in the linear approach. Avoiding or controlling change is the primary activity. In this traditional model, “change” is undesirable; when in fact change in the world of business systems is natural as well as desirable. A gap arises when the difference between managing in the presence of change and managing change is not understood. Agile Project Management uses risk and opportunity management to create a set of practices that proactively and explicitly manage in the presence of change.
† The current definitions of agile are strongly influenced by the software development paradigm. While this is useful to those writing software, for the Program Manager of development projects or the procurement and integration of COTS products, the software-centric paradigm has limits.
- Agile Alliance
- Declaration of Interdependence,
- Agile Project Managers Leadership Network,
- David Anderson’s Agile Management site
- Agile in a Nutshell
‡ In these models it is assumed that each phase of the project is complete in a fixed sequence, followed by the next logical step in the sequence.
References
[1] Collins, Jim, Good to Great: Why Some Companies Make the Leap…and Other’s Don’t, Harper Collins, 2001.
[2] Koffi, Atiogbe Dider, “A Model for the Evolution of Software and Systems Engineering Project Cultures Throughout Their Lifecycles,” Systems Engineering Journal, Vol. 8, No. 2, 2005.
