What Are the Advantages and Disadvantages of Agile and Scrum?

I have often been asked “What are the advantages and disadvantages of Agile/Scrum?” so I thought it would be useful to summarize what I believe are the most important advantages and disadvantages.

Advantages and Disadvantages of Agile/Scrum

Advantages of Agile/Scrum

1. Flexibility and Adaptivity

An Agile/Scrum approach is best-suited for a relatively uncertain environment. In that kind of environment:

  • It is very difficult, if not impossible, to accurately define the requirements and design for the solution in detail prior to the start of the project
  • Flexibility and adaptivity are essential to further define and elaborate the requirements and design of the solution as the project is in progress

2. Creativity and Innovation

In the highly competitive environment that we live in today, no one wants to buy average, run-of-the-mill products.  People expect a higher level of excellence and that requires creativity and innovation.  An Agile/Scrum approach emphasizes creativity and innovation to maximize the business value of the solution. An over-emphasis on planning and control tends to stifle creativity and innovation.

3. Time-to-Market

An Agile/Scrum approach typically results in faster time-to-market due to shorter startup times. An incremental development effort will also allow early delivery of at least a portion of the solution without the entire solution to be 100% complete

4. Lower Costs

An Agile/Scrum approach can lower the costs of a project in several ways:

  • Significantly reduced overhead resulting from reducing unnecessary documentation and control requirements
  • Higher productivity of the project team
  • Reduced “feature bloat” from using an incremental development effort and prioritizing the requirements. Using that approach, it will become apparent when the project begins to reach a point of diminishing returns where the incremental value of the features no longer exceeds the incremental development cost

5. Improved Quality

In an Agile/Scrum project, quality is an integral part of the development process rather than a sequential activity.  The developers know that quality is not “someone else’s responsibility”

6. Customer Satisfaction

An Agile/Scrum approach should result in higher customer satisfaction and more effective solutions because the customer is heavily involved in providing feedback and inputs throughout the development process

7. Employee Satisfaction

An Agile/Scrum approach should also result in higher employee satisfaction from all employees that are engaged in the effort because they are much more engaged to take responsibility for their own work as part of an empowered team

8. Organizational Synergy

An Agile/Scrum approach can improve organizational synergy by breaking down organizational barriers and developing a spirit of trust and partnership around organizational goals.

Disadvantages of Agile/Scrum

1. Training and Skill Required

An Agile/Scrum approach requires a considerable amount of training and skill to implement successfully.  Many project teams don’t fully understand the need for training and skill or don’t want to put the effort into it. They attempt to do Agile/Scrum mechanically without fully understanding the principles behind it and that is typically not very effective

2. Organizational Transformation

An Agile/Scrum approach may also require some level of organizational transformation to make it successful.  It require the business users to work collaboratively with the development team in a spirit of trust and partnership.  That may require breaking down some organizational barriers that make that difficult or impossible to do

3. Scalability

It can be difficult to scale an Agile/Scrum approach to large, complex projects.  There are some models for doing that (Scrum-of-Scrums, LeSS, and SAFe are examples) but none of those are a cookbook solution that are easy to implement.

4. Integration with Project/Program Management

An Agile/Scrum approach may not be totally appropriate for projects that require a more plan-driven approach to achieve some level of predictability. However, there are many ways to create a hybrid approach that blends a traditional plan-driven approach and an Agile/Scrum approach in the right proportions to fit the situation

Overall Summary

Agile is not a “silver bullet” and it is not a solution to every problem you might have. However, if Agile is applied intelligently in the right situations, it has huge advantages and the advantages can easily outweigh the disadvantages.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What Is Distributed Project Management? Why Does it Make Sense?

“Distributed Project Management” is a new approach to project management.   Here’s a brief overview of what it is all about.

What is Distributed Project Management?

“Distributed Project Management” is very important to help people see the relationship of “project management” and Agile in a very fresh new perspective.  It has the potential to redefine many of the heavily-ingrained notions that we have about what “project management” is.

What Is Distributed Project Management?

There are a number of people in the Agile community that believe that “project management” is not consistent with Agile. That opinion is based on:

  • A very narrow and stereotypical view of what project management is
  • An assumption that all project management functions are done by a single person called a “Project Manager”.

I think it is time to take a broader and more modern view of what “project management” is.

How Is Project Management Implemented in an Agile Team?

There is actually a lot of “project management” going on in an Agile environment, but many people won’t recognize it as “project management” because:

  1. It’s a different kind of project management, and
  2. The project management functions have been distributed among multiple people on the team

Let’s explore each of those areas individually.

1. It’s a Different Kind of “Project Management”

We need to broaden our thinking about what project management” is 

  • The traditional view is based heavily on planning and control to achieve predictability over project costs and schedules.  
  • A more modern and broader view of “project management” is based on delivering business value. 
    • That doesn’t mean that meeting cost and schedule goals is unimportant.
    • Achieving cost and schedule goals is only one component of business value and not necessarily the most important component. 
    • Creativity and innovation to maximize the value of the solution can be at least equally important

2. The Project Management Functions Have Been Distributed Among the Team

The functions that would normally be performed by someone called a “Project Manager” at the team level have been distributed among other members of the team.  As a result, you typically may not find anyone at the team level in an Agile project called a “Project Manager”.

In an Agile team, everyone on an Agile team has some kind of responsibility that might normally be performed by someone called a “Project Manager”:

RoleProject Management Function
Product Owner RoleThe Product Owner comes closest to the overall responsibilities of a project manager. However, the Product Owner role actually goes beyond a project management role. The Product Owner is expected to:
  • Take overall responsibility for the success or failure of the project
  • Make any decisions or trade-offs that might be needed to meet the project goals
Developer RoleIn an Agile environment, developers actually have responsibilities that might normally be done by a “Project Manager”. Developers are expected to:
  • Take responsibility for planning and completing the tasks that they are responsible for
  • Following through to meet commitments that they have made
  • Reporting progress and coordinating their work with other members of the team as necessary to produce an overall result
Scrum Master RoleThe Scrum Master also has responsibilities that might normally be performed by a Project Manager. The Scrum Master is expected to:
  • Facilitate the work of the team and team meetings
  • Coaching the team in Agile practices and
  • Removing any obstacles that might be impeding the team’s progress

A project manager in a traditional plan-driven environment would normally perform those functions.   A “Distributed Project Management” approach distributes these functions among multiple people.

Why Does Distributed Project Management Make Sense?

In an Agile environment:

  • Solutions can be much more complex and the level of uncertainty can be much higher. That makes it very difficult, if not impossible, to completely define a solution prior to the start of a project
  • That environment requires a much more flexible and adaptive approach

