Have you been questioned recently about agile or scrum project management? Are you looking for a way to handle projects with dynamic, changing scope but with fixed dates and costs? Has the launch of the new PMI Agile Community of Practice piqued your interest?
In this powerful paper, you will learn why agile has become so quickly entrenched in major companies like Qualcomm and the European giant, Tele Atlas! Agile project management is a skill set that is rapidly growing and is in high demand among employers. PMI has responded to this demand by launching a new agile method to support practitioners of this discipline, which means that agile project management is a skill set you need to acquire!
The Biggest Key to Project Management Success
Capture and Control All Significant Information
The key to success for project managers, in a nutshell, is to capture and control all significant information when it first appears and before it is too late! There is no such thing as “just in time” information for a project manager. The sooner a project manager becomes aware of significant information, the more options he or she has for responding to that information. Responding to changes late in a project is far more difficult, risky, and expensive than responding to the same challenge while there is still plenty of time.
The challenge can be summarized in three major variables. First, information comes to the project manager from all directions—customers, managers, and the project team, to name a few. Second, information often comes from stakeholders with unclear ideas and non-technical backgrounds. Many times these stakeholders suffer from IKIWISI (I’ll Know It When I See It) syndrome, which means they can only accurately tell the project manager what they want after they see what they have received. And third, it is expensive to “refine” the information that has been provided into a form that is useful for completing the project successfully.
Mapping Agile to A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
In the real world of project management, whether it is being executed with “traditional” methods or “agile” methods, many activities are happening at once because execution is iterative on so many levels. This reality creates significant challenges because of the limits of written communication for knowledge transfer of complex subject matter. Although that limit is undeniable, we will not let it be an excuse for anything less than robust content here.
Understanding the Vocabulary
When I ask students in my seminars, “Did you find the vocabulary in the PMBOK® Guide natural, intuitive, and easy to understand when you first started using it and preparing for the PMP exam?” it usually draws howls of laughter. Most of us can remember our mighty struggles to get comfortable with, and eventually master, the lexicon of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute, 2008). So, based on our experience with the PMBOK® Guide, it should come as no surprise that the vocabulary—the lexicon—of agile project management seems so strange.
Let’s take a look at two major facets of agile project management: the processes and the people.
Work Breakdown Structure
In the “traditional” world of project management, the work breakdown structure is a fundamental tool. The generally accepted convention is that information is aggregated into broad categories (i.e., “buckets”) with few details at the highest level progressively decomposed or elaborated at lower levels; the same is true for agile. In the “traditional” world, the generally accepted naming convention for those levels, from highest to lowest, is objective, phase, work package, activity, and task. In the agile world, the comparable levels would be vision (or product), epic, saga, user story, and task.
In both worlds of project management the designations associated with grouping or categorizing information are artificial constructs intended to help all stakeholders—the project manager and team—visualize how content or ideas are related to one another. Within the agile world there are several variations on this naming convention but this one is widely accepted and recognized.
Gantt Charts and Release Plans
In the “traditional” world of project management, the Gantt chart is a fundamental tool. The generally accepted convention for Gantt charts is deliverables, milestones, and phase gates; the same is true for agile, in which the concepts are similar, only the vocabulary is different. In agile, we refer to potentially shippable increments (deliverables), Sprint reviews (milestone approval; go-no), and release packages (phase gate). The exhibits below illustrate this similarity.
One significant difference between the traditional use of a project schedule, as displayed in a Gantt chart and a release plan, as typically used in an agile project management method, is the timing of estimating activities. In traditional approaches, a large investment of resources occurs early in the process to define detailed specifications, develop estimates based on those specifications, and create a schedule from those estimates. One challenge of this approach is that all that effort and consequent time and cost occur when the customer knows the least about what the ideal solution should be like. It is paramount to filing a flight plan to travel from San Diego to New York without significant information on the weather systems developing along the route. And to make matters worse, the current system is set up so that it is like penalizing the pilot for making in-flight adjustments as better information becomes available.
Alternatively, the agile approach consciously accepts the fact that environment variables (not the least of which is customer learning) always act upon the project in unexpected ways. Therefore, it integrates the expectation that the project manager (i.e., the pilot in our analogy) adds important value by making in-flight adjustments. The consequence of this basic understanding is that the expensive activity of defining detailed specifications and developing work-level estimates based on those specifications is not done until we have a high probability expectation that those features will actually be built as part of the solution. In practice, this means that creating a schedule is done by using both quantitative and comparative estimating tools. We use quantitative estimating for those activities that have a high probability of occurring and therefore are on the short-term horizon, whether that be 60, 90, or 180 days. Beyond that horizon, for those activities that do not yet have a high probability of occurring, we use comparative estimating, which is far less expensive and yet produces a statistically reliable, research-validated forecast for scheduling. We will explain this in detail below, but first we need to ask an important question to establish what our true expectation baselines are for comparing traditional and agile methods.
How Successful is the Current Model of Scheduling and Estimating?
According to the Standish Group’s CHAOS Summary 2009 Report( Standish Group, 2009), there has been a marked decrease in project success rates. With “successful” projects defined as delivered on time, on budget, and with the required features, results show only 32% qualified. With “challenged” projects defined as late, over budget, and/or missing required features, results show fully 44% qualified. With “failed” projects defined as cancelled prior to completion or delivered and never used, results showed 24% qualified. And, of course, a decrease in success rates can be traced directly back to failures in scheduling and estimating. These results mean that our current baseline is a status quo of high risk, not one of high success. And it gets worse!
Another disturbing trend was underscored in a report by Jim Johnson, Chairman, Standish Group International, Inc., at the XP2002 conference in Sardinia, Italy. (Johnson, 2002) The study results reflected the percentage of delivered features that were actually used by the customers, and the categories used were always, often, sometimes, rarely, and never. The customers said that 7% of features were always being used, 13% were being used often, 16% were used sometimes, 19% were used rarely, and 45% were never used. This means that almost two thirds (i.e., 64%) of the features delivered were rarely or never used.
Waste is any process output that does not create value. So, all that time and money spent developing detailed specifications and estimates can only be described as waste; but the real question is: Is there a better option, way, or process that produces better results? Agile is the solution!
Applying the Theory of Relativity
Using both quantitative and comparative estimating tools is the key to affordable, sustainable, and accurate estimating. This understanding comes from the first two universal laws of estimating. Law number one says, “Accurate estimates are expensive, don’t waste them!” Law number two says, “Everyone must agree to the value of imprecise estimates.” These truths apply in both traditional and agile environments. In agile project management, we use comparative tools for planning and scheduling and quantitative tools for task estimating and management.
Universal law number one warns us to avoid estimating anything that may not be developed or needed because it controls costs and conserves budget. Comparative estimating focuses on quickly (i.e., inexpensively) establishing the relative size of each component of the deliverables. Because each member of the team is a subject matter expert, he or she can quickly resolve whether a particular component is small, medium, or large. He or she can also quickly identify the scale implied by the small, medium, and large designations; for instance, small may be 1 to 2 days, medium may be 1 week, and large may be 2 to 3 weeks. Using that information, plus the prioritization of each feature or component, we can create a working schedule (i.e., release plan). The working schedule places deliverables into “time buckets” based on the combination of their priority and their size.
For example, if we define our time buckets as “months” (i.e., 4 weeks) and we have a 5-person team, then the team can produce 20-person weeks of output per reporting period (i.e., 5 people x 4 weeks = 20 person-weeks). If, for our example, we assume our project includes 10 deliverables, named task 1 through task 10, where number one is the highest priority and ten is the lowest priority, and the following comparative sizes:
|Task 1||Medium||10 person-weeks|
|Task 2||Small||5 person-weeks|
|Task 3||Medium||10 person-weeks|
|Task 4||Large||15 person-weeks|
|Task 5||Small||5 person-weeks|
|Task 6||Small||5 person-weeks|
|Task 7||Large||15 person-weeks|
|Task 8||Medium||10 person-weeks|
|Task 9||Small||5 person-weeks|
|Task 10||Large||15 person-weeks|
Then, the working schedule (i.e., release plan) for project would be:
|Month 1||Tasks 1, 2, and 5||(i.e., 10 + 5 + 5 = 20)|
|Month 2||Tasks 3, 6, and 9||(i.e., 10 + 5 + 5 = 20)|
|Month 3||Task 4||(i.e., 15)|
|Month 4||Task 7||(i.e., 15)|
|Month 5||Task 8||(i.e., 10)|
|Month 6||Task 10||(i.e., 15)|
Assuming the working schedule is acceptable, then we use the quantitative estimating tools (which are the same as those used in our current traditional model) to estimate the tasks for month 1 (or months 1 and 2) so we can begin on the highest priority and highest value work.
We do not spend expensive resources to estimate the tasks for months 5 or 6, because experience has demonstrated that at some point, the customer will either change what they want (i.e., how they define the solution) or they will realize that the highest value features have already been delivered (and therefore the cost-benefit ratio for the remaining features no longer makes sense) and will want to end the project because they are extremely pleased with the results, not because they are extremely dissatisfied! In this scenario, they will have gotten 75% or 80% of the value but only used 50% or 60% of their budget, so they feel like they have won the lottery!! But, I digress.
At the end of month one, we estimate month three, and so on. (Does this sound like traditional rolling wave planning to you?) We only apply resources to quantitative estimating when we will need that information to manage project execution. Prior to that point, we use comparative estimating (i.e., sizing) for planning and scheduling.
What is the Logical Foundation for Risk Management?
Before we can effectively discuss the differences in risk management using a traditional or an agile method to manage projects, we need to understand the logical, quantitative foundation in each environment. In the prior section we discussed the differences in the planning processes and as part of that discussion we indentified a fundamental difference in the timing of those activities. That timing is quantitatively different because the agile method uses comparative tools for scheduling and quantitative tools for estimating.
In the traditional method, a large investment is made to create detailed information far in advance of its actual usage. The timing of that approach induces a number of risks, such as customer uncertainty and unpredictable changes of external variables, which therefore must be tracked, analyzed, planned for, and responded to, when they materialize from risk to problem.
In the agile method, the investment in detailed information only occurs when the actual usage of that information becomes highly probable. The timing of that approach eliminates a number of risks, because the time window for materialization from risk to problem is reduced to the short cycle time employed to produce workable components of the solution (commonly referred to by agilists as “increments of potentially shippable product”).
The traditional method of project management has a quantitative foundation that is referred to as a defined process approach. That is, create a defined process for executing the project and then employ tools, such as a change control board, to resist change and constrain reality to the plan. The agile method has a quantitative foundation that is referred to as an empirical process approach, which is to collect empirical data while executing the project and then employ tools (e.g., short cycle times and customer feedback) to adjust the plan to the reality of the environment surrounding the plan.
What does that mean in practice? In practice, it means that the traditional method is best suited to any environment in which the project has a fixed, stable scope; in other words, the customer clearly knows and can articulate what they want, including dynamic dates and costs, so the delivery date and cost to develop the solution can both be flexible. One example of this type of project might be developing the targeting system for a nuclear weapon because it has a well-defined outcome and having it be positively 100% error-free absolutely outweighs any consideration of when it will be delivered or how much it will cost. In comparison, in practice, the agile method is best suited to any environment in which the project has a fixed delivery date and budget; in other words, it must be delivered on a certain date and must be within a given budget and a dynamic scope, so components of the solution can be prioritized by the value they provide, and the customer is flexible as long as the highest value components are delivered first in a fully functioning state. One example of this type of project might be delivering a complex scientific mission to the surface of Mars, as NASA does. The launch date and the budget are fixed, but each individual experiment has a priority within the mission package, so any particular experiment can be included or removed as the cost of preparing the higher priority experiments becomes known.
Directing Team Focus
One of the challenges in traditional project management is energizing a sense of urgency for a subject matter expert whose tasks occur early in a long project, such as month 3 of a 24-month project. The human tendency is to feel that there is plenty of time left because it is hard for humans to internalize how subsequent tasks are dependent on timely completion of predecessor tasks. It is precisely this tendency that PERT and CPM work to overcome. In the agile world, the combination of shorter iteration cycles and reporting, especially using burndown reports, work to overcome this obstacle.
In the agile method, the typical cycle for completing a working component of the solution, or a potentially shippable product, is four weeks. During that four-week period the team has a daily stand-up meeting where each member answers three key questions. The first question is, “What did you work on (since yesterday’s meeting)?” This allows the other team members to address any questions about synching up for a hand-off. The second question is, “What will you work on next?” This allows the team to address any questions about how task execution is being prioritized so bottlenecks can be identified and mitigated. And, the third question is, “Are there any impediments (preventing you from making progress)?” This allows the team lead—commonly called scrum master—to intervene as needed to ensure each team member can continue to make progress at a desirable rate.
This dual system of four-week cycle times and daily meetings help the team focus on making measurable progress in reasonable time. Instead of the traditional pattern of three or four months of vague or mediocre progress, followed by six or eight weeks of breakneck effort with overtime and weekends and the unavoidable mistakes and oversights that approach induces, we have a pattern in which every day or two team members ramp up their focus and effort in order to stay in synch with the rest of the team. And every four weeks we have any final push needed to prepare to deliver a potentially shippable product that will be presented to the customer for the acceptance, rejection, or adjustment.
In the agile method we are able to see progress on a daily basis, because the results of the stand-up meeting are memorialized in the burndown report.
In Exhibit 4, we see an example of a burndown report in which the total number of tasks identified rises for the first four days. We also see that the lowest bar represents tasks that have not started, the middle bar shows tasks that are in progress, and the top bar highlights tasks that are completed. This report provides a strong visual reinforcement of the probability of our team meeting its next deliverable date. Assuming the deliverable is linked to the milestones and phase gates in the release plan, then the team has early feedback on whether progress is realistically on track to achieving successful project completion.
Challenging Your Mindset
Differentiating Project Managers from Scrum Masters and Product Owners
Perhaps the most misunderstood and confusing concept in agile project management is mapping the role of a project manager in the traditional method to either a scrum master or product owner in the agile method, although it may not be as difficult as first perceived. In the traditional worldview, we generally have three common tiers: technical lead, project manager, and program manager, where the technical lead focuses on helping a team deliver a specific type of functionality, the project manager focuses on resource management, and the program manager focuses on solution viability and customer satisfaction. Of course, because these are artificially defined categories, their actual applications will vary from environment to environment.
In the agile worldview, we have a somewhat simplified view that is more rigorously employed. The scrum master, in a mature agile environment, is more closely associated with a traditional technical lead. The management style is facilitative not directive, but the focus is on delivery of a specific type of functionality, a potentially shippable product. The product owner (again, in a mature agile environment) is more closely associated with a traditional program manager. The management style is executive and facilitative, focused on the creation of business value as defined by the customer. The product owner speaks with the authority of a fiduciary agent for the customer or customer segment. However, it is important to recognize the importance of the caveat about a mature agile environment, because most organizations are not in a state that could be described as mature in agile practices.
The absence of agile process maturity presents a unique challenge and opportunity for those brave souls struggling to bring agile to life in their organizations. While the organization is beginning its journey toward agility, there is a crucial need for leaders with the capacity to consciously and confidently move back and forth between the two roles. Those leaders also need to be able to articulate the value of agile to the organization, provide broad-based training (either themselves or by carefully selected professionals) to help co-workers, both up and down the chain of command, understand their roles and model the correct behavior in each role.
In Andy Crowe’s insightful book (2006) , Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not, there were two key insights, among many others, that help us understand the difference between project managers and scrum masters or product owners. First, he asserts that alpha project managers (the top 2%) do twice as much planning as the average project manager. Second, he notes that alpha project managers are much better communicators. Linking those two ideas, we see that project managers who plan well are true experts about their projects, which makes them more confident communicators. So, planning that is done well, whether in a traditional or agile method enables the opportunity for you to become an alpha project manager.
So, in the end, achieving agile project management mastery quickly comes down to challenging your mindset! Can you apply an empirical process that focuses on delivering prioritized business value? Can you integrate process steps that create accountability through “inch-stones” instead of milestones? Can you embrace and master facilitated planning as your leadership style? Agile requires all three. Developing your capacity to do all three will transform you into an alpha project manager, with all the rewards that come along with those skills.
It is reputed that Henry Ford once said, “Thinking is the hardest work there is, that is why so few people do it!” We would add that planning is the hardest thinking there is, which is why so few project managers do it. Perhaps part of the power of agile is that it does not require that all that hard thinking and planning to occur up front in a relative vacuum of important information. We hope that you will embrace it, rise to the challenge, and we welcome any opportunity to support you in your quest!!