An Introduction to Agile Project Management

An Introduction to Agile Project Management 
Copyright image to invensislearning.com

OVER THE PAST 10 TO 15 YEARS, there has been a rapid and dramatic adoption of agile methodologies:

1-Project Management Institute (PMI)® studies concluded that from 2008 to 2013, the use of agile practices tripled

2-According to a 2013 survey conducted by VersionOne:

• 88% of the respondents say that their organizations are practicing agile development, up from 84% in 2012 and 80% in 2011.
• Over half of the respondents (52%) are using agile software to manage the majority of their projects.
• 88% say that they are at least “knowledgeable” about agile software development techniques, up 7% from the previous year.

3-This trend has been going on for some time. As early as 2007, a Forrester survey reported

• “26% are already using agile and an additional 42% are aware.” 
• “Adoption of agile increased 56% from 17% in 2006, to 26% in 2007.” 
• “Awareness increased 45% from 29% in 2006, to 42% in 2007.”

These statistics indicate that agile is not a fad, it is having a significant impact on the way projects are managed, and it’s definitely here to stay. This trend has a significant impact on the career direction of project managers who have come from a traditional, plan-driven project management background since there is no formal role for a project manager at the team level in an agile project.

The Chams In Project Management Philosophies

In spite of this rapid and sustained proliferation of agile, there is still a fairly large chasm between the agile and traditional project management communities:

• There has been only a limited amount of progress on developing a more integrated approach to project management that embraces both agile and traditional plan-driven project management principles and practices.
• Many people seem to see agile and project management principles and practices as competitive approaches that are in conflict with each other, and they are essentially treated as two separate and independent domains of knowledge.
• Considerable polarization between these two communities is based in some part on myths, stereotypes, and misconceptions about what agile and project management is.

A major goal of this Article and other some is to help project managers understand the impact of agile on the project management profession and to broaden and expand their project management skills as needed to develop a more integrated approach to adapt to this new environment.

A lot of the polarization that exists between the agile and traditional project management communities is rooted in some well-established stereotypes of what a project manager is that are based on how typical projects have been managed in the past. 

The role of a project manager has been so strongly associated with someone who plans and manages projects using traditional, plan-driven project management approaches that many people can’t conceive of any other image of a project manager. 

It’s time to develop a new vision of what an agile project manager is that goes beyond all of those traditional stereotypes and fully integrates agile within the overall portfolio of project management principles and practices.

It feels very similar to an evolution that took place when I worked in the quality management profession in the early 1990s. Up until that time, the primary emphasis in quality management had been on quality control, and inspection and the image of a quality manager were heavily based on that role:

• The predominant quality management approach was based on final inspection of products prior to shipping them to the customer and rejecting any that didn’t meet quality standards. It’s easy to see how that approach was inefficient, because it resulted in a lot of unnecessary rework to correct problems after the fact, and it also wasn’t that effective because any inspection approach is based on sampling, and it is impractical to do a 100% sample. For that reason, it can result in mediocre quality.
• A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects and build quality into the inherent design of the products. That didn’t mean that the prior emphasis on quality control and inspection was obsolete and eliminated; it was just not the only way to manage quality and wasn’t the most effective approach in all situations.

That was a gut-wrenching change for many in the quality management profession—instead of being in control of quality and being the gatekeeper with the inspection process, a good quality manager needed to become more of a coach and a consultant to influence others to build quality into the way they did their work.

This changed the nature of the work dramatically for many in the quality management profession and eliminated a number of traditional quality management roles that were based on the old quality control and inspection approach. The similarity to the changes going on in the project management profession should be apparent:

• To be successful in more uncertain environments, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project and integrate quality into the process rather than relying on final acceptance testing at the end of the project to validate the product that is being produced.
• They also need to give up some of the control that has become associated with the project management profession—in some cases, they may need to become more of a coach and a consultant to influence others rather than being in absolute control of a project.