In that environment,

  • It is essential to further elaborate the requirements and the design of the solution as the project is in progress.
  • That calls for a very different approach to project management.

Distributing the project management functions among the different Agile team roles provides a much more dynamic approach:

  • Instead of centralized control where all decisions are made by a project manager,
  • Decision-making is more decentralized among the various roles on an Agile team
    • The team, as a whole, is self-organizing and empowered
    • That approach is very well-suited for an environment with a high level of uncertainty

Overall Summary

Distributed Project Management is a new way of thinking about how to do project management:

  • Instead of the normal project management functions being performed by a single person called a “Project Manager”
  • Those functions may be distributed among other roles

This approach may be threatening to many traditional project managers because, in many cases,

  • It could eliminate the role of a project manager at the team level in an Agile project, and
  • It also could require a significant adaptation for many project managers who are used to being in control of a project

For more on that check out this article on The Future of Project Management:

For the project management profession to continue to thrive, we need to recognize this fundamental shift in thinking and develop a broader vision of what “project management” is.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

How Do You Choose the Best Methodology for a Project?

I often see questions on “How do you choose the best methodology for a project?”

Choose the Best Methodology for a project

Is There a Best Methodology for a Project?

I don’t think that there is one single “best” methodology for a project that works for all projects.  A lot of people make the mistake of force-fitting a project to some standard methodology.

Traditional Plan-driven Approach (“Waterfall”)

Some project managers will try to use a traditional plan-driven methodology for a project (what many people loosely call “Waterfall”):

  • It may be the only project management approach that they know.
  • It has also been widely-accepted as the only way to do project management

Force-fitting a Project to a Methodology

Many other people have the misconception that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”. As a result, they will attempt to force-fit a project to one of those extremes

Fit the Methodology to the Project

The “best” approach is to go in the other direction and fit the methodology to the nature of the project. 

  • That takes more skill but it definitely can be done
  • You should also recognize that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”
  • There is a whole spectrum of different approaches ranging from heavily plan-driven at one extreme to heavily adaptive (or Agile) at the other extreme
Range of Agility

Factors to Consider

There are a number of factors that influence the selection of the best approach for a particular project:

1. Level of Uncertainty

First and probably the most significant factor in choosing an approach, is the level of uncertainty in the project. A project with a high level of uncertainty would be best-suited for a more adaptive (Agile) approach. Attempting to force-fit such a project to a traditional plan-driven project management approach could be disastrous.

  • It would force you to make a lot of assumptions to try to resolve the uncertainty; and, in many cases, those assumptions may be wrong and require a lot of re-planning and possible re-work
  • The emphasis on planning and control in a traditional plan-driven project is not conducive to changes. That will make it difficult to maximize the value of the solution in an uncertain environment

2. Need for Creativity and Innovation

Next, in today’s competitive environment, creativity and innovation can be very important to create very competitive business solutions. An approach with a heavy emphasis on planning and control can stifle creativity and innovation.

3. Customer Relationship

Finally, managing customer expectations is probably one of the most critical aspects of any project.  If the results of a project are not consistent with customer expectations, the project will likely not be viewed as successful no matter how good you think it is.  The nature of the customer relationship can range between:

Contractual Style of Relationship

A contractual style of relationship is where there are very definite and well-defined customer expectations that must be met.  In this type of relationship, the customer may not take any responsibility for the success of the project.  The customer defines requirements and expects the project team to do whatever is necessary to meet those requirements. In this style of relationship, there is limited participation by the customer in the project

Naturally,  the contractual style of relationship is well-suited to a project with a relatively low level of uncertainty. It must be possible to define the customer’s requirements in some level of detail prior to the start of the project.  It would be much more difficult to make a contractual-style relationship work in a project with a high level of uncertainty.

Collaborative Style of Relationship

A collaborative style of relationship is where there is a shared responsibility for the success of the project. In this environment both the project team and the customer take an active role in defining the direction of the project as it is in progress

What’s the Right Style of Relationship?

Of course, the customer has to be amenable to whatever type of relationship you choose.  If the project has a high level of uncertainty, that would lean towards more of a collaborative relationship; however:

  • The customer has to be open to that kind of relationship for it to be successful. 
  • This is a big problem in many companies where it is difficult to break down organizational boundaries between organizations
  • It requires establishing truly collaborative relationships based on a spirit of shared responsibility, trust, and partnership.

3. Project Team Capabilities

The final major factor in selecting a project approach is, of course, the capabilities of the project team.   

  • An Agile approach requires a lot of training and skill and a hybrid Agile approach  can require even more training and skill. 
  • Naturally, it does not make any sense to choose an approach that the team is not capable of implementing.

Why Is Choosing the Best Methodology for a Project Important?

There are two major factors that require us to broaden the way we think about “project management” today:

  • Solutions tend to be much more complex and the level of uncertainty is much higher
  • Competitive pressures frequently require much higher levels of creativity and innovation

For those reasons, force-fitting all projects to a standardized plan-driven approach is not necessarily the best approach for all projects.

Overall Summary

Choosing the best methodology for a project can be a difficult thing to do. It is not necessarily a simple matter of choosing Agile or Waterfall. You have to fit the methodology to the nature of the project. A project should be focused on producing value for the customer and its very important to understand what “value” means to the customer:

  • First of all, meeting cost and schedule goals is only one component of value, and it may not be the most important component of value to the customer
  • Second, there have been many projects that have met their cost and schedule goals but failed to deliver an acceptable level of business value
  • Finally, “Value” can be a very elusive goal but, in any case, it’s what the customer thinks that “value” is that counts

There is no “best” process. Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. Both have advantages and disadvantages depending on the environment you’re in:

When Does an Agile Approach Work Best?

When does an Agile approach work best? An Agile model tends to work best in projects where:

  • There is a relatively high level of uncertainty and a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
  • Creativity and innovation are needed to maximize the business value of the solution

When Does a Plan-driven Approach Work Best?

When does a plan-driven approach work best? A traditional plan-driven model (what many people loosely call “Waterfall”)  tends to work best where:

  • There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
  • The organization is not really  well-prepared to implement an Agile approach and/or the project team is not trained in Agile

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

In addition, you may also be interested in the following articles related articles:

Agile Change Management – Why Is It important?

Why is Change Management for an Agile transformation so important? Implementing an Agile transformation can require a big shift in thinking and possibly also require changing a well-established corporate culture for many companies.  That is not an easy thing to do and it requires some skill and planning to do it successfully.

The Need for Change Management in an Agile Transformation

