How agile software development teams are built on PMBOK® guide best practices
When traditional Information Technology shops are introduced to Agile methodologies, such as Extreme Programming (XP) or Scrum, myths and preconceptions about Agile often create barriers to a thoughtful evaluation. Likewise, when poorly or partially implemented Agile practices are used on pilot projects, the lessons learned relate more directly to the implementation than the practices themselves. If you can get past the myths and misinformation about Agile software development practices, you will find that the key lessons documented in A Guide to the Project Management Body of Knowledge (PMBOK Guide)---Third edition (Project Management Institute, 2004) drive many of the Agile software development processes.
In today’s challenging business environment, there is tremendous pressure to accomplish more work with fewer resources. In response to this challenge, some organizations have experimented with the adoption of Agile Software Development methodologies in an attempt to help their programmers write software faster. Unfortunately, these experiments can be both unsettling and confusing for various members of the organization, and sometimes even more so for the project participants. These experiments also often yield inconsistent results. One reason for these inconsistent results is a basic misunderstanding about what it means to go Agile. Even many strong Agile proponents do not understand what makes Agile succeed. It is my position that Agile methods succeed because of the rigorous implementation of core project management processes within their daily activities.
Some of Agile’s advocates would argue that Agile makes project managers obsolete. This is an unfortunate characterization. It would be more correct to state that Agile focuses on fully implementing a few critical project management tools. The implementation of these tools is woven deeply into the behaviors and culture of the team. Perhaps more importantly, successful Agile teams focus on the content of the project management tools instead of the format or the technology used to implement those tools. For example, many Agile teams use index cards to track their work breakdown structures (WBS) instead of using software tools. Ultimately, teams that implement effective project management are typically more successful than teams that simply fill out all of an organization’s required project management forms and reports.
Some Key Project Management Practices
Although many project management practices are important, some of the practices are fundamental and answer important basic questions such as:
- What are we going to do?
- What will we have when it is done?
- What will it cost, and how long will it take?
- Who is going to do the work?
- Who is authorized to make decisions that change the outcome?
Many projects could have dramatically improved outcomes if all of the project’s stakeholders had the same answers for all of these questions. Almost all successful Agile teams use key project management practices to keep stakeholders synchronized on these important topics.
Synchronizing Stakeholder Groups
Getting all of the stakeholders for a project on the same page can be difficult. This difficulty is compounded if the project plan changes during the course of the project. Many projects attempt to avoid this difficulty by freezing scope, or by creating a difficult change control process. Unfortunately, changing business conditions, the changing capabilities of technology, changes in available resources, or simply discovery of mismatching project visions represent a negative impact on project outcomes. Effective management of these influences often require changes to the project plan.
Many teams find that adapting a project plan to external changes is an important component of project success; these projects typically make use of the natural linkages between key project management processes. In particular, three outcomes typically occur:
- Change control results in an updated project plan, in which work package definitions change.
- Change control becomes the normal routine process instead of an exceptional case.
- Change control is seen as a tool to adapt the plan instead of a mechanism to freeze scope.
Exhibit 1-- Process Groups in Project Management (PMI, 2004, p 40)
The shorter the time period required to loop through all three process groups, the greater the level of control available for making timely, thoughtful changes to the project plan. In addition, each planning cycle is informed by the actual performance observed in the preceding execution cycle.
Agile teams use this cycle to create an intentional and rigorous feedback loop. By formally scheduling all of the processes to occur in a repeating cycle of 1 month, 2 weeks, or once per week, the team measures results and then updates their project plans accordingly. Each of these cycles is called an “iteration,” and has a full set of planning activities, executing activities, and controlling activities. The length of these iterations corresponds directly to the granularity of control necessary to keep the project on track.
An Agile team using 1-week iterations will perform each of the following project management activities each week:
- Evaluate the functionality completed to date by demonstrating it to key stakeholders
- Identify any potential scope changes and create appropriate work package descriptions to represent those changes
- Estimate all new “candidate work packages” and re-estimate any work packages that have not yet been completed
- Rebuild the project plan going forward to match available resources, incorporating the updated estimates and any scope changes
- Authorize specific work packages for the next iteration
The team working together with the key stakeholders executes these project management activities. Project management becomes part of the way work gets done, instead of a tracking system that the project manager uses to characterize the progress of a project.
The vast majority of Agile teams have a surprisingly formal work authorization process. While each iteration’s project planning processes focus on the overall project outcome, specific work packages are authorized for the iteration’s limited period of execution activities.
Exhibit 2--Work Authorization Board
Many Agile teams use a visual work authorization board. The descriptions of the authorized work packages are hung on a bulletin board near the team doing the work. Sometimes these descriptions are simply hand-written on index cards. As work packages are completed, their completed status is indicated visually by moving the card to a new location on the board, or the card is marked in some manner such as affixing a sticky dot to it. This formal, if somewhat low-tech, adoption of work authorization has several interesting implications:
- Team members working on completion of scope stay focused on a limited set of high-priority items.
- All stakeholders know what portion of the plan has been committed (authorized) and what part of the plan could still be adapted in some way to better meet the project’s objectives.
- There is lowered risk of new scope being added accidentally, because there is an obvious and positive mechanism for considering changes, the next iteration’s planning/work-authorization cycle.
This process establishes a consistent understanding between all stakeholders regarding what potential scope changes will impact already completed work, and what planned work is not yet authorized and therefore subject to future changes.
Work Breakdown Structure
The WBS is a fundamental building block of most project management practices, as it answers the question of “what are we doing?” When teaching the concept of work breakdown structures it is common for an instructor to hand stacks of sticky notes or index cards to small work groups. The groups then break a commonly understood deliverable, such as a house, a bike, or another common object, into smaller and smaller component pieces using decomposition. This exercise is often used to help illustrate the important differences between a project plan based on a deliverable-oriented WBS and a project plan based on a task-based activity sequence diagram.
In many projects, the scope definition is captured in a large specifications document, while the project planning focuses on resources and activities. When project planning focuses on activities instead of component deliverables, the risk for scope misunderstandings increases. How many times have you seen a scope change made to a project, or even a formal change order accepted, that resulted in no changes to the project plan? Agile teams recognize this challenge and address it by capturing project specifications in the form of a WBS, often working as a cross-functional team using sticky notes or index cards. After each deliverable-oriented work package is estimated, any work package that is too large to fit in a single iteration is then decomposed into smaller deliverable-oriented work packages. Most agile teams also work hard to enforce the discipline that work packages are independent from one another. This discipline, along with work authorization, is what gives Agile its name.
The work packages created by an Agile team become fundamental to all other activities. It would be very unusual to spend a day with team members on an Agile team and not see everyone actively reading, discussing, and making notes on the agreed-upon work package definitions.
Agile teams focus considerable effort on functionally decomposing their project into deliverable-oriented functionality in the form of work packages. The individual activities such as data-base design, writing code, and quality assurance testing do not appear within the WBS, as these activities are not independent elements of functional scope. The resulting improvements to the work package descriptions and the project plan upon which they are based ultimately create a project plan that facilitates effective change control in a manner that directly affects project planning and work authorization.
Agile teams recognize that there are many potential barriers to communications, and that communications is a critical component of project success. As such, Agile teams look for every possible advantage for improving their communications plan. The most visible aspect of most Agile teams is their absolute insistence on collocation for the key members of the project team.
Exhibit 3--Collocated Work Environment
All too often, organizations are prepared to spend tens-of-thousands of dollars on collaboration software to improve project outcomes, but are unwilling to take on the logistical challenges of collocating teams. Collocation also will typically create a noisy environment in which unplanned collaborations will occur all day long. Likewise, Agile team recognize that a status report elaborating on a percentage complete metric seldom has deep meaning to project sponsors. Or worse, the metric is not trusted. Agile teams choose to measure output by regularly producing small pieces of working and demonstrable functionality each iterative cycle. This functionality is demonstrated to key stakeholders in order to communicate progress as well as to solicit feedback.
Myths about Agile are pervasive. Listed below is a sampling of typical myths and the realities behind those myths.
Myth #1: Agile development processes eliminate the need for Quality Assurance and Project Management.
Many developer-centric software teams have implemented Agile and feel that they have eliminated the need for quality assurance and project management specialists. It is even possible that in some cases this might be true. However, in the vast majority of cases, it would be more appropriate to say that many of the traditional quality assurance tasks and many of the traditional project management tasks have been distributed throughout the whole team by the nature of the process. This change in process actually creates more time for these valuable specialists to focus on the value-added components of their discipline. For example, the Quality Assurance specialist can spend less time performing rote testing and more time evaluating customer satisfaction and process improvements. Likewise, the project management specialist can spend less time performing project administration and more time eliminating external barriers as well as facilitating stakeholder participation.
Myth #2: Agile teams plan only one week of work at a time.
Agile teams rebuild their project plan on a regular basis. Some teams rebuild their project plan once per week. This plan extends beyond the upcoming week, and the planning horizon for each planning session extends as far as possible given the team’s current understanding of requirements. What makes planning in Agile so different is that planning is not postponed until we have better data. Instead, the team builds the best plan it can, given the data it has, and at regularly scheduled small intervals, a new plan is created with better data. Agile teams then use this improving project plan to predict the functionality they can complete within a fixed schedule and/or fixed budget.
Myth #3: Agile teams refuse to use Microsoft Project and to populate executive dashboards.
The tools of project management should not be confused with the software used by some organizations to implement those tools. It might be helpful to recall that large projects were managed long before computers were available to assist with these types of tasks. In any case, computers are not required for a team to be able to build an effective WBS. In some ways, it is easier to build an effective WBS using index cards or sticky notes, because the technology does not distract from the project management task being performed.
Many Agile teams exist within large organizations that have enterprise management and reporting systems. In these cases, the project manager on those teams plans and tracks progress on the project using the tools appropriate for the team’s Agile methodology and then copies the appropriate data into the enterprise reporting system on a weekly or daily basis as appropriate for the organization’s needs.
Although some unenlightened Agile teams may claim that they no longer need project management, quite the opposite is true. High-performing Agile teams have built their daily work processes around the core project management concepts that are documented in the PMBOK Guide (PMI, 2004). Project managers who work on Agile teams typically find that their role shifts from administration of project status reports and other artifacts to a role that facilitates interactions between team members. Agile teams place an emphasis on people working together to solve problems collaboratively to produce desirable outcomes, which ultimately is what good project management is all about.
Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK®Guide) Third edition. Newtown Square, PA: Project Management Institute.
© 2008, Clement James Goebel III
Originally published as a part of 2008 PMI Global Congress Proceedings – Denver, Colorado