Software Project Management Reading List

Niwot Ridge Resources

A Source of Information for Mission Critical Systems, Management Processes, and Strategies

Publications

Agile Software Project Management Discussion

This list provides resources for agile software project management. This list includes books and papers on a variety of topics. The purpose of the list is to provide an academic foundation and practical experience base for managing software development projects and products using the principle and practices of agility.

Anchored by the Project Management Institute's Project Management Body of Knowledge (PMBOK), much of the PM literature places emphasis on a set of practices required to successfully manage a project.

Arranging these practices so as to address the needs of a modern software management process is not defined by the PMBOK. By "modern" I mean one in which emerging requirements, changing technology, declining–returns–economies, and post–normal attributes operative.

Modern–Science Approach to Project Management

Modern project management is heavily influenced by the belief that a project management process can be improved by scientific methods. These include the beliefs that:

Clear–cut investment opportunities with an explicit purpose, beginning, duration, and end can be identified early in the project.
Low opportunity costs for each business or technical decision exist, in most instances with a reversible decision process.
Feasible, suitable, and acceptable project attributes can be identified.
Accurate predictions of project duration and resource demands are possible once the requirements have been defined.
Worst–case consequences can be determined in advance.
The failure of the project was due to lack of skills rather than inappropriate feasibility, suitability, or acceptability of the solution.

Post–Modern Science Approach to Project Management

This is a normal–science view of project management. [1] In an emergent software development domain, this view can be replaced with a post–modern view, in which there are:

Highly uncertain facts about the project attributes.
Constant disputes about the values and expectations.
High decision stakes with irreversible consequences.
Urgently needed decisions in the presence of insufficient information.
Outcomes that affect broad communities of interest.

Agile methods do not mean that the normal–science model is irrelevant, just that such a model is applicable only when uncertainty and decision stakes are low.

A fundamental attribute of post–normal science method is the reliance on heuristics. Using heuristics to guide the development of a software project allows the project management method to be placed in a post–normal science context as well.

There are several issues with normal–science approach, not the least of which it is the control centric. The most recognizable control of software development exhibited by the high-ceremony linear waterfall method. Attempting to control a development process which by its very nature is emerging and evolving leads to disappointment for all participants - stakeholders and providers. It also creates the initial emotional disconnect between the high–ceremony PM methods and agile methods.

Empirical Process Control Paradigm

One way to distinguish the differences between traditional project management and agile project management is to look at the process as a control system.

"It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice." – Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992.

Empirical process control relies on frequent inspection and continuous adaptation to minimize risk and produce quality product. Agile project management implements empirical process control through iterations, frequent increments of working, and tested functionality. Requirements emerge through the efforts of self-organizing small teams, and direct collaboration with the stakeholders.

The General Discussion Question

In order to generalize the discussion, here are some questions that might be asked:

How can an Agile Project Management method be reconciled with the contents of PMBOK, CMM, or other high–ceremony guidelines?
Can the elements of the PMBOK be applied to an agile PM method?
In which software development environment is the so–called "waterfall" method appropriate?
In which environments is waterfall clearly not appropriate?
How can the project manager make the determination which of the many PM methods to use?

Just a Quick Starting Point

One important aspect of Agile PM is a description of what the project management does not do, that distinguishes it from the high-ceremony project. The PM does not:

Assign work to the developers from an external resource of process.
Design the system in an "up front" manner.
Set Priorities without the full participation of the stakeholders.
Select the features for implementation without the full participation of the stakeholders.

These activities and many others are done by the team and the customer.

[1] Classical science and conventional problem solving were labeled “normal science” by Kuhn. Post–Normal science acknowledges there is high system uncertainty, increasing decision stakes, and extends the peer review community to include the participants and stakeholders, who insure the quality and validity of the conclusions.