In general many companies need to move from an excessive emphasis on planning and control to a more flexible and adaptive approach with more emphasis on creativity and innovation in a very uncertain environment.  That requires:

  • Developing a spirit of trust and partnership among all parts of the organization at every level
  • Breaking down organizational barriers that might prevent a collaborative, cross-functional approach
  • Developing a clear, unifying vision for the organization that creates a common purpose that is well-aligned with the company’s business objectives

Why Is Change Management Difficult?

Those are not easy things to accomplish and creating lasting organizational change is difficult.  People resist change and will naturally revert back to the old, comfortable way of doing things if the change management effort is not successful.

Agile Change Management

Kotter’s Change Management Principles

The best source on this is John Kotter’s book “Leading Change”. Kotter identifies eight errors that companies make in change management initiatives:

1. Allowing Too Much Complacency

This probably could be better stated…it isn’t necessarily a matter of “allowing too much complacency”. The real issue is that if there isn’t a feeling of urgency for making a significant change, it will be difficult to get support for making the change.

2. Failing to Create a Sufficiently Powerful Guiding Coalition”

Overall leadership is extremely important – all the key leaders have to be on board with making a broad-based, cross-functional change and providing the guiding leadership to make it happen.

3. Underestimating the Power of Vision

A clear vision is needed for what the organization will look like after the change is complete. If there is no vision, it will be difficult to guide the change in the right direction.

4. Under-communicating the Vision

Major change is usually impossible unless most employees are willing to help, often to the point of making short-term sacrifices. But people will not make sacrifices, even if they are unhappy with the status quo, unless they think the potential benefits of change are attractive and unless they really believe that a transformation is possible.”

5. Permitting Obstacles to Block the New Vision

The important points that Kotter brings up are:

  • Implementation of any kind of major change requires action from a large number of people
  • New initiatives fail when employees, even though they embrace a new vision, feel dis empowered by huge obstacles in their paths
  • Occasionally, roadblocks are only in peoples’ heads – In many cases, the blockers are very real

6. Failing to Create Short-Term Wins

Many times the best approach is to not take on too much at once but focus on some short-term wins that show progress.

7. Declaring Victory Too Soon

  • People can be tempted to declare victory in a major change effort with the first major performance improvement
  • While celebrating a win is fine, any suggestion that the job is mostly done is generally a terrible mistake
  • Until changes sink down into the company culture(3-10 years) new approaches are fragile and subject to regression

8. Neglecting to Anchor Changes Firmly in the Corporate Culture

Culture and values are extremely important – if people are simply mechanically implementing the change without any real change in corporate culture and values to support it, the change may be somewhat fragile and not long-lasting.

Three Most Critical Principles

All eight of the issues that Kotter has defined are important, but from my experience, there are three that are most critical that most frequently derail an Agile transformation.  These are:

1. No Burning Platform

This is based on Kotter’s first error “Not Creating a Sense of Urgency”.  There needs to be something that creates some urgency about making a change because maintaining the current situation is very painful and untenable.The phrase “burning platform” originated with a fire on an oil-drilling platform off the coast of the United Kingdom some years ago.  The phrase can have several contexts –

  • One context was that there were serious safety issues with the platform that were not addressed until the platform caught fire because there didn’t seem to be a sufficiently urgent need to address them.

  • Another context was that once the platform was on fire, there was an urgent need for the employees to do something to save their own lives – staying on the platform at that point was an untenable situation.

2. No Vision for the Future

This is based on Kotter’s third error “Underestimating the Power of Vision”.  Taking the time to define a vision for an Agile transformation is extremely important – many people make the mistake of using a one-size-fits-all approach to force-fit a company to some kind of “textbook” model.The best approach is to fit the model to the company’s business and a pure, top-to-bottom Agile approach may or may not be the best fit.  It may require more of a hybrid approach to achieve that kind of alignment, at least in the short-term.

3. Failing to Show Short-term Progress

This is based on Kotter’s sixth error “Failing to create short-term wins”.  There are always naysayers and skeptics who will remain on the sidelines waiting to see if the change is likely to be successful before they jump on the bandwagon.  That is why it is important to get started and demonstrate progress as quickly as possible.  From an Agile perspective, it is important to set clearly-defined and measurable goals that show progress and regularly communicate that progress to everyone involved.

Overall Summary

Implementing Agile successfully at an enterprise-level many times requires a significant transformation. That can be a difficult thing to do and it requires some understanding of change management to do it successfully. It is actually very similar to a business process reengineering project.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is Agile? How Would You Define Agile? What Does Agile Mean?

How do you define Agile? I’ve seen a lot of discussions where people have attempted to answer the question of “What is Agile?” with very different answers. 

Define Agile

Do You Really Mean Scrum?

First, there’s a lot of confusion about Agile and Scrum. Scrum is so widely-used as an Agile approach that when many people say “Agile”, they’re really talking about Scrum.

  • Agile is a general philosophy
  • Scrum is a specific Agile approach

Check out this article on What Is Scrum? What Is Agile? for more on that.

Feeling the Elephant

I’m sure that you could find at least 100 definitions of what “Agile” is on the Internet. It’s like the old fable of “The Blind Men Feeling the Elephant”:

“It was six men of Indostan
    To learning much inclined,
Who went to see the Elephant
    (Though all of them were blind),
That each by observation
    Might satisfy his mind[18]”

Each man came away with a different opinion depending on which part of the elephant he touched:

“Each in his own opinion concludes that the elephant is like a wall, snake, spear, tree, fan or rope, depending upon where they had touched”

Different Views of Agile

The way people define Agile is somewhat similar.  Depending on which part you touch, you may come away with a different impression of what Agile is:

  • Many people will define Agile in terms of how it is done. For example, many people will say that it is defined by the Agile Manifesto.  Here are a couple of examples of that:

“Agile is a set of methods and frameworks that embody the principles  and values of the Agile Manifesto”

“Agile is a term used to describe approaches to software development emphasizing incremental delivery, team collaboration, continual planning, and continual learning. The term “Agile” was coined in 2001 in the Agile Manifesto.”

  • Some people will say that it is just a mindset or way of thinking.  Here’s an example of that.

“Being ‘Agile Is a mindset. It’s about finding the right thing to build, faster (and not just building things faster)”

  • Some people will define it by comparing it to “Waterfall” to tell you what it is not.  Here’s an example of that:

“Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.”

None of those definitions are incorrect, but it’s like “feeling the elephant”; they don’t really get to the real essence of what the “elephant” is, in my opinion.

How Do You Define Agile?

Personally, I like the definition that is published by the Agile Alliance:

“The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”

I think that is a better definition because it gets to what I consider the real essence of what Agile is.

