IT project managers should understand how the Project Management Body of Knowledge (PMBOK) aligns to Software Engineering Processes (SEPs). This article explores the application of the PMBOK to an SEP called Agile or Extreme Programming (XP) and explains how project managers can combine or "stack" these processes--ultimately improving analysis, development, and delivery in software projects.
PMI processes are frequently applied to software development projects. Given that information technology has its own set of software engineering processes (SEPs) and that the underlying technologies continues to change at a rapid pace, the application of the Project Management Body of Knowledge (PMBOK) to software development can produce a wide and unexpected range of outcomes. In order to improve process coherency and drive down risk, an IT project manager should be aware of the software "process stack," or the alignment of PMBOK to a SEP.
One popular SEP is the IBM Rational Unified Process (RUP). RUP is a product and SEP that provides a disciplined approach to assigning tasks and responsibilities within a development organization (RUP). Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget (RUP). Both RUP and the PMBOK are structured, include standardized roles and documentation, and stress analysis before execution. When provided with sufficient resources, a project manager can produce a positive outcome with relatively low risk in a large and structured software development environment. The PMBOK tends to work well with robust SEPs.
However, as large and small projects have their belts tightened in the face of leaner budgets and increased oversight, organizations are choosing smaller and more nimble SEPs like Agile or Extreme Programming (XP) (See Figure 1). The XP community has identified many best practices that are especially applicable to small, co-located project teams. These practices require less training, stress small releases, extensive testing, refactoring, pair programming, collective ownership, continuous integration and on-site interaction (see Figure 2). It is more difficult to successfully apply the PMBOK to an XP project. Where there is process, XP relies on informal and verbal communication, and tends to delay decisions until they must be made. This is clearly a different approach than that which is recommended by the PMBOK. Rigorous work breakdown structures and Gantt charts will not be adopted easily by an XP development team. Introducing a network diagram may be a tactical error–an XP and highly technically competent audience will expect a plot with pictures of servers and systems deployment information. Any individual who uses a “network diagram” for project planning is likely to be quite confused. In fact, XP has a completely different set of terminology. Essentially, scope is called a "product backlog," stakeholders “personas,” stakeholder requirements "stores and retrospectives," person-days "story points," and a logically related sequence of development activities an "iteration."
Process differences are also cultural. XP focuses on the journey and not the destination (Hussman). Rather than plan ahead and assign clear roles and responsibilities prior to project execution, XP advocates collective ownership. Team members may be empowered to make development changes in the absence of a project plan. This approach may work with a small team for a limited duration, such as for a prototype, but in a large environment and over time, this practice can be detrimental. It is not practical to have collective ownership across a large enterprise organization. If developers believed themselves to be owners without proper oversight, they would likely modify and ultimately accidentally break key infrastructure with the potential for a disastrous impact.
Moreover, XP attempts a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff (Fowler). The differences in this approach are clearly visible with software refactoring. In a project guided by the PMBOK, a need for software refactoring might need to be formally communicated, assessed, and if approved by a change control board, carefully applied to a new baseline.