This can dramatically change the role of a project manager. In some situations, the role of a project manager as we’ve known it may no longer exist. 

For example, at a team level in an agile project, you probably won’t find anyone with a title of project manager because the project management functions have been absorbed into other roles and are done very differently. 

That doesn’t mean that project management is no longer important, but it may cause us to dramatically rethink what project management is in a much broader context than the way we might have thought about it in the past.

The Evaluation of Agile and Waterfall 

You will often hear people make a comparison between agile and waterfall. Many of those discussions are polarized and position them as competitive approaches. Here’s an example:

According to the 2012 CHAOS report, Agile succeeds three times more often than Waterfall. Because the use of Agile methodologies helps companies work more efficiently and deliver winning results, Agile adoption is constantly increasing.

 While that statement is generally true, it’s an oversimplification. There are at least two problems with that kind of statement:

• It makes it sound like there are only two binary, mutually exclusive choices, agile and waterfall.
• The meaning of the words agile and waterfall are typically not well-defined and are used very loosely.

For those reasons, I prefer to avoid comparing agile to waterfall because it tends to be a very polarized discussion—I prefer to take a more objective approach that is based on a comparison between a plan-driven and an adaptive approach to project management. So let’s first define both agile and waterfall, and then compare the two approaches.

Definition of waterfall

The word waterfall actually has a very specific meaning, but that’s often not how the word is really used:

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. 
Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. 
It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

Another aspect to the waterfall model is that it is plan-driven; it attempts to define and document detailed requirements and a plan for the entire project prior to starting the project. When someone makes a statement comparing waterfall to agile, the word waterfall is often used very loosely to refer to any kind of plan-driven methodology, and that’s not really a very accurate and meaningful comparison. In some other comparisons like this, the word waterfall refers to a general style of project management that obsessively emphasizes predictability and control over agility, and that’s just bad project management.

Definition of agile

The meaning of the word agile in this kind of comparison is also somewhat elusive because it has taken on some very strong connotations in actual usage. At a project level, at least in the United States, the word agile has taken on a specific connotation associated with using the Scrum methodology on software development projects:

Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrimmage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. Scrum employs real-time decision-making processes based on actual events and information.

Comparison of plan-driven and adaptive approaches

Traditional, plan-driven project management is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent prior to implementing the project. 
However, plan-driven is a relative term, and you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all.

In contrast, an adaptive style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and recognizes that the requirements and plan for the project are expected to evolve as the project progresses. Adaptive is also a relative term; you won’t find many projects that have no plan whatsoever of how the project will be done.

The important point is that the terms plan-driven and adaptive: 
are relative—they are not discrete, binary, mutually exclusive alternatives. They should imply a continuous range of approaches with different levels of upfront planning.

Saying “Agile is better than waterfall,” is like saying, “A car is better than a boat.” Agile and waterfall are different kinds of methodologies designed for different kinds of projects. 

The problem is not so much that waterfall or agile are inherently good or bad; the problem comes about when those methodologies are misused and people try to use a single methodology (whatever it might be) for all projects. 

Using a “one size fits all” strategy to applying either waterfall (plan-driven) or agile (adaptive) approaches to all projects is not likely to yield optimum results. 

In my opinion, being able to objectively understand the difference between a plan-driven approach and a more adaptive approach—as well as the principles behind those approaches at a deeper level—is probably one of the most important skills an agile project manager needs to have. 

An agile project manager needs to recognize the following:

• There is a broad range of alternative approaches between being plan-driven and being adaptive. The agile project manager must choose the right level of upfront planning to be applied to a project, based on the level of uncertainty and other factors in the project.
• It takes some skill to make the right choice. There is nothing inherently wrong with either of those approaches (adaptive or plan-driven). The problem comes about when people try to force-fit a project into one of these approaches rather than selecting and tailoring the approach to fit the project. For example, if I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be dismal.

