Abstract
Agile project management and software development have become hot topics in recent years; several papers at the 2006 PMI North America Global Congress specifically addressed the topic. To date though, the emphasis seems to have been on how to move from a traditional approach to Agile, abandoning the traditional approach completely.
While Agile might be the best approach for some projects, other projects still require the rigor of a more traditional approach. For example, upgrading a financial system may require specific documentation to comply with Sarbanes-Oxley. How should an organization decide which approach to take? Does an organization have to use just one approach? Can the approach be modified in the middle of the project?
In this paper the author discusses how an organization with a traditional PMBOK® Guide-aligned project management approach can adapt an Agile approach, while keeping the traditional approach in place. The paper looks at both Agile and traditional methodologies, including key deliverables, process steps, and advantages of both. The author also discusses how to decide the best approach based on key parameters such as the level of risk, the level of uncertainty, and the speed of delivery. The paper also examines how the approach can be adjusted or changed while the project is underway.
This paper approaches Agile from a strict methodology standpoint. To successfully implement Agile, a number of other factors such as organizational change management, training, management support, and coaching must be considered. In addition, implementing a new technology cannot be rushed. A successful methodology implementation in a large organization could take six months or longer to complete.
A Theoretical Overview of Agile Project Management
The Manifesto for Agile Software Development (© 2001) set the core values for the Agile approach:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more. (Agilemanifesto.org, 2001)
While the manifesto focuses on software development, the principles apply to project management as well. For the project manager this means:
- The project team selected for the project is more critical then the process they follow. The process itself will evolve.
- The team focuses on features the user can see, not documentation.
- The customer should be very involved in the project.
- The product will evolve; an effective plan cannot be created from the beginning because there are too many unknowns.
There are several common myths in Agile project management. One myth is that there is no planning in an Agile approach. Planning does occur, but, like the actual development, it is an iterative process. Teams initially plan high level features. At the start of each iteration, a more detailed plan is created for that iteration. While detailed plans are not developed at the beginning, because of the unknowns, planning is definitely part of an Agile project.
Just as there are no detailed planning documents developed at the start of the project, there are no detailed requirements documents. Project teams work closely with the customer to define the features of the end product. In this phase, only high level information is documented for each feature; details are determined during the iteration in which the feature is developed.
A second myth is that Agile projects do not require project managers. In reality, the role of the project manager is different since there is less emphasis on management activities, such as planning or budgeting and more emphasis on leading the team. Jim Highsmith uses the term “leadership-collaboration” to describe the modified role of the project manager (Highsmith 2004, p. 59). In the Agile environment, project managers focus on communicating the project vision, providing support for the team, and removing obstacles that would impede progress.
A Traditional Project Management Methodology Based on the PMBOK® Guide
A Guide to the Project Management Body of Knowledge (PMBOK Guide®) is intended “to provide a general overview” of good practices (PMI, 2004, p. 3). To lead a project, more detail is necessary; this is where a project management methodology comes in. The American Heritage Dictionary describes methodology as “A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods” (2000).A project management methodology, then, is a toolkit that used to manage projects. There are a number of items that are part of a methodology:
- Procedures
- Guidelines
- Templates
- Checklists
- Definitions of Roles and Responsibilities
The procedures may be packaged in a project management handbook and contain the step by step approach to running projects. While this may be contained in a printed document, changing technology has made it more likely that it will be a collection of web-based pages with links to other components, such as the templates or checklists.
Guidelines are detailed explanations on how to execute a particular task, or information that might aid in the execution of that task. These would be especially useful for someone new to the methodology and ensure they understand the particular activities of a task, such as preparing the project schedule.
Templates, of course, are forms used to capture information. Examples include the project charter, status reports, schedules, project management plans, etc. Organizations may have both blank templates and examples or samples, showing how completed templates will look. Project managers familiar with the methodology may go straight to the template list when running a project, having become familiar with the content in the handbook and guidelines.
Checklists are quality management tools for executing the project and contain the steps of an activity to ensure completion of all the steps. For example, a checklist for the initiating phase of the project may contain steps such as completing the project charter, obtaining sponsor approval of the preliminary scope statement, and identifying the planning team.
The roles and responsibilities of the project management team are defined within a well-written methodology. The definition includes key responsibilities, the deliverables they are responsible for, and timing for their engagement in the project. In addition to descriptions, a responsibility matrix can be used as a project template.
Other components of the methodology might include:
- A glossary to define specific project management and organizational terms
- A contact list to provide information on who to contact for project management questions or assistance
- A document repository to provide a structure to support knowledge management.
- More advanced tools such as wikis or blogs may also be included in the methodology structure.
Exhibit 1 shows the phases and major processes for a methodology aligned with the PMBOK® Guide. Each of these processes has additional activities.
Exhibit 1 – High Level Overview of Traditional Methodology
Taken from PM Solutions’
Project Management Community of Practice SMMethodology
Exhibit 2 shows activities within the Project Definition process. Each of these activities would have steps to follow, associated templates, and other supporting documentation such as Guidelines for specific tasks or definition of roles.
Exhibit 2 – Activities for Project Definition
Taken from PM Solutions’
Project Management Community of Practice SM Methodology
An Agile Project Management Methodology
There are a number of Agile approaches for software development. Some of the better-known are Extreme Programming (XP), Scrum, and Crystal. This paper, however, will take a more general approach to Agile project management. While each approach brings its own vocabulary, more traditional project management terms will be used in the description presented here. Exhibit 3 presents the approach.
Exhibit 3 – Agile Project Flow
Regardless of the approach used, organizations should have a standard project initiating process. These activities help define the purpose of the project and may include preparing a business case or project request. At this time, the decision to apply either a traditional or Agile technique will be made. This decision process will be discussed in more detail later in the paper.
Once the decision is made and a project manager is assigned, the project charter is prepared. Like a traditional project, the charter will include an overview of the project, the project timeline, assumptions and constraints, and risks. The project charter for an Agile project should also focus on the vision of the project.
Having a clear understanding of the product vision at the beginning of the project is key to the success of the project. The vision will provide a clear understanding of why the project is being undertaken and help guide decisions throughout the project. The vision should be developed jointly by the user, project manager, and project team. The vision may also be developed in a workshop environment lead by a facilitator.
This activity shows how the Agile methodology is different from the traditional approach. There isn't necessarily a template for the visioning exercise, so the completion of this step relies on the ability of the team to collaborate and the experience of the project manager or facilitator to lead the team to the desired outcome.
Once the charter has been accepted, the team moves into the planning activities. Key areas of focus are documenting key project information and capturing the product features. A project data sheet and product feature list can be used to capture this information (Highsmith, 2004, pp. 101,132).
The Project Data Sheet template captures key information on the scope of the project, including benefits, technical information, and customers. The project data sheet also captures project information, including initial targets for the schedule and budget.
Project features are captured in the Product Feature List template; they are prioritized and then further defined. The prioritized feature list and estimates for effort are used to develop the Iteration Plan.
Some standard project management techniques are applied during planning, including development of the communications plan and the risk register. Once the risks are identified, however, the approach to addressing the risks in an Agile project is different.
Risks can be associated with specific features; features with high risk are addressed in early iterations of the project, so the risk can be mitigated earlier in the project's life cycle.
The final planning activities are the development of the schedule and budget. The budget template for an Agile project may be a similar or scaled down version of the traditional budget template. An Agile schedule differs from a traditional schedule in that it lays out the general timeline, including the number and length of the iterations. Based on a priority ranking of the features, they will be slotted into iterations. The development of a detailed task list or identification of dependencies at this time will be done further into the project.
A technique referred to as timeboxing may be used. In timeboxing, the end date for the project is determined. The team and customer work together to prioritize the list of features and the first iteration begins. The goal is to complete as many features as possible within the allocated time and set of iterations and release the product on the predetermined date. Because the features are prioritized, important features will be included (other features will be added later, as possible). This approach forces the customer to make hard choices and helps eliminate gold plating (extra features that aren't required, but may look good).
The executing, monitoring, and controlling phase is composed of a series of iterations. The number and length of the iterations was determined during the planning phase. At the start of each iteration, the team plans out the iteration in more detail, including assigning work to team members, developing the activities for each feature, and scheduling the work.
While the purpose of this paper isn't to explain the details of Agile project management, there are some differences in execution are worth mentioning. A daily standup meeting replaces the written status reports. White boards are used for documenting key ideas. The team works in pairs, thereby improving product quality. The customer is highly involved, providing constant feedback on features as they are completed.
Comparison of the Two Methodologies
So what is the difference between traditional and Agile project management from a methodology standpoint? Both methodologies use templates. Both have procedures and guidelines. Is there a difference?
Clearly, the Agile methodology is not as detailed as the traditional methodology. This supports of the idea of “individuals and interaction over process and tools” contained in the Agile manifesto. While there may be general guidelines in the Agile approach, it does not have the details provided with the traditional approach. There will be fewer templates and less specific procedural steps in the Agile methodology.
Agile principles stress a working product over documentation. Because of this, the Agile approach shifts more quickly to execution and spends less time on planning. Complex project management plans, detailed requirements documents, or documentation of roles and responsibilities, which are key planning documents of a traditional methodology, are not included..
One key aspect of the Agile approach is adaptability. The team not only looks at the product as it is being developed and make changes to features, they also look at the process. At the end of each iteration, the team conducts a lessons learned session, often referred to as a retrospective (for example, Highsmith, 2004, p. 220). The point of the session is to review both the product and the process. The team discusses how the project is going and what changes to the procedures would increase their performance. For example, the team may decide they need to modify the testing process or change the format of the daily standup meeting.
In traditional projects, conducting lessons learned is part of the project closing process. As in the Agile approach, one topic is a review of the project management processes; although any recommendations to changes in the process impact future projects rather than the current project. Even if the lessons learned are conducted at the end of each phase, because that phase won't be repeated for the project, the recommendations will only impact future projects.
How to Select the Correct Approach at Project Start
As stated above, the decision to follow either a traditional or Agile approach is made during Initiating. This decision is made by the project sponsor, project management office, and project manager, if already identified. Factors to consider are:
- How clear are the requirements? An Agile approach better suits a situation where the requirements are unclear or subject to change whereas the traditional approach is more suited to the situation where the requirements can be clearly defined at the start of the project
- Is new technology involved? The Agile approach allows for more experimentation with new technology. When the technology is not new, a traditional approach may be more appropriate.
- Is there a lot of risk? With an Agile approach, risk can be addressed sooner in the project.
- Is the right team available? An Agile team is typically small and composed of more experienced members. If the project requires a larger team, the traditional approach may better suit the project.
- What is the criticality of the end product? Because there is less documentation, an Agile approach may not be appropriate for critical products such as drug development or space shuttle components. In these cases, a more traditional approach is best.
Based on these questions, checklists can be used to assess the project factors to decide the best approach for any project. Obviously, the sponsor will need to be comfortable with the decision. If a sponsor is more used to a traditional approach, supporting an Agile project could potentially create confusion or conflict. For example, consider project status reporting. In the traditional approach, sponsors typically receive a weekly written status report. In the Agile world, the sponsor is told they have to show up for the daily stand-up meeting to get a status update. They may resist this change and ask for the weekly status report anyway. The project manager will need to educate the sponsor on the Agile approach and sell the benefits so that the sponsor understands how they support the project in this new environment. In some cases, the project manager may have to perform some of the traditional project management tasks behind the scenes to support stakeholders while the team marches forward using the Agile approach.
How to Adjust the Approach Mid-project When Necessary
As part of the Agile approach, project teams review the processes and procedures at the end of each iteration and make necessary adjustments to improve performance. These adjustments may be small (changing the time of the stand up meeting) or very significant (deciding to continue the project using a traditional approach).
The project may have started as an Agile project because risk was high or there was uncertainty with the requirements. However, these challenges may be resolved in the first few iterations. At that point, the team may decide to continue the project using traditional techniques. If this happens, the project manager must ensure all stakeholders are made aware of the decision and the impacts of the decision.
Conclusions
Each approach has a number of advantages. Organizations that use both approaches must understand the advantages of each so that the best approach can be selected for any given project.
The traditional approach is better suited for complex projects with larger project teams. Agile works well with smaller teams with high skill levels. The traditional approach also works better in more stable environments where there is little use of new technology. Agile works well when new technology is being used. A traditional approach provides a higher level of documentation. Agile works well when requirements are unclear or risk is high.
While Agile is flexible, it isn't always the fastest approach. Although it is true that a working version may be developed sooner, the situation could also exist where a first version of the product is developed and, after reviewing it, the team starts over again. Because there wasn't as much planning, the team may discover how not to design the product.