“Agile is best suited for situations that have some level of uncertainty where creativity and innovation are important to maximize the business value of the solution as opposed to other situations with lower levels of uncertainty where planning and control to achieve predictability are more important.” (My own definition)

What Problems Does Agile Solve?

We should acknowledge that Agile is not a solution to every problem you might have. One way to define it is in terms of what problems it is useful for. 

  • If you accept that Agile is not a solution to every problem you might have, the first thing you would want to know is “what problems is it useful for?” 
  • You don’t need to get too far into the mechanics of how to do it until you’ve determined that it is a useful solution to the problem you’re trying to solve.

There is an interesting observation you might draw from this – people get very immersed in the mechanics of how to do Agile and that’s how they define it.  Isn’t it more important to know what problems it’s useful for solving before you get into the details of how to use it?

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

How Do You Apply Agile to Non-Software Projects? Agile Book Publishing

Many people have asked about “Applying Agile to non-software projects”.  I’ve done a lot of that myself in using an Agile book publishing approach for publishing five books. I’ve also used similar techniques in designing and developing numerous online training courses. I thought I would summarize some of the techniques I’ve learned from doing Agile Book Publishing over the years.

Agile Common-Sense Principles

Here are some common-sense principles I’ve learned from using an Agile book publishing approach for publishing five books:

1. Just Get Started

One of the most important principles I’ve learned is “just get started”.  When you’re faced with writing a book or developing a major online training course, it can be a daunting experience. Just getting started is sometimes the hardest part:

  • We’re not sure how the final result is going to come out
  • We’re not certain how the final result will be structured – what should come first, etc.
  • We don’t want to produce something that is going to be a failure

You have to stop worrying about all of that and just get started.  I think of an Agile book publishing effort like developing a fine art sculpture.  You start with a lump of clay and you just keep molding and shaping it until it becomes a work-of-art.

How Do You Apply Agile Techniques to Non-Software Projects?

If you never get started, it will remain just a lump of clay.

  • It takes some courage and confidence in yourself to do this.  You’ve got to have courage and confidence that if you just get started, that somehow the final result is going to come out OK if you keep working at it
  • It also takes patience and commitment because you may have to go through a large number of iterations to get something useful out of it.  You may even have to throw something completely away and start over again

2. Use an Incremental and Iterative Approach

Many people don’t understand the difference between the words “incremental” and “iterative”. An Agile book publishing approach involves both:

  • “Incremental” means that you break up a solution into pieces and develop one piece (increment) at a time
  • “Iterative” means that if you’re not sure what a given piece should be, you develop something and then continue to refine that piece until you meet the customer’s expectations

Both of those are important:

Incremental Approach

Using an incremental approach is very important.  In any large effort like writing a book or developing an online course, its best to break it up into “bite-sized pieces.  If you try to take on too much at once, you’ll never finish it.  The effort to write a book can easily take well over a year and it’s easy to get discouraged in that period of time that you will never finish if you don’t see progress in the work.

Iterative Approach

Taking an iterative approach is also important.  A close corollary to “Just Get Started” is “Don’t Expect Perfection”.  A major reason for not getting started sometimes is that we’re afraid to produce something that is less than perfect. 

  • We have to accept that whatever we produce on the first iteration is certainly not going to be perfect. The final result may not be perfect either. 
  • Get something done quickly and then continue to refine it as needed to meet customer expectations.
  • There’s also a saying in Agile that is used a lot called “just barely good enough”. 
  • We shouldn’t try to “gold-plate” or over-design something. It should satisfy the need to provide value to the customer and nothing more.  Keep it simple!

3. Know  Your Customers and Listen to Them

When I first started writing books, I had a lot of people who helped me.  I had a network of people on the Internet who provided me with lots of great feedback and inputs.  I would write a chapter or two of the book and put it out to my network for feedback and comments.  Part of doing that successfully is recognizing that you “don’t know what you don’t know”.  You have to be humble, listen to other people, and respect their needs and interests.  If you think that you know it all, you probably won’t be very successful.

In the online training I develop, I get lots of feedback and inputs from students and I listen to it and take action.  As a result of that feedback, I have continuously improved all of my courses.

4. Refactor Your Work As You Go Along

I’ve done a fair amount of software development in my career and I’ve learned a lot from it. 

  • I’ve learned the value of having clean and well-organized software because I have had to support a lot of the software I’ve developed
  • Organization and flow of the material is particularly important in books and online training as well
  • As a result, it is essential to take time to go back and clean-up your work as necessary as you go along
  • When I first write something, I get it done quickly but I may have to rewrite it and reorganize it 5-6 times before I’m satisfied with it

5. Work at a Sustainable Pace and Do a Little at a Time

When you’re doing a long project like writing a book, working at a sustainable pace is very important.  That is especially true if it requires a lot of creativity and innovation.

  • You can easily get burned out by trying to do too much too quickly and when that happens, your creativity can go downhill quickly. 
  • Sometimes you need to put it down, walk away from it for a while, and come back when you’re refreshed to start work again.

Agile Book Publishing – Overall Summary

I think all of this is just good, common-sense things to do – why do people have trouble doing this? 

  • I think many people think of Agile as Scrum and also think about doing it mechanically. They aren’t sure how they would go about applying a Scrum process to this kind of effort
  • Agile is not just Scrum – it is a way of thinking. We need to understand the principles behind Agile. Don’t just do it mechanically and “by-the-book”. Take the time to interpret how it applies to your current situation and adapt it as necessary

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

For another example of applying Agile to non-software projects, check out this article:

What Is the Relationship of Physics and Agile Project Management?

Physics and Agile Project Management

What can Physics teach us about Agile Project Management?   We can learn a lot from how the science of physics has evolved. I think there are a number of interesting similarities the way that Agile Project Management is evolving.

How Has the Science of Physics Evolved?

For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”.

What is Classical Physics?

“Classical physics is the physics of everyday phenomena of nature, those we can observe with our unaided senses. It deals primarily with mass, force and motion.

  • While its roots go back to the earliest times, to the Ancient Greeks such as Aristotle and Archimedes,
  • It later developed into a cohesive system with the contributions of Galileo, Kepler and Newton.
  • Classical physics achieved phenomenal success, as the Calculus of Newton and Leibniz gave it the tools to tackle even problems not imagined by its pioneers.”

How Has Classical Physics Evolved?

“Around 1900, give or take a decade, surprising new experimental evidence, primarily about atoms and molecules:

  • Showed us that these small-scale phenomena behave in ways not anticipated by classical theory
  • This ushered in a new era called “modern” physics.
  • New laws and methodology were developed to deal with the rapidly expanding experimental evidence.
  • Relativity and quantum mechanics added new tools to the study of nature.”

