Traditional project managers are often uncomfortable with the apparently unstructured nature of agile software development. This article gives a definition of project management, and then goes on to cover traditional project management, why software development is different, how agile project management is different, and the role of an agile project manager.
Definition of Project Management
According to Wikipedia: Project Management
Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.
Unlike operational activities, which are on-going, a project is finite with a beginning and end. Each project is trying to achieve a clear objective and bring about change. Not surprisingly in the software development world that typically means building software. Project management has to balance scope, quality, time and budget to achieve the given objective.
To illustrate the difference between a project and an operational activity consider a company that wants to make a DVD player. The effort to design the DVD player and set up the manufacturing facilities to make the player is part of one or more projects. Once that has happened, and DVD players are rolling off the production line, we are in operational mode without a project in sight.
Traditional Project Management
Traditional project management is based on experiences in manufacturing and civil engineering. Wikipedia: Project Management lists project management activities and the resulting artefacts.
| Project management activities | Project management artefacts |
|---|---|
|
|
In my opinion the distinguishing feature of traditional project management is the attempt to identify all the work, down to task level, at the start of the project and then manage against that (the traditional approach is sometimes called plan-driven to reflect this). This approach primarily manifests in one of the artefacts and two of the activities listed above:
- Work Breakdown Structure (Artefact)
- Assigning tasks (Activity)
- Directing activities (Activity)
A Work Breakdown Structure (WBS) is “A task-oriented detailed hierarchical breakdown, which defines the work packages and tasks at a very low level” (Ohio State University: Office of the CIO). The WBS lists the tasks after which the traditional project manager can start “Assigning tasks” and “Directing activities”. This approach works fine in a well defined project such as putting in a new Radio suite for the BBC. In this scenario the problem domain is well understood because the team have done it before, it is just a matter of buying the kit and doing the work.
Traditional project management is “Predictive” in nature (Boehm & Turner, 2004, cited in Wikipedia: Project Management). Predictive teams try to plan the future in some detail. This emphasis means they have difficulty changing direction – and change is inevitable in software development.
By the way some project management methods, e.g. Prince2 and DSDM, advocate a variation on the WBS called a Product Breakdown Structure (Wikipedia: Product Breakdown Structure)
Why Software Development is Different
Software development is different! The problem in software development is that the project manager doesn’t have sufficient information at the start of a project to create a meaningful WBS, which almost guarantees the project will go out of control.
The best arguments I’ve found for why software development is different are in Lean software development: An Agile Toolkit (Poppendieck & Poppendiek, 2003) and Agile software development with Scrum (Schwaber & Beddle, 2002). Both essentially argue that software development is a creative process more akin to designing a new product than manufacturing the final product. Where a production line can churn out product with predictable regularity a design team has to deal with a lot of uncertainty so its efforts are very difficult to predict. Software development requires a different approach to project management.
In contrast to the “Predictive” nature of traditional project management, project management in software development needs to be “Adaptive” (Boehm & Turner, 2004, cited in Wikipedia: Project Management). An Adaptive team ensure that they can change with events. They make little attempt to accurately predict what will happen in the future. The further in the future the less detail the Adaptive team will have.
The Agile Approach to Project Management
The difference between what a traditional project manager does and what an Agile Project Manager does is more about the approach taken than the activities. The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile Project Manager is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:
- Gather information from all stakeholders and integrate into workable plan
- log estimates
- advise programmers on their estimates using historical figures
- log task assignments
- sustain high rate of progress
- make decisions
- remove impediments
- build and sustain team culture
- ensure team sticks to process
- liaise between management and team
- manage customer relationships
- fend off “feature creep” and other project hazards
- get agreement on the prioritisation of requirements and detailed content of timeboxes
- track progress against the timebox goals/plan
- collect information without disturbing the process
- update plans
- communicate progress
- ensure that the lessons are learnt
- log defects
- stay calm
Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional project management role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.
How Agile Project Management is Different
I belie
ve Agile practices bring a certainty to software development which traditional project management cannot. Agile can do this because it emphasises an empirical approach with short cycles of the structure: plan-do-check-act (classic Total Quality Management; see Wikipedia: PDCA). These cycles happen at different levels: each day, each Timebox, each Release, and each project. Agile demands the team look at how fast they are progressing and adjust accordingly – this is the “Empirical” aspect of Agile Project Management. Agile is lean and emphasises feedback, for example, if we need a status meeting then do it daily (more feedback) but make it lean (at most 15 min), hence the Agile Daily Meeting.
Back in 2002 when I wrote my Agile Comparison I already noticed strong similarities between the main Agile methods (primarily Scrum, XP, DSDM). Since then there has been even more convergence amongst the methods. Although the Scrum books doesn’t mention putting the Timebox number in the Product Backlog, thus effectively making it a Release Plan (see Agile Project Planning), Ken Schwaber recommends it. Similarly Ken now recommends XP’s Technical practices (see Agile Project Execution). In fact it is now common practice for organisations to adopt Scrum and embellish it with the XP technical practices – for example we did this at the BBC.
But we can’t throw the baby out with the bath water and I recognise the useful contribution that traditional project management techniques make to the art of managing software development projects. Therefore my definition of Agile Project Management uses Agile practices at its heart, to develop software, but is cloaked in the language of traditional project management. In other articles I show how to do the activities of a traditional manager in an Agile fashion:
- Agile Lifecycle / Agile Heartbeat
- Agile Roles and Responsibilities
- Agile Pre-project
- Agile Project Initiation
- Agile Project Scope
- Agile Project Planning
- Agile Project Estimating
- Agile Project Execution
- Agile Project Monitoring and Control
- Agile Quality Management
- Agile Risk Management
- Agile Change Management
- Agile Project Closure
References
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.
Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.
Boehm, B., and Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley.
Cockburn, A. (1998). Getting Started: Plan the project by milestones. Surviving Object-Oriented Projects: A manager’s Guide [Chapter 4], 77-105. Addison-Wesley.
Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley.
DSDM Consortium. (1997). Dynamic System Development Method [3rd ed.]. Tesseract Publishing.
DSDM Consortium. (2002). Framework for Business Centred Development:Handbook for DSDM Version 4.1. Author.
Ohio State University: Office of the CIO
Poppendieck, M. and Poppendiek, T. (2003). Lean software development: An Agile Toolkit. Addison-Wesley.
Schwaber, K., & Beddle, M. (2002). Agile software development with Scrum.. NJ: Prentice Hall.
Stapleton, J. (1997). DSDM – Dynamic System Development Method: The method in practice. Harlow, England: Addison-Wesley.