Project Management == Herding Cats?
By Glen B. Alleman
Can the principles of Agile Project Management be articulated in the absence of "traditional" project management processes? That seems to be the question of the hour (or month). Many words have been written about agile PM. Ranging from questioning the need for project management at all to questioning the validity of the concept of "agile" project management. Extreme Programming advocates might claim that the role of the "project manager" is obsolete in a self-directed software development team. PMI adherents might claim that nothing can be discussed about PM without first finding guidance in the PMBOK.
Tweedledum and Tweedledee
At times this makes for interesting discussions. At other times it reminiscent of Tweedledum and Tweedledee...
"We must have a bit of a fight, but I don't care about going on long," said Tweedledum. "What's the time now?" Tweedledee looked at his watch, and said, "Half past four." "Let's fight till six, and then have dinner," said Tweedledum.
In the end it is a moot point since the practice of Project Management is just that - a "practice." The theorist will continue to state that the theory of PM is critical to its practice. And the practitioners will continue to state the "practice" is critical to its practice. Like Tweedledum and Tweedledee both are right in their own ways and both are wrong in their own ways.
So what's an "agile" project manager to do? Since I claim to be one and manage those who claim to be them as well, I'll tell you what we do, we...
- Continue to develop products with agile methods such as XP, Scrum, and Lean Construction. These methods do not artificially separate project management process from product development processes. This distinction - although interesting to some -holds little interest to agile PMs or agile developers. It's a taxonomy issue, not a project management issue.
- Continually read and reread the "agile manifesto" from the Agile Alliance, http://agilemanifesto.org. This continuous reminder is necessary for several reasons, not the least of which it is actually hard to maintain an 'agile' attitude when developing products. It is much easier to fall back into the reverse of the manifesto. Lead with processes and tools, focus on comprehensive documentation, look to the contract for problem resolutions, follow the plan even in the presence of changing requirements.
Oh you say, ".... if you were to only implement our ' normative,' 'rational' set of guidelines the problems of late, over budget, poorly responsive software could be avoided." If that were true, then software systems would be delivered on time, on budget, and gloriously meet the needs of the customers, by simply "deploying" the guidelines described in the "normative" bodies of knowledge. If these bodies of knowledge are not sufficient for successful software development project-and are simply guides to the bodies of knowledge - then what is sufficient?
Can agile PM methods create such a glorious delivery process? Not likely. Can agile PM methods go some way toward solving the "software problem?" What's the software problem? Software is:
- Brittle
- Expensive to develop
- Hard to maintain
- Very hard to update
The Emperor has No Clothes
The normative standards of the PMBOK and the "hand books" of agile development and project management have yet to deliver one important thing - a measure of the productivity of the development team in the presence of a specific project management method. I keep saying, "project management" to mean the management of the development of a software product. These are inseparable in XP, which is what we practice in our organization. The topic deserves some "objective"analysis in this area. Without repeatable experiments project management let alone software development is not a science suitable for analytical discussion.
As far back as 1971 there were voices that said ... "of all the professions on earth ours is the only one without a well defined set of guiding principles." [1] Every profession has its own set of abstractions or principles that guide its wiser members in its practice.
The question here is - are these abstractions and principles as expressed in the project management literature appropriate for the development of complex software systems? They may be appropriate for the delivery of complex construction projects, the assembly of large collections of mechanical equipment, or the coordination of large groups of personnel and organizations. But for software? Is the solution to "The Software Problem," to be found in the abstractions and principles of PM as espoused in the traditional practices described PMBOK or similar texts?
"Ay" as the Bard was fond of having Hamlet saying, "there's the rub." [2]
Do we have a set of guiding abstractions and principles for managing software development projects? If so do they result in satisfactory software projects? If not, why not? If why not, what's preventing the quest for such principles from being successful?
I'm on the editing team for the next edition of the Software Engineering Body of Knowledge (SWEBOK). In there is a discussion of "managing software development projects." Chapter 8 describes the processes involved in "Software Engineering Management." One interesting sentence in 2.2 of Chapter 8 says ..."Whilst it is true in one sense it should be possible to manage software engineering in the same way as any other (complex) process, there are aspects particular to software products and the software engineering process that complicate the effective management-just a few are as follows ...." The author goes on in his lovely New Zealand prose to describe most of the attributes I presented before (all from original sources). These attributes lead me to conclude that starting with "normative" guidelines is a mistake when defining a software project management method. Referring to these "normative" guidelines now and again is useful, but as the author suggests "software is different."
More next month on these differences, how agile PM of software projects can address some of these differences.
[1] "Looking Back and Looking Forward," Peter J. Denning, Communications
of the ACM, December 1971. pp. 819–820.
[2] Act 3, Scene 1, The Tragedy of Hamlet, Prince of Denmark, William Shakespeare,
1603.
About the Author:
Glen
Alleman is Vice President, Program Management for the Information and Network
Services organization of CH2M HILL's Communication Group. Prior to this
position Glen was the Principal Consultant for Niwot Ridge Consulting, where
he specialized in the management enterprise application integration projects.
At CH2M HILL, Glen provides services to Rocky Flats Environmental Technology Site. This work involves program management services for software development, server and network operations, infrastructure installation and removal, as well as telecommunications and wireless devices. Glen B. Alleman < galleman@niwotridge.com>
Follow Glen Alleman's practice of Agile Project Management through his recent PM World Today Viewponts. Here is a list of his 2002-2003 columns.
o Nine Best IT PM Practices
o Agile Project Management
o Principles of an Agile PM Method.
o Practices of an Agile PM Method.
o Agility and the Myths of Software Projects
o Agile Project Management And Earned Value
o Agile PM and EV - A Field Report
o Agile Project Management - A July 02 Field Report.
o Agile Project Management - A February - March
03 Field Report.
o Agile Project Management - An April 03 Field
Report.
o Agile Project Management - A May 03 Field Report.