These did not make classical physics “wrong”, for the old laws were working just as they always had, within their limited scope—which was the study of large objects (not atomic scale ones) moving relatively slowly (not near the speed of light). “

“So classical physics is still the starting point for learning about physics, and constitutes the bulk of the material in most introductory textbooks.

Simanek, Donald E., What’s Physics All About?, https://www.lhup.edu/~dsimanek/ideas/allabout.htm

What Happened to Cause People to Rethink Classical Physics?

That notion of physics that was intended to define how the entire universe worked held together for a long time; however, serious weaknesses began to appear around the early 1900’s:

“By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena. There was clearly a lot of cleaning up to do, but it looked like a fairly mechanical job: turn the crank on the calculator until the results come out. Apart from a few niggling problems like those lines in the light emitted by gas discharges, and the apparent dependence of the mass of high-speed electrons on their velocity”

Slavin, Alan J., “A Brief History and Philosophy of Physics”, Trent University

How is This Transformation Related to Agile Project Management?

Classical Physics Is Analogous to Traditional Plan-driven Project Management

Classical Physics is analogous to traditional, plan-driven project management. Similar to the laws of classical physics:

  • The traditional, plan-driven project management approach has been widely accepted as the only way to do project management for a long time
  • The way traditional, plan-driven project management is done hasn’t changed significantly since the 1950’s and 1960’s
  • It assumes a very predictable view of the world where it was possible to completely define a project plan with a fairly high level of certainty prior to the start of a project

Recognizing the Limitations

Physicists recognized the limitations of Classical Physics just as we are beginning to recognize the limitations of traditional plan-driven project management. The table below shows a comparison of how these two areas have evolved:

PhysicsProject Management
For many years, physicists believed that a model of the universe could be completely predicted based on some relatively simple and well-defined laws of classical physicsFor a long time, we assumed that traditional plan-driven project management was the only way to do project management and that approach would work in any project
Beginning in the early 1900’s, modern physics began to evolve and the limitations in Classical Physics began to be much more apparentIn recent years, it is apparent that we are in a much more dynamic and more complex universe with much higher levels of uncertainty
In this new environment, Classical Physics still provides a foundation however, it is no longer a universal view of how the world worksIn today’s world, we are beginning to recognize that a traditional plan-driven approach to project management is not the only way to do project management and it doesn’t work well in a very uncertain environment

What Are the Limitations of Physics and Project Management?

Traditional, plan-driven project management (just like Classical Physics) will never be totally obsolete and will continue to be a foundation for many areas of project management:

“…classical physics retains considerable utility as an excellent approximation in most situations of practical interest. Neither relativity nor quantum theory is required to build bridges or design cellphone antennas.”

The never-ending conundrums of classical physics, Trent University

Limitations of Classical Physics

However, it is important to recognize the limitations that are inherent in a traditional, plan-driven project management approach. Experienced physicists have learned to recognize the limitations of classical physics. It only works reliably in a certain range of situations as shown in the figure below:

modern-physics

“Classical Physics is usually concerned with everyday conditions: speeds much lower than the speed of light, and sizes much greater than that of atoms. Modern physics is usually concerned with high velocities and small distances.”

Limitations of Traditional Plan-driven Project Management

Similarly, project managers also need to recognize that a traditional, plan-driven project management approach only works reliably in a limited set of situations. In the project management world, this can be expressed with the Stacey Complexity Model:

stacey-complexity-model

In this model, there are two primary dimensions – one is requirements complexity and the other is technology complexity.

  • Traditional, plan-driven project management still works in areas of low complexity such as some construction projects. However, even in some of those areas, project managers have recognized a need for a somewhat more adaptive approach
  • As you get further out on either complexity axis, there is typically a need for more of an adaptive Agile approach. In that area, Agile is better suited for dealing with uncertainty but this is not a binary and mutually-exclusive proposition. There is a need to blend both approaches in the right proportions to fit the situation

Overall Summary

The way that the science of Physics has evolved has some strong similarities to the evolution of Agile Project Management.

Classical Physics Is Like Traditional, Plan-driven Project Management

The foundation of Physics today is still Classical Physics, just as traditional plan-driven project management is still a foundation of project management today:

  • Classical Physics is the theory underlying the natural processes we observe everyday.
  • It is the key to understanding the motion of pulleys, machines, projectiles and planets.
  • It helps us understand geology, chemistry, astronomy, weather, tides and other natural phenomena”

Evolution of New Ways of Thinking

Just as new theories about Physics have significantly extended the notion of what “Physics” is beyond the Classical Physics, Agile will have a similar impact on project management.  The way this will probably evolve is very likely similar to the way that Physics has evolved:

Physics EvolutionProject Management Evolution
In today’s world, there are people who specialize in Classical Physics
There are also people who specialize in the more esoteric areas of Modern Physics
There will be project managers who continue to specialize in a traditional plan-driven approach to project management
There will also be project managers who specialize in Agile
However, neither one of those areas can ignore the existence of the other areaJust as in Physics, neither one of those areas can ignore the existence of the other area
A truly broad-based Physicist has a fairly solid knowledge of both Classical and Modern PhysicsA truly broad-based Agile Project Manager has a solid knowledge of both traditional plan-driven project management and Agile

Overall Summary

There is a definite relationship between the way the science of Physics has evolved and the way that Agile Project Management is currently evolving. An understanding of how Physics has evolved will help us understand how Agile Project Management is likely to evolve.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What Is the Future of Project Management? What is the Impact of Agile?

Background

PMBOK version 6 and the new PMI Agile Practice Guide signal a new direction for the future of project management. For the first time, PMI has started to integrate Agile and traditional plan-driven project management. What does that mean for the future of project management?

Future of Project Management
A bold, red question symbol stands at the center of a light gray maze.

What’s the Impact?

I’ve written a number of articles on the future of project management and I get a lot of questions from project managers. Many are confused about the impact of Agile on project management and ask questions like “What Agile certification should I get?”.

  • Unfortunately, it’s not as simple as just going out and getting another certification like PMI-ACP
  • The PMI-ACP certification is a step in the right direction and it’s not an easy certification to get. However, it’s just a test of general Lean and Agile knowledge and is not aligned with a particular role.
  • In fact, the role of an Agile Project Manager Is not well-defined. There is even some controversy about whether there is a role for an Project Manager In an Agile environment.

Confusion Over Project Management Direction