The important point is that a heavily plan-driven approach (what some loosely refer to as waterfall) is not the only way to successfully manage a project. In many projects, a good approach is to use an adaptive approach to start the design effort without fully-defined and detailed requirements and perhaps prototype something quickly. Then user feedback can be added to further refine the design as the project progresses. With a more adaptive approach:

• The elements of the approach are much more concurrent than sequential. Instead of doing the entire design and then turning it over to quality assurance (QA) for testing, the design is done in small chunks called iterations or sprints that are typically two to four weeks long. During that time, developers and testers work collaboratively to design and test the software during each sprint. 
• The customer also provides detailed inputs on the design during each sprint. The customer accepts the results of each sprint at the end of each two- to four-week period rather than waiting for user acceptance testing (UAT) at the end of the project. That has the advantage of finding and resolving any problems quickly and early in the project.

One primary advantage of a more adaptive approach is that the project startup is accelerated because less time is spent upfront in attempting to define detailed requirements. In addition, engaging the user more directly in the design process is more likely to produce an outcome that provides the necessary business value and really meets the user needs. 

An adaptive approach maximizes the business value to the customer because the customer is directly engaged with the design team as the project progresses, but it is worse for predictability and control because the customer can make changes as the project progresses. 

In an agile project, change is the norm rather than the exception. However, this is not an “all-or-nothing” proposition to have total control or no control at all. There are many ways to achieve the right balance of control versus agility. 

For example, prior to the start of a project, the high-level requirements might be defined and stabilized, and then only the more detailed requirements need to be further elaborated as the project progresses.

The Evaluation of the Project Management Profession

Many of the techniques associated with project management that are in use today haven’t changed significantly since the 1950s and 1960s. I believe that we are on the verge of a major transformation of the project management profession that will cause us to redefine project management in a much broader context that includes both agile and traditional, plan-driven project management.

Agile Project Management Benefits

I am a strong believer in agile, and there are some very significant benefits of an agile approach in many situations. However, many proponents of agile oversell the benefits and sometimes position agile as a panacea that should be used for all projects. 
The real benefit to a typical project manager of developing an agile project management approach is not in throwing away any notion of using a plan-driven approach, converting to agile, and using a totally agile approach for all projects. 
Rather, the benefit results from recognizing that a traditional, plan-driven approach is not the best way to manage all projects and thus learning to blend adaptive/agile and plan-driven principles and practices in the right proportions to fit a given situation.

Here are five specific benefits of developing an agile project management approach:

1. Increased focus on business outcomes. Many people think that the primary benefit of an agile project is just getting it done faster, but that is not always the case. The primary emphasis in an agile project is really to deliver value in the form of very successful business outcomes by taking an adaptive approach to maximize the value that is delivered. That doesn’t always result in the fastest delivery times. In some cases, it may require some experimentation and trial-and-error prototyping to find an optimum solution—that may or may not be the quickest way to get it done, but it should result in a better product in the end.
2. Reduced time to market. Time to market is, of course, an important consideration, and agile accomplishes that in a couple of ways
3. Higher productivity and lower costs. Agile can also result in higher productivity and lower costs by eliminating unnecessary overhead and bottlenecks and doing work concurrently rather than sequentially. 
4. Higher quality. A very important benefit of agile is higher quality. In a traditional waterfall project, quality is sequential and is often perceived as a separate effort that is the responsibility of the quality assurance (QA) department. The developers many times develop the software and then “toss it over the wall” to be tested by QA. In an agile project, the team, as a whole (which includes QA testers) jointly owns responsibility for building quality into the design of the products that they produce—it’s not someone else’s responsibility. The development effort is broken up into short iterations called sprints that are typically two to four weeks in length. There is an emphasis on producing a shippable product at the end of every sprint, which means that quality testing must be more integrated with development and cannot be put off indefinitely.
5. Organizational effectiveness. Finally, a very important benefit of agile is a more effective organization with higher morale

Reference: The Project MANAGER’S GUIDE TO MASTERING AGILE