It’s totally understandable why there would be a lot of confusion among project managers about how Agile might impact their career direction.

  • There are some project managers who are in “denial”.
    • They want to assume that traditional, plan-driven project management is the only way to do project management.
    • They assume that it will go on unchanged forever unchanged and Agile isn’t really a valid form of project management at all
  • On the other hand, there are people in the Agile community who believe that there is no need at all for traditional plan-driven project management. They believe that Agile is a solution to almost any problem you might have

An Objective, Pragmatic Viewpoint

I’m not an Agile zealot – I try to take a very objective and pragmatic approach.

  • In one of my courses, I have a slide that says “Saying Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment.
  • You have to be able to fit the approach to the problem rather than force-fitting all problems to one of those extremes.
  • Project managers who only know how to do traditional, plan-driven project management and try to force-fit all projects to that approach will be at a severe disadvantage relative to other project managers who know how to blend Agile and traditional project management in the right proportions to fit the situation.

What’s Wrong with Traditional, Plan-driven Project Management?

There’s nothing inherently wrong with the traditional, plan-driven approach to project management; the problem is in how its applied.

  • The primary problem with the traditional, plan-driven approach is that it works for situations where the requirements are well-defined. In that environment, the primary concern is planning and managing a project to meet those well-defined requirements within a given budgeted cost and schedule
  • That approach just doesn’t work well in situations where the requirements are much more uncertain. In an uncertain environment, the primary concern is not just managing costs and schedules but taking an adaptive approach to maximize the business results and value that the project produces. 
  • In today’s rapidly-changing business environment the need for taking that kind of approach is becoming increasingly common.

The Future of Project Management

There’s essentially two sides of this equation: value and cost. In the past,

  • The value side has been assumed to be well-defined by a fixed set of requirements
  • Project managers only needed to worry about the cost side

In this new environment, that is no longer true. Project managers now need to worry about both maximizing value as well as managing costs and schedules.  That’s a fundamental shift in thinking for many project managers – it means:

  • Taking a broader focus on maximizing the business value that a project produces
  • Using whatever methodology (or combination of methodologies) that makes sense to achieve those goals
  • Fitting the project management approach to the nature of the business problem rather than force-fitting all projects to a standard, plan-driven approach.

That raises the bar significantly for many project managers.

What Certification Should I Get?

Some people seem to think that it is only a matter of getting another certification. I’ve participated in several discussions lately where project managers were asking questions like:

  • “What certification should I get in order to get into Agile (CSM/PSM, CSPO, or ACP)?” 
  • The answer to the question of “what certification should I get” depends on what role you want to play. It requires some thought because there is no well-defined role for a project manager in Agile at the team level

There are several possible career directions for project managers with regard to Agile. You may not:

  • Have to completely throw away your project management skills. However, you may ave to rethink them considerably in a very different context
  • Use some traditional project management skills very fully at all depending on the role you choose

Potential Agile Project Management Roles

There are several potential migration paths for project managers who want to develop into an Agile Project Management role:

1. Become a Scrum Master

A Scrum Master:

  • Ensures that the team is fully functional and productive
  • Enables close cooperation across all roles and functions
  • Removes barriers
  • Shields the team from external interferences
  • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
  • Facilitates the daily scrums

There’s a few project management skills that might be useful (at least indirectly) for that role. However, it doesn’t utilize much of the planning and management skills that a project manager typically has.  For that reason, becoming a ScrumMaster may or may not make sense as a career direction for many project managers.

2. Become a Product Owner

The Scrum Alliance defines the primary responsibilities of a Product Owner as follows:

  • The product owner decides what will be built and in which order
  • Defines the features of the product or desired outcomes of the project
  • Chooses release date and content
  • Ensures profitability (ROI)
  • Prioritizes features/outcomes according to market value
  • Adjusts features/outcomes and priority as needed
  • Accepts or rejects work results
  • Facilitates scrum planning ceremony

The Product Owner role actually includes a lot of project management functions. However, it is actually much more similar to a Product Manager than a Project Manager.  The major differences are that:

  1. The Product Owner is a business decision-maker and requires some business domain knowledge that a project manager may not have.
  2. The Product Owner role doesn’t typically include many team leadership skills. In an Agile environment, team leadership is more a function of the ScrumMaster and the team itself.

3. Hybrid Agile Project Management Role

For a lot of good reasons, many companies will choose to implement a hybrid Agile approach that blends the right level of traditional plan-driven project management with Agile.

  • This is a very challenging role for a project manager to play.
  • It requires a deep understanding of both Agile and traditional plan-driven project management to know how to blend these two seemingly disparate approaches together in the right proportions to fit a given situation.

4. Project/Program Management of Large, Complex Enterprise-level Agile Projects

There is a legitimate role for project managers in managing large, complex enterprise-level projects; however, there are several things to consider about planning your career in that direction:

  • This role is limited to large, complex projects that typically require multiple Agile teams
  • It also may require blending together some level of traditional plan-driven and Agile principles and practices in the right proportions to fit the situation
  • This role doesn’t exist at all on most small, single-team Agile projects

This role requires some very significant skills that can be very difficult to attain. Many people may assume that the PMI-ACP certification qualifies you to perform this role. It is a step in the right direction, but a lot more experience and knowledge is needed to perform this role including:

  • Knowing how to blend traditional, plan-driven principles and practices in the right proportions to fit a given project,
  • Adapting an agile approach to fit a business environment, and
  • Scaling Agile to an enterprise level.

You have to be a “rock star” Agile Project Manager to perform this role.

Overall Summary

Agile will have a big impact on the future of the project management profession:

  • In many industries and application areas, the project management role associated with small, single-team projects may be completely eliminated by Agile
  • There may be some project managers who are not significantly impacted by this such as project managers in the construction industry, but even in those industries some knowledge of Agile principles and practices may be essential

This creates difficult choices for a Project Manager to make. Agile may force project managers to make some significant choices about their career direction. It isn’t as simple as just going out and getting another certification (like PMI-ACP).

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

What is the Purpose of the New PMI Agile Practice Guide?

PMI recently published PMBOK version 6 as well as a new document called “The Agile Practice Guide”.   The Agile Practice Guide is a totally new kind of document for PMI and raises some questions about “What is the purpose of the new PMI Agile Practice Guide?”

For a long time, PMI has treated Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two.  A major goal of this guide s is to start to develop a more integrated view of these two areas. I think this is a major step forward to begin to close this gap.

A lot of people may have thought that integrating these two areas might be as simple as adding more content about Agile to PMBOK version 6. They might think that PMBOK version 6 would become a universal guide to both of these areas.  I don’t believe that to be a realistic way to accomplish that goal at all. See my article on Does PMBOK Version 6 Go Far Enough to Integrate Agile?

What is the Purpose of the New PMI Agile Practice Guide?

Agile and traditional plan-driven project management are two radically different approaches to project management that each require significant individual focus; however, at the same time, we need to build a much more unified view of these two areas. I think that is exactly the role that the Agile Practice Guide attempts to fill.  Here’s how I see these various documents fitting together:

What is the Purpose of the New PMI Agile Practice Guide?

Here’s how I see this all fitting together:

  • PMBOK has become well-accepted for many years as the “bible” for a traditional plan-driven approach to project management. It is very detailed and somewhat prescriptive. To some extent, some (not all) of the practices in PMBOK provide a foundation for a general project management approach
  • Agile documentation has a very different and less prescriptive format. It is primarily based on some very simple and succinct principles and values in the Agile Manifesto

Those two formats are very incompatible with each other in my opinion. However, there is some commonality and we need to start to develop a more unified view of these two different worlds.  That is the major purpose that the PMI Agile Practice Guide attempts to serve in my opinion.

What Does This Mean for the Future of Project Management?

This strongly reaffirms what I’ve been saying for a long time. The way of the future seems very clear:

  • There is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people have seemed to think. Those two areas are actually complementary to each other rather than competitive.
  • There is a continuous spectrum of different approaches ranging from:
    • Heavily plan-driven (predictive) at one extreme to
    • Heavily adaptive (Agile) at the other extreme

The right approach is to fit the methodology to the nature of the problem rather than just force-fitting a problem to some predefined methodology (whatever it might be).

The project manager of the future needs to be proficient in both of these approaches and also know how to blend the two approaches as necessary to fit a given situation.  In the not-too-distant future, any project manager who only knows how to do traditional plan-driven project management and attempts to force-fit all projects to that approach will be at a serious disadvantage.

Review of the Agile Practice Guide?

Here’s a brief summary of my review of the Agile Practice Guide:

General Comments

  • Overall, I think this document is well-written and really helps to close the gap between Agile and traditional plan-driven project management. However, that is a huge gap and there is still a lot more work to be done to create a truly integrated project management approach.
  • Agile and traditional plan-driven project management are two very different ways of thinking and it will be very difficult to fully integrate the two.  This is a great step in the right direction but it’s not the final step to close that gap.

Specific Comments

Agile PM Role
  • I don’t think this document has gone far enough to address the real “elephant in the room”. That is, “What exactly is the role of a Project Manager in an Agile environment?”.
    • There are many project managers who are in denial about that.
    • They think that their project management role will go on indefinitely unchanged.  
    • There is a need to address this issue more directly so that project managers can plan their future career direction.
  • In the back section of the document, in a number of different places, it says that the role and expectations of a project manager don’t change in an Agile environment.  I don’t agree with that at all. The role of a project manager at the team level (if there is one at all) will likely change radically to more of a coaching and facilitation role than a traditional PM role.
Organizational Perspective
  • The authors of The Agile Practice Guide made a decision to limit the scope of this document to project and team-level work. They excluded discussion of the context of implementing Agile at an enterprise and organizational level. I think that is serious a mistake.
  • This is much too limiting because most Agile implementations cannot be successful without some level of organizational transformation.  Furthermore, the role of a project manager is either non-existent or very limited at the team level. That will force many project managers to move up to more complex enterprise-level projects.
Agile Mindset
  • The section on “Agile Mindset” is really important and probably could be beefed up a lot. There is a big shift in mindset that is needed but it’s not just a matter of a choice between adopting an “Agile Mindset” or a “Traditional Project Management Mindset”.
  • I n many cases, you need to blend the two approaches and take a broader view of what “project management” is.
    • That broader view should fully embrace both of those approaches.
      • Many people would not view “Agile” as “Project Management” because it doesn’t fit the normal stereotype of what “project management” is
      • However Agile is just a different form or “project management”.  That’s a big mindset change that PM’s need to make – we need to rethink what “project management” is in broader terms that include all forms of project management including Agile.
Relationship of Lean and Agile

I don’t agree with the graphic on page 11 showing that Lean totally encompasses Agile.  It does not – there is a lot of overlap between the two; however, taken to an extreme, each would tend to pull you in somewhat different directions.  Both are focused on customer value but:

  • Lean is more heavily focused on efficiency where
  • Agile is more heavily focused on flexibility and adaptivity.
Agile versus Predictive

The document talks about a spectrum of alternatives with predictive at one end point and Agile at the other end point.  The idea of a spectrum of approaches is right on. However, I don’t think that the use of the word “Agile” for an end point is the right choice.  Agile should not be an end point because there is not just one way to do Agile. There are a range of choices for Agile.  This spectrum should reflect different levels of planning and I think the end-points are “adaptive” and “plan-driven” (or “predictive”).

Hybrid Approach

The section on hybrid approaches needs to be improved. This is a critical area for PM’s to understand. As it is currently written, this is too high level and not specific enough to help a PM understand how to really implement a hybrid approach.

Team Roles

I would like to see the discussion of team roles expanded.  One particular subject that is not covered is how many project functions that might normally be performed by a project manager have been assimilated into other roles in an Agile environment.  Agile uses a distributed form of project management.

Overall Summary

If you are a PMI member, you can download a copy of the Agile Practice Guide from the following link:

https://www.pmi.org/pmbok-guide-standards/practice-guides/agile

I am very pleased to see the PMI Agile Practice Guide being published.  It is definitely a step in the right direction and is very consistent with the integrated approach to Agile Project Management that I’ve developed in the Agile Project Management Academy.

PMBOK and Agile – Does PMBOK Version 6 Go Far Enough to Integrate Agile?

One of the biggest changes in PMBOK® version 6 is that it has incorporated more guidance about Agile. Does PMBOK version 6 go far enough to integrate Agile?  

  • I think that the release of PMBOK version 6 and The Agile Practice Guide is a huge step forward. It is a noble attempt to create a more integrated approach for integrating Agile and traditional plan-driven project management;
  • However, the full integration of Agile and traditional project management requires some very major shifts in thinking. It even involves something as fundamental as adopting a much broader definition of what “project management” is.
Does PMBOK version 6 go far enough to integrate Agile?

I don’t think that simply adding some words about Agile to PMBOK is going to be sufficient to bring about the kind of shift in thinking that is needed.

What is “Project Management?

The crux of the problem is that for many years the essence of what “project management” is has been centered on some very well-established stereotypes of what “project management is. Those stereotypes are based on achieving predictability and repeatability as shown below:

Traditional Project Management Emphasis

Traditional Project Management Emphasis

That’s the primary way people have thought about what “project management” is since the 1950’s and 1960’s.  A successful project manager is one who could plan and manage a project to meet budgeted cost and schedule goals. That obviously requires an emphasis on planning and control.

The way to achieve predictability and repeatability has been to have a detailed and well-though-out plan and then control any changes to that plan.

Many people loosely refer to this approach as “Waterfall” because, in many cases, it has been implemented by using a sequential phase-gate process.  However,  I don’t believe that description is entirely accurate:

  • I prefer to refer to it in more general terms as “traditional, plan-driven project management”
  • PMI has started using the term “predictive” to describe this kind of project management approach because the emphasis is on predictability
What’s Wrong With That Definition?

In the 1950’s and 1960’s that approach worked well and it was particularly in high demand for large, complex defense programs that were well-noted for cost and schedule overruns.  At that time, the primary goal was to achieve predictability.  In fact, that approach has been so prevalent that it has essentially defined what “project management” is. Since that time, many project managers don’t see any other way to do project management.

The problem with that approach is it only works well in environments that have a fairly low level of uncertainty where it is possible to develop a fairly detailed plan prior to the start of the project.

Factors Driving Change

In today’s world, there are several major factors driving change:

  1. The environment we live in today has a much higher level of uncertainty associated with it. That makes it very difficult, if not impossible, to develop detailed plans prior to the start of a project
  2. Solutions are more complex and are much more difficult to design and optimize
  3. Competitive pressures demand high levels of creativity and innovation in spite of the level of uncertainty in the environment.  Producing high-value business results is more important than predictability in many cases.

The New Environment

This new environment demands a very different kind of project model that looks more like this:

Think of a typical new product today like the next generation of  the iPhone.  Do you think that a traditional plan-driven approach with an emphasis on predictability, planning, and control would work well to develop that kind of product?

How Are PMBOK and Agile Different?

The differences in how these two approaches have been defined and implemented in actual practice are very significant:

AreaTraditional Plan-driven Approach (PMBOK)Agile
Approach
Process
Control
Model
Based on what is called a “Defined Process Control ModelBased on what is called an “Empirical Process Control Model
PM
Emphasis
The emphasis of is on planning and control to achieve predictability over project costs and schedulesThe emphasis is on using an adaptive approach to maximize business results in an uncertain environment
PM
Role
Project management functions are typically implemented by someone with clearly-defined responsibility for that role called a “Project Manager”The functions that might normally be performed by a “Project Manager” at the team level have typically been distributed among other roles
ImplementationFollowing a well-defined plan and process are typically importantReliant on the judgement, intelligence, and skill of the people doing the project to fit an adaptive approach to the nature of the project

Is the Agile approach shown above in the right-hand column not “project management?  A lot of people would not recognize it as “project management” because it doesn’t fit with many of the well-defined stereotypes of what “project management” is.  I contend that it is just a different kind of “project management” that will cause us to broaden our thinking about what “project management” is.

“Project Management” should not be limited to a particular methodology.  A project manager should be capable of delivering results using whatever methodology is most appropriate to achieve those results.

Is One Approach Better Than the Other?

There are a lot of Agile enthusiasts out there who will advocate that Agile is a better approach for almost any problem you might have.

My opinion is that saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – they both have advantages and disadvantages depending on the environment that you’re in.

  • An Agile approach works best in situations that have a relatively high level of uncertainty. In those situations, creativity and innovation to find an appropriate solution are more important than predictability.   For example, if you were to try to find a cure for cancer, it would be ridiculous to try to develop a detailed plan for that effort.
  • A traditional plan-driven approach works well in situations that have a relatively low level of uncertainty and where predictability, planning, and control is important.  For example, if you were building a bridge across a river, it would be equally ridiculous to say: “We’ll build the first span of the bridge, see how that comes out , and then we’ll decide how to build the remaining spans.”

Are These Two Approaches Mutually-Exclusive?

A lot of people have the mistaken belief that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”:

  • There has been a lot of polarization between the Agile and project management communities for a long time. Many people in these two communities have seen these two approaches in conflict with each other
  • PMI has treated these two areas as separate and independent domains of knowledge for a long time with little or no integration between the two

It takes a higher level of skill and sophistication to see these two approaches in a fresh new perspective as complementary to each other rather than competitive. It is a challenge to learn how to blend them together in the right proportions to fit any given situation but it definitely can be done.

Does PMBOK version 6 go far enough to integrate Agile?

I have ordered a final copy of PMBOK Version 6 and haven’t actually seen it yet; however, I have seen early preview editions and I think I understand where it is trying to go. I have several concerns:

  1. As I’ve mentioned, I think that there is a huge and fundamental shift in thinking that is needed to rethink what “project management” is.  I’m not sure that simply adding some words about Agile to PMBOK is going to be enough to help people make that shift in thinking. It requires seeing “project management” in a fundamentally and radically different perspective.
  2. The whole concept of PMBOK does not seem to be very consistent with an Agile approach:
    • Agile is based on some very simple and succinct principles and values. It relies very heavily on the training and skill of the people performing the process to interpret those principles and values in the context of a project
    • The latest version of PMBOK is over 700 pages long. It’s supposed to be a “guide” but it seems to try to provide a detailed checklist of things to consider for almost any conceivable project management situation.

Putting those two things together is like trying to mix oil and vinegar. They just don’t blend together very well and attempting to blend the two approaches at that level doesn’t seem to make much sense.

What is the Solution?

This is definitely a challenging problem.  Agile and traditional plan-driven project management are like two different religions – they both have a common goal of delivering business results but the way each approach goes about doing it is very different.

There are two significant components of the solution to this problem:

Developing an Integrated View of Project Management

Somehow, we have to create a much more unified view of what “project management” is. That view should fully embrace Agile as well as traditional plan-driven project management.  However, modifying PMBOK to totally integrate Agile would be very difficult.  Its like setting out to create a unified view of religion.  A better approach might be to cross-reference the two sources to identify areas of similarity and then create an over-arching guide to blend the two approaches together to create a unified view of religion.

I believe that is essentially what PMI has attempted to do with The Agile Practice Guide. I  discussed that in a separate article.  For a long time, PMI has treated Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two.  The new Agile Practice Guide attempts to bridge that gap and show a more integrated approach to those two areas.  I think that is the only reasonable strategy that makes sense for now.

Develop a New Breed of Agile Project Managers

This “raises the bar” significantly for the whole project management profession.  In my Agile Project Management books, I have often used the analogy of a project manager as a “cook” versus a project manager as a “chef” that was originally developed by Bob Wysocki:

  • A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook
  • A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Blending Agile and Traditional Project Management