Is PMP Certification Still Relevant in Today’s World?

I have mixed feelings about the subject of “Is PMP certification still relevant in today’s world?”. On the one hand,

  • I am a PMP myself,
  • I have had a PMP certification since 2004, and
  • I’m proud to be a PMP, but I recognize the limitations of a PMP certification.

On the other hand, I can clearly see the limitations in the PMP certification.

IS a PMP Certification Still Relevant?

Is PMP Certification Still Relevant?

What Are the Limitations of PMP®?

PMP is heavily based on a traditional plan-driven project management approach (what many people loosely call “Waterfall”). The world is rapidly changing today.  There’s nothing inherently wrong with a traditional plan-driven approach to project management under the right circumstances. However, we definitely shouldn’t try to force-fit all projects to that approach.

  • A traditional plan-driven approach to project management works well in situations where there is a relatively low level of uncertainty and predictability is important
  • It does not work well in situations
    • With a high level of uncertainty or
    • Where an emphasis on creativity and innovation may be more important than an emphasis on planning and control to achieve predictability

In today’s world,

  • A project manager needs to be capable of using a broader range of methodologies to fit the nature of the project rather than
  • Force-fitting all projects to a traditional plan-driven approach.  

Situations are becoming increasingly common that require a more flexible and adaptive approach due to very uncertain rapidly-changing technology and a very dynamic and very competitive business marketplace.

What Is the Impact of Agile on PMP?

For those reasons,

  • Agile is having a profound effect on the project management profession that will cause us to rethink the way we do project management.  
  • That doesn’t mean that traditional plan-driven project management and PMP are obsolete.
  • However, we’ve got to think of project management in broader terms and
  • Recognize that traditional plan-driven project management is not the only way to do project management

Check out this article for more on that:

What is “Agile” and Why Is It Important to Project Managers?

Is PMI-ACP Certification the Answer?

PMI-ACP® certification is a step in the right direction but it doesn’t go far enough in my opinion:

  • It doesn’t really address the big challenge that many project managers face today of “how do I blend Agile and traditional plan-driven project management in the right proportions to fit a given situation?”  
  • Unfortunately, PMI still treats Agile and traditional plan-driven project management as fairly separate and independent domains of knowledge with little or no integration between the two

What About PMBOK® Version 6?

The final edition of PMBOK version 6 was released in September 2017. One of the big changes is that it contains more references to Agile.  

  • The changes to PMBOK v6 barely scratch the surface of what needs to be done to develop a more integrated approach
  • I can’t imagine that future extensions to PMBOK will solve this problem either

The whole concept behind PMBOK is not very compatible with an Agile approach.  These are two very different ways of thinking:

PMBOKAgile
PMBOK is based on the idea that you can develop a checklist of things to consider in almost every conceivable project management situation that you can imagine.Agile requires a very different mindset.  An Agile approach needs to be much more adaptive and it would be impossible to develop a checklist defining what to do in every conceivable situation you might find yourself in in an Agile environment.
PMBOK and traditional plan-driven project management are based on a defined process control modelAgile is based on an empirical process control model which means that both the product and the process to produce the product are continuously adapted based on observation throughout the project
PMBOK is over 500 pages long with lots of details on what to do or consider in various situationsAgile is based on some very brief and succinct principles and values without a lot of detail and expects you to figure out what to do in a given situation.
PMBOK is also based on compartmentalizing a project into distinct and well-defined process groupsAgile requires a much more holistic and integrated approach to project management

What is the Long-term Solution?

This is not an easy problem to solve. 

  • In the long-term, the solution to this problem is likely to involve some very significant rethinking of both PMBOK and PMI certifications.
  • What is needed is to create a much more integrated approach for blending Agile and traditional plan-driven project management principles and practices.
  • However, that is a very difficult problem to solve and is not likely to happen for a while.

What Is the Short-term Solution?

In the short-term, here are some possible strategies:

If You Have a PMP Today

If you already have a PMP certification today, that knowledge is a good foundation to begin to develop a broader focus on an Agile Project Management approach. However, it does require a lot of rethinking on how to do project management and also requires a very different mindset.

If You Don’t Already Have a PMP Certification Today

If you don’t already have a PMP certification today and are early in your career as a project manager, you have a much more difficult choice to make between two directions:

1. Getting a PMP

You could make a significant investment in time and money to get a PMP certification and then perhaps move on to learn an Agile approach sometime later.  If you are working in an industry or application area where traditional plan-driven project management is still the dominant way of working, that might be  a reasonable choice.

2. Skipping PMP

If you’re not working in an industry or application area where traditional plan-driven project management is the dominant way of working, getting a PMP may not make sense.  Certainly, some foundation of traditional plan-driven project management is worthwhile but you may not need a full PMP for that.  An alternative is to skip getting a PMP and just focus on developing an integrated approach to  Agile Project Management.

In my opinion, skipping PMP and developing a more integrated Agile Project Management approach may be a reasonable for anyone

  • Who doesn’t already have a PMP and
  • Is interested in an Agile Project Management role.  

However, it is a very difficult path to follow in the short term  because:

  • There is currently no certification built around an integrated approach to Agile Project Management and
  • The knowledge base is not well-developed either
  • For that reason, you have to be somewhat of a “pioneer” in choosing this direction and
  • Since there is no certification, “you don’t know what you don’t know”.

Overall Summary

Is PMP Still a Good Foundation?

Some elements of PMBOK and PMP are definitely useful as a foundation for any kind of project management.

  • However, the depth of study and knowledge required for PMP certification tends to “brainwash” people into thinking that PMP/PMBOK is the only way to do project management and that is not the case
  • Someone who only wants a foundation of knowledge in traditional plan-driven project management principles probably doesn’t need that depth of knowledge

The full PMP certification would still be appropriate for any project managers who plan to specialize in traditional plan-driven project management. However, that depth of knowledge in plan-driven project management should not be needed for someone who wants to develop an integrated Agile Project Management approach.

Additional Resources

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

Why Is Agile Important to Project Managers?

I think a lot of people are confused about “What is ‘Agile'” and the importance of Agile to project managers:

  • The word “Agile” has many different connotations
  • Many project managers think that it is something that only applies to software development and doesn’t apply to them at all.

For more detail on that, here’s an article with more detail on “What is Agile?”:

What is Agile?

Different Meanings of “Agile”

“Agile” means a lot of different things to different people. To some people:

  • It means just developing software faster, or
  • It means creating a more people-oriented project environment,
  • To others, it means making the project management process a lot more efficient by streamlining the whole process and eliminating unnecessary documentation

Those are only a few different connotations – there are many, many more. In addition, there are also many more stereotypes, myths, and misconceptions about what Agile is.

All of those things are potential outcomes of an Agile process but that’s not the fundamental essence of what an Agile process is all about in my opinion.  The fundamental essence of an Agile process is adaptivity.

What’s Wrong With the Typical Project Management Approach?

Many project management processes, as we know them today, were designed around what is called a “traditional plan-driven project management” model (what many people loosely call “Waterfall“). 

  • In this model, achieving predictability over the outcome of a project and the costs and schedule associated with achieving that outcome is very important
  • Therefore, it is also very important to have clearly-defined requirements as well as an adequate level of planning to be able to somewhat accurately predict the outcome, costs, and schedule of the project

That’s the predominant way that project management has worked since the 1950’s and 1960’s. A project was considered successful if it delivered what the requirements for the project within the defined budget and schedule.

That kind of predictability can be important. For large investments, it allows a company to:

  • Attempt to calculate with some level of certainty what the return on their investment is likely to be from a project, and
  • Make a go/no-go decision as to whether the project should be funded or not based on that information.

The primary problem with that approach is that it requires developing a fairly detailed plan for the project upfront. That is very difficult, if not impossible to do in projects with a very high level of uncertainty.

Why Is Adaptivity Important?

We live in a different world today from the world that existed in the 1950’s and 1960’s when formalized project management approaches were first defined. 

Higher Levels of Uncertainty

There is a much higher level of uncertainty:

  • Technology is rapidly changing,
  • Solutions are much more complex, and
  • The business environment that we operate in is dynamic and constantly changing.

In that kind  of environment,

  • Developing a detailed plan for a project with a lot of uncertainty upfront will typically require you to make a lot of assumptions.
  • And, many times those assumptions will be wrong  and may require significant re-planning and possible rework later.

Rather than force-fitting a project that has a high level of uncertainty to a traditional plan-driven approach;

  • it’s much better to fit the methodology to the nature of the project and that’s where a more adaptive approach really makes sense. 
  • That doesn’t mean that you don’t do any upfront planning; it means that you use a level of planning that is appropriate to the level of uncertainty in the project:
Traditional Plan-driven ApproachAdaptive (Agile) Approach
Atempt to develop a detailed set of requirements and a detailed project plan for the project upfrontLimit the amount of upfront planning based on the level of uncertainty in the project and use a “rolling-wave” planning approach to further define the requirements and plan for the project as the project is in place

Need for Creativity and Innovation

Another important factor in today’s environment is that there is a greater need for creativity and innovation to develop truly leading-edge products. An over-emphasis on planning and control can stifle creativity and innovation.

What’s an Example of a Project Requiring an Adaptive Approach?

A Simple Example

I use an example in my Agile Project Management training that is somewhat extreme but it gets the point across. The example I use is:

  • Suppose you were given the task to find a cure for cancer and you were asked to outline:
    • What the solution will be,
    • How long it will take to develop it, and
    • What the total cost of the research will be to develop the solution
  • In that situation, it would be ridiculous to attempt to develop a detailed project plan with accurate cost and schedule estimates – there is just way too many uncertainties to resolve
  • So what would you do? Give up and do nothing? That doesn’t make sense either

It’s important to recognize that we do know some things about finding a cure for cancer based on years of research that have gone into that area.

  • However, there are still way too many unknowns to develop a detailed project plan for a solution
  • What you would do is take advantage of what is known as much as possible and then take an iterative, trial-and-error approach to find a solution

Thomas Edison and the Light Bulb

That’s the way Edison invented the light bulb…here’s a quote from Edison on that subject:

“I speak without exaggeration when I say that I have constructed three thousand different theories in connection with the electric light, each one of them reasonable and apparently to be true. Yet only in two cases did my experiments prove the truth of my theory. My chief difficulty, as perhaps you know, was in constructing the carbon filament, the incandescence of which is the source of the light.”

(1890 Interview in Harper’s Magazine)

In a 1910 autobiography of Edison, Edison’s friend and associate Walter S. Mallory is quoted as asking

“Isn’t it a shame that with the tremendous amount of work you have done you haven’t been able to get any results?”  The book goes on to say that “

Edison turned on him like a flash, and with a smile replied:

“Results! Why, man, I have gotten lots of results! I know several thousand things that won’t work!”

What Makes This Kind of Project Different?

There are two things that make this kind of project fundamentally different:

  1. The level of uncertainty is very high and makes it impractical or impossible to develop a detailed plan for the project upfront
  2. Creativity and innovation required for finding a good solution are far more important than predictability

How Does an Agile Approach Solve This Problem?

An Agile process is built on an “Empirical” Process Control model. The word “empirical” means “based on observation”. In the context of an Agile development process, “Empirical” means that during the course of a project, both the product as well as the process to produce the product are continuously refined as the project is in progress. The goal is to produce the right product and to optimize the value of the product being produced.

Empirical Process Control Model

Why Is This Important to Project Managers?

You might ask “Why is this important to project managers?”

  • Isn’t Agile something that only applies to software development? (That’s a common misconception)
  • The truth is that all projects have some level of uncertainty associated with them

If you try to force-fit all projects to a traditional plan-driven project management approach, its just not going to work in many cases. Imagine, for example,

  • Trying to develop the next generation of the iPhone or any other new and innovative product
  • In that kind of project, creativity and innovation is just as important, if not more important, than predictability.

In this new environment, a project manager who only knows how to do a traditional plan-driven approach to project management will be at a serious disadvantage. What makes this even more difficult is that:

  • That this is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.
  • It’s a matter of figuring out how to blend a traditional plan-driven approach with an adaptive (Agile) approach in the right proportions to fit a given situation.

Overall Summary

Agile will have a profound impact on the project management profession that will cause us to rethink many things we have taken for granted for a long time about what “project management” is.

Additional Resources

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

How to Make a Hybrid Agile Process Work

Have you given any thought to “How to make a hybrid agile process work”? Some people claim that hybrid Agile projects don’t work at all. For example, I recently saw an article on LinkedIn entitled “Why Hybrid Agile-Waterfall Projects Fail” that caught my eye.  I’m not surprised at this article:

  • It takes some skill to make a hybrid Agile process work successfully and
  • Anyone who would literally try to combine an Agile methodology with a Waterfall methodology to create a hybrid methodology is asking for failure

That’s not the way to do it

Blending Two Recipes

This should not be a matter of literally combining an Agile methodology and a Waterfall methodology.

  • That would be like trying to take a recipe for Italian food with a recipe for Chinese food and literally trying to mix the steps and ingredients from the two recipes together to create “Italian-Chinese” food
  • A good chef would never even attempt to do that. However, he/she might create an entirely new recipe that blends together some of the aspects of Italian food with some aspects of Chinese food

Creating a Hybrid Approach

It takes a lot of skill to create an effective hybrid approach and doing it effectively is like the difference between a “chef” and a “cook”. 

When I talk about creating a hybrid approach, I try to avoid the words “Agile” and “Waterfall” if possible. Those words give people the impression that you are literally combining two different methodologies together like combining two food recipes: 

  • I prefer to think of a hybrid approach as the appropriate blend of an adaptive approach and a plan-driven approach
  • The words “adaptive” and “plan-driven” convey an entirely different meaning than “Agile” and “Waterfall”

Creating a hybrid Agile approach:

  • Doesn’t mean that you’re trying to literally combine two very different methodologies by mixing them together
  • Means that you’re creating a blended approach with the appropriate amount of emphasis on being “adaptive” versus being “plan-driven”

An Example of a Real Hybrid Approach

Some years ago, I was responsible for managing a very large development program for a US Federal Government agency:

  • It had a fixed-price contract associated with it and a fairly aggressive delivery schedule
  • However, the customer wanted some level of flexibility in the details associated with defining requirements 
  • I created an approach for this situation that was very successful that I have called “The Managed Agile Development Framework“.

The Managed Agile Development approach:

  • Does not attempt to literally combine an Agile methodology and a Waterfall methodology
  • Instead, it wraps a plan-driven layer at the “macro” level around a standard Agile/Scrum process at the micro level

Here’s a diagram that shows what it looks like:

Hybrid Agile Process

You might say:

  • “That’s not a hybrid Agile-Waterfall model”
  • “It’s only a standard Agile development process with a plan-driven layer wrapped around it”

And, that would be correct.  There has been no attempt to actually mix-and match a phase-gate Waterfall methodology with an Agile methodology.

How To Make a Hybrid Agile Process Work

This is a very flexible model – that is why I call it a “framework” rather than a “methodology”.

1. Project Planning

You would start out a project by at least developing high-level requirements with estimates of the costs and schedule for completing the project.  Those estimates can be as detailed as you want them to be. That’s what makes this model so flexible.

  • You can have a relatively “thin” layer of planning with very high-level requirements and less-detailed plans or
  • A “thicker” layer of planning with more detailed requirements and planning

The most important thing is that there has to be a common understanding between the development team and the customer about how detailed the requirements and plan are:

This model will not work without a spirit of trust and partnership between the customer and the project team.  The customer and the project team must agree to working collaboratively as the project is in progress to:

  • Further elaborate requirements,

  • Continuously refine the plan for completing the project, and

  • Resolve any trade-offs that may be necessary to stay within the budgeted cost and schedule.

2. Managing Changes

As the project is in progress, any changes to the project requirements made at the “micro” level need to be fed back into the planning at the “macro” level.

By agreement with the customer, there should be enough slack built into the plan so that minor changes can be absorbed easily without a change to the overall plan. Only more significant changes might require trade-offs and adjustments. When trade-offs are needed to stay within the budgeted cost and schedule, the customer may need to either:

  • Adjust the planned cost and schedule as necessary, or
  • Reduce the scope of some of the requirements if necessary to fit within the planned cost and schedule.

This is a fairly simple model but it works and it can be easily adapted to a wide variety of projects. However, note that this is not a simple step-by-step cookbook approach. It takes some skill to make this model work successfully.

Matching the Level of Uncertainty in the Project

A good strategy is to match the design of the hybrid approach to the level of uncertainty in the project:

  • A project with a lower level of uncertainty might lend itself to a more plan-driven approach particularly if predictability is important to the customer of the project.  That would mean putting a higher level of emphasis on developing a “thicker” layer of planning at the  macro-level
  • A project with a higher level of uncertainty would probably require a more adaptive approach to further elaborate the plan as the project is in progress.  That would mean that the level of planning at the macro-level would probably be much “thinner”.

Overall Summary

It is very possible to create a hybrid Agile approach that blends Agile principles and practices with traditional plan-driven project management principles and practices in the right proportions to fit a given situation but it can require a considerable amount of skill to do that.

Additional Resources

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

What Does Waterfall Mean? How Do People Use That Word?

What does ‘Waterfall’ really mean? Have you ever thought about that?

  • The word “Waterfall” is often used in comparison to ‘Agile’ but do people know what they really mean when they compare ‘Agile’ to ‘Waterfall’?
  • I think the word ‘Waterfall’ is one of the most loosely-used words in the English language (the word ‘Agile’ is not far behind).

When people talk about ‘Agile’ and ‘Waterfall’,

  • it sounds like they’re comparing two very specific and well-defined methodologies that are binary and mutually-exclusive opposites of each other
  • However, when you dig into what the words ‘Waterfall’ and ‘Agile’ really mean, you quickly discover that’s a very inaccurate and misleading comparison
What Does Waterfall Mean?

What Does Waterfall Mean?

Strictly speaking, the word ‘Waterfall’ was originally defined in 1970 by Dr. Winston Royce in his very famous paper:

Dr. Winston Royce’s 1970 Waterfall Paper

Dr Royce described a model that consists of a sequence of phases. In this model, the outputs of one phase flow into the next phase like a “Waterfall”:

What Is Waterfall

The process was called ‘Waterfall’ because the results of one phase flow into the next phase like a waterfall.

What Was Life Like Prior to ‘Waterfall’?

it is useful to understand what life was like prior to Waterfall and what problems it tried to solve. What existed at that time was a lot of poorly-organized development efforts with little or no structure, discipline, and planning. Some of the major problems with the that approach were:

Coordinating Work of Large Development Teams

As projects grew in terms of scope and complexity with potentially much larger numbers of developers, it became apparent that a more planned and structured approach was essential to coordinate the work of large development teams

Cost and Schedule Overruns

The other major problem was that there was very limited predictability over the costs and schedules of software projects:

  • There were many and frequent very significant cost and schedule overruns, and
  • Business sponsors demanded some level of predictability

How Did the Waterfall Process Improve These Problems?

When the Waterfall approach was originally defined, it was a big improvement to go from practically no methodology at all to a very well-defined process. The new Waterfall process provided:

  • A “road map” to:
    • Coordinate the work of multiple developers as well as
    • Integrate the work with any other essential resources outside of the immediate development teams, and
  • A mechanism to gain control over the scope of software projects in order to get more predictability of project costs and schedules

Many younger people today don’t appreciate that history and just criticize Waterfall as being bad without understanding the problems it was intended to solve.

The “Pendulum Effect”

As with many things, there was a “pendulum” effect when the Waterfall approach was initially implemented. There was somewhat of an over-correction in many cases in going from no methodology to a very well-defined methodology. The pendulum swung in many projects from almost no control and discipline to very rigid control and discipline.

It Became Very Rigid and Inflexible

The initial implementation of the Waterfall process had a number of problems that even Dr. Royce recognized in 1970 when he first defined the process. Some of the most serious problems were:

  • The common practice when the Waterfall process was originally defined in 1970 was a very document-intensive and over-controlled process
  • You couldn’t exit a phase until all the documentation required to show that the work required for that phase had been completed, reviewed, and approved
  • The ultimate user of the software didn’t normally even see the software until all of the development and testing was complete and by that point in time; it was very difficult, if not impossible, to go back and make any significant changes
  • The emphasis on control of scope made the process very inflexible to any changes that might be needed to meet user needs and business goals in an uncertain environment

What Was the Impact?

As a result,

  • There have been many situations where the project may have met cost and schedule goals but failed to provide a sufficient level of business value
  • Another major problem was that a heavy emphasis on documentation and other overhead required for reviews and approvals made the whole process bureaucratic and not very cost efficient

It’s important to note that many of the problems associated with “Waterfall” are a result of how it is implemented and not necessarily inherent problems in the methodology itself.

Why Is the Agile versus Waterfall Comparison So Misleading?

A big reason why the typical Agile versus Waterfall comparison is so misleading is that the words “Agile” and “Waterfall” are so loosely-used:

How is the Word “Waterfall” Loosely-used?

Before Agile came into widespread use, many variations on the original Waterfall model were developed to create a more adaptive approach to solve some of these problems.

  • More iterative processes such as the Rational Unified Process (RUP) and a number of variants became widely-used in the 1990’s and early 2000’s
  • There has been a proliferation of a broad range of many different development models such as the Spiral model
  • Some of those have only a very limited resemblance to the original ‘Waterfall’ model as it was defined in 1970.

In spite of this evolution, people still loosely characterize all of those methodologies as ‘Waterfall’ as if it was one specific, unique and well-defined methodology called ‘Waterfall’ and that is not really the case


The common denominator of all the methodologies that people loosely call ‘Waterfall’ is that

  • They emphasize some level of upfront planning and control.
  • The goal is to try to achieve predictability over project scope, costs, and schedules.

For that reason, I think the word “plan-driven” is a more accurate and objective description of what people really mean when they say ‘Waterfall’.

How Is the Word “Agile” Loosely-Used?

The word ‘Agile’ is also loosely used. We all know that ‘Agile’ is not a specific methodology although many people equate ‘Agile’ with Scrum:

  • Scrum is not really a specific methodology, it is really a framework that is intended to be adaptable to a broad range of situations
  • Agile is not really equivalent to Scrum. There are other Agile methodologies such as Kanban

The common denominator of methodologies that people call ‘Agile’ is that:

  • They are flexible and adaptive and
  • Emphasize creativity and innovation in an uncertain environment

rather than:

  • Emphasizing planning and control to achieve predictability with lower levels of certainty.

For that reason, I prefer to use the word “adaptive” instead of the word ‘Agile’ when comparing it to ‘Waterfall’ (plan-driven).

Overall Summary

When people in the Agile community compare ‘Agile’ and ‘Waterfall’, it’s usually in the context of

  • Agile is good and Waterfall is bad and that’s really not accurate and objective.
  • Saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – both have advantages and disadvantages depending on the environment that you are in.

The words “Agile” and “Waterfall” are very loosely used in practice and that causes a lot of confusion. They are used as if both “Agile” and “Waterfall” are unique, individual methodologies and that is not the case.

The word “Waterfall”, in particular, is very loosely-used.

  • When people use the word “Waterfall”, they’re not necessarily talking about the real “Waterfall model that was defined by Dr Winston Royce in the 1970’s
  • They’re really talking about any plan-driven methodology that is not completely agile.

A better way to think about “Agile” versus “Waterfall” is in terms of “adaptive” versus “plan-driven”. That’s a much more accurate and objective way of making that comparison.

Additional Resources

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

Agile and Six Sigma – Are They Complementary to Each Other?

I recently responded to a question on an online discussion that asked “Are there companies that use Agile and Six Sigma?”.  This raises an interesting question of “Are Agile and Six Sigma really complementary to each other?”. How would you go about blending the two approaches?

Are Agile and Six Sigma Really Complementary to Each Other?

Agile and Six Sigma – Potentially Conflicting Approaches

There are numerous approaches that might conflict with each other such as:

  • Agile and Six SIgma,
  • Lean and Agile, and
  • Agile and Waterfall

Those approaches have different objectives. If you pursued these approaches individually and independently of each other, the objectives of each approach might be somewhat contradictory. However, if you do it intelligently, it is very possible to blend these approaches in the right proportions.  

  • That requires a lot more skill and
  • It requires a different kind of thinking to see them as complementary rather than competitive approaches

The Fundamental Problem

There is a significant fundamental problem that must be overcome to see all of these approaches in a different perspective:

  1. Companies and individuals get enamored with a methodology like Agile or Six Sigma and see it as a “silver bullet” solution to any problem that they might have
  2. They attempt to mechanically force-fit their business to one of those methodologies without fully understanding the principles behind it

An Example With Six Sigma

When I published my first book in 2003, Six Sigma was very hot and everyone wanted to “jump on the Six Sigma bandwagon”.  At that time, I researched a number of companies that were doing Six Sigma and other process improvement methodologies. What I saw was this:

Successful Companies

In companies that seemed to do Six Sigma successfully:

  1. It wasn’t even obvious that it was Six Sigma and they might not have even called it “Six Sigma”:
    • The implementation wasn’t limited to Six Sigma
    • They understood the principles behind Six Sigma, and
    • Might have blended Six Sigma with other process improvement methodologies, and
  2. It was very well-integrated with their business:
    • It was just a tool that was part of their business
    • Rather than a program that was superimposed on their business
Less-Successful Companies

In other companies, I saw a much more superficial implementation of Six Sigma that didn’t last in many cases:

  • There was a lot of emphasis on the “mechanics” of doing Six Sigma,
  • There was a lot of “hoopla” about the ceremonies associated with Six Sigma. (green belts, black belts, etc.), and
  • They openly advertised that they were using Six Sigma to promote themselves

Does that sound familiar?  I think a similar thing is going on with Agile today.

The Key Factor for Success

What I learned from that some of the key factor for success are:

  • Don’t get overly enamored with any methodology (Six Sigma or anything else):
    • Don’t think of it as a “silver bullet” for any problem you might have.  
    • Be objective and recognize that any methodology has advantages and limitations depending on the problem you’re trying to solve,
  • Adapt the methodology to fit the problem and the business environment rather than force-fitting your business to some predefined methodology, and
  • Go beyond simply doing a mechanical implementation of any methodology (Agile or Six Sigma) and understand the principles behind it at a deeper level

Are Agile and Six Sigma Really Complementary To Each Other?

On the surface, Six Sigma and Agile would tend to pull you in different directions:

  • Agile emphasizes creativity and innovation as well as flexibility and adaptivity to maximize the business value of the solution
  • Six Sigma emphasizes process standardization and control of a process to minimize process variation

The key to seeing these approaches as complementary rather than competitive is to understand the fundamental principles behind the approach at a deeper level rather than getting lost in the “mechanics” of the approach.

The essence of Six Sigma is attempting to standardize processes and reduce variation in processes.  If you became obsessive about pursuing that goal, it would also not be very consistent with being Agile. However, there is absolutely nothing wrong with attempting to standardize processes to some extent as long as it is also done intelligently and in balance with other objectives.

The importance of “Systems Thinking”

A fundamental skill for doing this successfully is “Systems Thinking”.
Systems thinking is essential for seeing these seemingly contradictory approaches in a much broader context. It enables you to see how these objectives can interact in complementary ways rather than being competitive. Here’s an article with more detail on “Systems Thinking”:

Overall Summary

It is very possible to blend together different approaches that are seemingly in conflict with each other as long as it is done intelligently. It requires:

  • Understanding the fundamental principles behind each approach rather than getting lost in the mechanics,
  • Using a systems thinking” approach to see these seemingly contradictory approaches in a different perspective. Systems thinking enables you to see how they might actually be complementary to each other rather than competitive, and
  • Learning to fit the methodology to the problem rather than force-fitting a problem to any given methodology

This is exactly the approach behind the Agile Project Management online training courses I’ve developed.

Additional Resources

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

What’s the Future of Project Management? What Do You Think?

What’s the future of project management? Is project management obsolete? 

  • I don’t think that “project management” is obsolete. However, I do think that some traditional roles of a “Project Manager” are becoming obsolete in projects that require a more adaptive approach
  • I also think that there’s a need to redefine what “project management” is if it is to continue to thrive in the future

There is a need to:

  • Separate the functions of “project management” from some of the traditional roles that have been played by a “Project Manager”, and
  • “Reinvent” the project management profession and develop a broader view of what “project management” is if it is going to continue to thrive and remain relevant in today’s world.
Future Project Management

Examples of Companies and Professions Reinventing Themselves

Any company or profession that doesn’t change and adapt to changes in the world around them runs the risk of becoming stagnant and no longer relevant. Here are a couple of examples:

American Express

American Express is a company that has been around for more than 150 years and has had to reinvent itself a number of times over that time. American Express started out in 1850 shipping boxes on railway cars. That business went very well for a while:

“For years it enjoyed a virtual monopoly on the movement of express shipments (goods, securities, currency, etc.) throughout New York State.”
(Wikipedia)

Can you imagine where American Express would be today if it still defined its business primarily around shipping boxes on railway cars? American Express has continued to reinvent itself over-and-over again to remain a vibrant and competitive company.

Quality Management

In the early 1990’s I worked in the Quality Management profession with Motorola. Prior to that time,

  • Quality Management was heavily based on a quality control approach that relied on inspectors to inspect products for defects
  • That process was very reactive and inefficient and companies like Motorola began implementing a much more proactive approach to quality management that was based on eliminating defects at the source rather than finding and fixing them later

That caused a major transformation in the Quality Management profession. Instead of being in control of quality through quality control inspectors,

  • Quality Managers had to learn to distribute some responsibility for quality to the people who designed and manufactured the product and play more of a consultative and influencing role.
  • When I worked for Motorola in the early 1990’s,  my manager used to tell me that “Our job is to teach, coach, and audit – in that order“.

That turned out to be a much more effective approach but it was a gut-wrenching change for many people in the Quality Management profession who were used to being the ones who owned responsibility for quality and were in control of quality.

How Does This Relate to Project Management?

For many years, the project management profession has been dominated by an approach that emphasized planning and control.

  • A project was deemed to be successful if it delivered well-defined project requirements within an approved budget and schedule.
  • That approach hasn’t changed significantly since the 1950’s and 1960’s but
  • We live in a different world today

There are two major factors that are creating a need for a different approach to project management in today’s world:

Levels of Uncertainty

There is a much higher level of uncertainty because problems and solutions tend to be much more complex: 

  • This is particularly true of large software systems.
  • With a high level of uncertainty; it is difficult, if not impossible, to define a detailed solution to the problem prior to the start of the project.  

The example I use in my training is “finding a cure for cancer”. 

  • Can you imagine attempting to develop a detailed project plan for that kind of effort? 
  • There is just too much uncertainty

Instead of getting bogged down in trying to develop a detailed project plan upfront, it would be much better to get started and use an iterative approach to attempt to converge on a solution as the project is in progress.

Increased Emphasis on Creativity and Innovation

In many areas, competitive pressures require a significant level of innovation in new product development. 

  • In these areas, creativity and innovation are much more important than planning and control. 
  • For example, think of what a company like Apple has to do to develop a new iPhone. 
  • Do you think that they start with a detailed plan based on some well-defined requirements?  I don’t think so.

What is Agile Project Management?

An Agile Project Management approach is ideally-suited for a project that:

  • Has a high level of uncertainty, or
  • Requires an emphasis on creativity and innovation rather than an emphasis on planning and control.

However, it is not limited to projects that are 100% Agile.

  • An Agile Project Management approach is applicable to a broad range of projects and
  • An Agile Project Manager needs to know how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation

Where Does Project Management Fit in Scrum?

In a Scrum project at the team level, you may not find anyone with the title of “Project Manager” but there is actually a lot of project management going on. At the team level, many functions that might normally be performed by a Project Manager have been distributed among other roles. Here’s an article with more detail on that:

What Needs to be Done to Adapt to This New Environment?

In today’s world:

  • There are many project managers who have been heavily indoctrinated in a traditional plan-driven approach to project management who might attempt to force-fit all projects to that kind of approach
  • There are also many project managers who are used to a project management approach that relies heavily on well-defined document templates and checklists to define how the project is managed

Some project managers will need to upgrade their skills to a higher level because there is typically no project manager role at the team level in an Agile/Scrum project

  • We all need to adopt a broader view of what “Project Management” is that is not limited to traditional plan-driven project management
  • Project managers need to learn how to blend an Agile (adaptive) approach with a traditional plan-driven approach in the right proportions to fit the nature of the problem
  • Force-fitting all projects to a traditional plan-driven project management approach is not likely to be very successful

This new environment “raises the bar” considerably for project managers and requires a lot more skill.  It is not a simple matter of filling in the blanks in well-defined project templates and following project checklists based on PMBOK®.

What Has Been Done to Transform the Project Management Profession?

PMI® has begun to recognize the need to deal with this challenge and has made steps in that direction but much more needs to be done:

PMI-ACP Certification

The PMI-ACP® certification is a step in the right direction but it doesn’t go far enough in my opinion. 

  • It recognizes the need for project managers to have an understanding of Agile and Lean but it is only a test of general Agile and Lean knowledge
  • It doesn’t really address the big challenge that project managers have of figuring out how to blend those approaches with a traditional plan-driven approach to project management.

PMBOK and Integrated Approach

PMI® still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two. PMBOK® version 6 has added material on how the various sections of PMBOK® might be applied in an Agile environment but that also doesn’t go far enough in my opinion.

Agile Project Management Training

Much of the training that is available to project managers today on Agile only addresses the basics of Agile and Scrum. 

  • You have to understand the principles behind Agile and Scrum at a much deeper level to understand how to successfully adapt those approaches to different kinds of projects. 
  • You can’t just do Agile and Scrum mechanically.

Overall Summary

Project Management certainly isn’t obsolete but the “handwriting is on the wall” that change is definitely needed for the profession to continue to grow and thrive.

We need to go beyond these steps and “reinvent” what “project management” is. Here’s an article I wrote with more on that subject:

Additional Resources

I am very passionate about helping the project management profession recognize the need for this transformation.  That’s the essence of the three books I’ve published on Agile Project Management and of the online Agile Project Management training that I have developed.

Improving Team Performance – How Do You Improve Team Performance in a Project Environment?

A number of people have asked questions related to improving team performance. It takes some skill to do that – “How do you improve team performance in a project? 

Improve Team Performance

Improving Team Performance

How to Improve Team Performance

It is very common for project managers to over-manage teams and I think that is a mistake. A team is like a dynamic organism:

  • Rather than simply putting pressure on the team to improve performance, a better approach is to understand the dynamics of how a team performs. You can then work on the factors that impact improving performance
  • An even better approach is to help the team become self-organizing and take responsibility for improving their own performance

What is a Self-organizing Team?

Here’s a good definition of a self-organizing team from the Scrum Alliance web site:

“A group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands”

The diagram below shows a comparison of a traditional project team and a self-organizing team:

What is a Self-organizing Team

Does This Mean Abdicating all Responsibilities to the Team?

The principles behind empowered teams can be used in any project. It is just different levels of empowerment.  The diagram below shows a comparison of different levels of empowerment:

How Do You Improve Team Performance

Here’s a description of each of these levels:

LevelDescription
Manager-led TeamThe lowest level of empowerment is a “manager-led team”. In that environment, the only responsibility delegated to the team is for managing the execution of tasks that they are responsible for.
Self-governing TeamAt the other extreme is a “self-governing team” where the team takes complete responsibility for their operations including setting their own direction. It would be unlikely to find that level in a project team but you might find a senior management leadership team that operated that way.
The two levels below are more typically found in an Agile environment:
Self-managing TeamA “self-managing team” takes responsibility for monitoring and managing work process and progress.
Self-organizing TeamA “self-organizing team” goes beyond that and takes responsibility for designing the team including defining roles within the team and defining the organizational context of how the team operates.

An important point is that “self-organizing” does not mean that a team does not need any direction at all. Self-organizing teams should not be used as an excuse for anarchy.

What Are the Advantages of Empowered Teams?

There are a number of advantages of empowered teams:

  • Empowered teams more fully utilize the capabilities of the people on the team
  • They reduce the need for someone to directly manage all aspects of how the team operates
  • They improve team performance because the team takes more responsibility for managing its own performance
  • Team performance is more sustainable because the performance of the team is more self-correcting
  • It encourages creativity and innovation and enables the team to quickly adapt to new problems and challenges

Comparison of Agile and Plan-driven Approaches

There can be a big difference between an Agile environment and a traditional plan-driven environment.

1. Traditional Plan-driven Projects

In a traditional plan-driven project team, a Project Manager or Team Leader typically provides direction to the team:

  • The project manager is the one who is held responsible for the performance of the team and the results that they produce, and
  • Some level of control may be needed to manage conformance to the project plan

However, even in that kind of environment, it is essential to delegate some level of responsibility to the members of the team.

2. Agile Projects

In an Agile project,

  • There is a much higher level of emphasis on creativity and innovation rather than conformance to a plan
  • In that kind of environment, it is very important to fully empower all the members of the team to actively contribute to the solution as much as possible

In an Agile environment, there may not be a project manager involved at all at the team level:

  • If a project manager is involved at that level, he/she needs to be more of a coach to help the team improve its own performance.
  • However, there is no reason why the idea of empowered teams is limited to an Agile environment
  • The same ideas can be applied in a traditional plan-driven environment; however, it may involve somewhat less empowerment

Overall Summary

Project Managers have a tendency to over-manage the performance of teams because the perception is that is what a Project Manager or Team Leader is supposed to do.

  • However, in many cases, simply putting pressure on the team to improve performance may not be effective
  • A more proactive and more sustainable approach is to better understand how the team functions as a dynamic organism. You can then work on the factors that drive performance.

Additional Resources

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

What Is Servant Leadership and How Does It Relate to Agile?

“Servant Leadership” is a commonly-used term in an Agile environment. However, if you asked people what it means, I’m sure you would get a number of different responses. For that reason, I think it is worthwhile to discuss “What Is Servant Leadership?”

What is Servant Leadership?

What Is Servant Leadership?

“Servant leadership” sounds like a manager who does nothing but get coffee, donuts, and pizza for the Agile team. Is that what it really is? (I don’t think so). The phrase “servant leadership” was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970 long before Agile came into being.   Here’s a definition of “servant leadership”:

“Servant leadership is characterized by leaders who put the needs of a group over their own. These leaders foster trust among employees by holding themselves accountable, helping others develop, showing appreciation, sharing power and listening without judging. While serving and leading seem like conflicting activities, these leaders are effective initiators of action.”

http://www.ehow.com/list_6753156_servant-leadership-games.html?ref=Track2&utm_source=IACB2B

A “servant leader” doesn’t necessarily completely abdicate the leadership role and do nothing but get coffee, donuts, and pizza for the team.  He/she recognizes the importance of working through others and engaging and empowering others to use as much of their own capabilities as possible.  Here’s an excellent quote on that:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons?

A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong”

Greenleaf Center for Servant Leadership

What is Servant Leadership?

What Does it Really Mean to be a Servant Leader?

A major leadership principle that is applicable to any leadership role is that there is no single leadership style that works in all situations. A good leader should be capable of taking an adaptive and situational leadership approach that is appropriate to the people and the environment he/she is trying to lead.

With regard to servant leadership, the way the servant leader role is implemented will be very dependent on the capabilities of the Agile team you are leading and the environment you are part of. The goal should be to maximize the utilization of the capabilities of the entire team. However, that doesn’t mean a servant leader completely abdicates a leadership role and turns over all responsibility to the team. Determining the most effective servant leadership role requires some judgement:

  • If the team is very strong and very capable, the role of the servant leader may be limited to a facilitation role
  • If that is not the case, a more active leadership role may be needed by the servant leader

Basically, the servant leader needs to “fill the cracks” as much as possible to help the team become fully effective on their own.

Why Is This Important in Agile?

The idea of “servant leadership” is particularly important in an Agile environment because an Agile approach is best suited for projects with a high level of uncertainty.  In that kind of environment,

  • A lot of individual creativity may be needed to find an optimum solution and
  • Maximizing the creativity of the team requires that the team be empowered as much as possible.

It is basically a softer leadership style that puts an emphasis on empowering others over a more controlled approach.  It is ideal for a highly uncertain environment that requires an adaptive Agile approach.  Naturally, it probably would not be so ideal for a more plan-driven environment where conformance to a plan is important.

Additional Resources

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

What is Emotional Intelligence and Why Is It Important?

I recently created a significant training module on Agile Leadership. One of the key topics in that module is “Emotional Intelligence”.  I’m sure some people are wondering “What is emotional intelligence and why is it important?”  I’d like to summarize some of that here.

What Is Emotional Intelligence?

First, here’s a definition of “emotional intelligence”:

“Emotional intelligence is the ability to identify and manage your own emotions and the emotions of others. It is generally said to include three skills:

  • “Emotional Awareness
  • The ability to harness emotions and apply them to tasks like thinking and problem solving; and
  • The ability to manage emotions, which includes regulating your own emotions and cheering up or calming down other people”

https://www.psychologytoday.com/basics/emotional-intelligence

What Is Emotional Intelligence and Why Is It Important?

Why Is It Important?

Emotional intelligence is one of the most important skills of an effective leader. The reason that emotional intelligence is so important to leadership is that if you can’t control your own emotions; it will be difficult, if not impossible to be an effective leader.

Here’s a quote that sums up the value of emotional intelligence very well:

“We probably also know people who are masters at managing their emotions. They don’t get angry in stressful situations. Instead, they have the ability to look at a problem and calmly find a solution. They’re excellent decision makers, and they know when to trust their intuition.

“Regardless of their strengths, however, they’re usually willing to look at themselves honestly. They take criticism well, and they know when to use it to improve their performance.”

https://www.mindtools.com/pages/article/newCDV_59.htm

What Are the Benefits of Emotional Intelligence?

Here are some of the key benefits of developing emotional intelligence:

AreaImpact
Increased Leadership AbilityYour leadership approach will be based on sound, rational principles rather than being dominated by emotional responses
Increased Team PerformanceTeam members will feel much more comfortable and secure in a non-threatening team environment with no hidden agendas
Improved Decision-makingDecisions are made more objectively and rationally
Decreased Occupational StressThere will be less emotional tension involved in the work environment
Reduced Staff TurnoverThere will be fewer emotional flare-ups
Increased Personal Well-beingLearning to accept yourself and gain control of your emotions can lead to a much happier life

How Do You Improve Emotional Intelligence?

The following tips have been reproduced from the Mind Tools web site:

1. Observe How You React to People

“Do you rush to judgement before you know all the facts? Do you stereotype? Look honestly at how you think and interact with other people. Try to put yourself in their place, and be more open and accepting of their perspectives and needs.”

2. Look at Your Work Environment

“Do you seek attention for your accomplishments? Humility can be a wonderful quality, and it doesn’t mean that you’re shy or lack self-confidence. When you practice humility, you say that you know what you did, and you can be quietly confident about it. Give others a chance to shine – put the focus on them, and don’t worry too much about getting praise for yourself.”

3. Do a Self-Evaluation

“What are your weaknesses? Are you willing to accept that you’re not perfect and that you could work on some areas to make yourself a better person? Have the courage to look at yourself honestly – it can change your life.”

4. Examine How You React to Stressful Situations

“Do you become upset every time there’s a delay or something doesn’t happen the way you want? Do you blame others or become angry at them, even when it’s not their fault? The ability to stay calm and in control in difficult situations is highly valued – in the business world and outside it. Keep your emotions under control when things go wrong.”

5. Take Responsibility for Your Actions

“If you hurt someone’s feelings, apologize directly – don’t ignore what you did or avoid the person. People are usually more willing to forgive and forget if you make an honest attempt to make things right.”

6. Examine How Your Actions Will Affect Others

“Before you take those actions. If your decision will impact others, put yourself in their place. How will they feel if you do this? Would you want that experience? If you must take the action, how can you help others deal with the effects?”

Why Is This Particularly Important to Agile Project Management?

Check out my previous article on Agile Leadership and I think you will understand why effective leadership is extremely difficult and so important in an Agile environment with high performance teams.  Agile is based heavily on transparency and openness and if you can’t be open and transparent about who you are as a person, you will have a difficult time being effective in an Agile environment.

Overall Summary

Self-awareness is one of the biggest components of emotional intelligence.  Many people aren’t even aware of who they are as a person and don’t reveal that to others.  They live their lives behind a facade that is based on projecting an image of who they are to others that may not be very genuine and others can employees can see through that easily.

When I was a young manager many years ago, self-awareness training was a standard part of many companies’ management training curriculum.  

  • The idea was that, to be an effective leader, its important to be genuine and open with others and you can’t do that without self-awareness
  • Unfortunately, over the years, companies have cut back on that kind of training.  It was seen as frivolous and not essential and as pressure has mounted to reduce cost of operations, a lot of that kind of training has been cut

Additional Resources

I can’t really directly help you develop emotional awareness in my online training; however, I’ve added two new sections and twelve additional lessons on Agile Leadership and Emotional Intelligence in my online training that I think will be helpful to you to better understand how to develop an effective leadership strategy.

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

What’s Really Different About Agile Leadership?

I just finished developing some online training on Agile Leadership and What’s Really Different About Agile Leadership? This article is a brief excerpt of that training.

Agile Leadership

Leadership Stereotypes

They’re are lots of stereotypes and myths in this area – here are a few of them:

  • Project Managers only know how to do a “command-and-control” style of management
  • Agile requires a “servant leadership” approach which means that you completely abdicate the leadership role

Those stereotypes generally follow many of the stereotypes that people have about “Agile” and “Waterfall”. They see them as binary and mutually-exclusive choices with nothing in the middle of those extremes.  Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem. Sometimes that requires a blend of the two approaches.

Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem and sometimes that requires a blend of the two approaches.

Agile Leadership – Fitting the Leadership Style to the Nature of the Problem

You can make some similar observations about leadership style:

  • A good leader doesn’t have one well-defined style of leadership that he/she force-fits all situations to.
  • A good leader recognizes that different styles of leadership are needed in different situations. That’s what “situational leadership” is all about

Another important observation is that the leadership style that is most appropriate in a given situation is directly related to the nature of the project and the problem solving approach.  Here’s how I see the relationship:

What's Really Different About Agile Leadership?

The nature of the problem shapes the management objective and

  • The management objective shapes the problem solving approach
  • The problem-solving approach  determines the leadership style that may be most appropriate

Comparison of Different Environments

The table below shows some important differences between a traditional plan-driven environment and an Agile environment. The table shows the characteristics in each environment that might have some impact on the overall leadership approach.

General Characteristics and Problem-Solving Approach

<
AreaPlan-driven EnvironmentAgile Environment
General Characteristics Projects that have a relatively low level of uncertainty and require some level of predictability might lend themselves to more of a plan-driven approach to project management.

An important characteristic that differentiates this kind of project is that it is assumed to be possible to define the general solution to the problem with some level of certainty prior to the start of the project.

Projects that have a higher level of uncertainty typically require a more flexible and adaptive approach to arrive at the solution as the project is in progress.>

In an Agile project, both the solution and the process for finding the solution might evolve as the project is in progress.

Problem-Solving Approach A defined problem-solving approach is what is typically used. The solution to the problem is generally well-defined in advance and the general approach for implementing the solution is also fairly well-defined. An Agile project uses a empirical process control approach. The word “empirical” means “based on observation” which means that both the definition of the solution as well as the process to discover the solution will evolve based on observation throughout the project.

Management Objective and Leadership Approach

AreaPlan-driven EnvironmentAgile Environment
Management Objective Predictability is normally important. Achieving predictability requires a well-defined plan and conformance to the plan and some level of emphasis on control are also important. Arriving at an effective solution is far more important in this kind of project than predictability. Therefore, innovation and creativity would generally be emphasized more than control.
Leadership Approach The style of leadership naturally might be a bit more directive in order to remain on track with the project plan. You certainly don’t want members of the project team running loose in all different directions without some kind of plan that integrates all of their efforts together that is consistent with the overall plan. A different leadership style is typically called for. If you want to encourage creativity and innovation, you don’t want to emphasize control, you want to empower people and give them some flexibility to use their own intelligence and judgement to explore alternatives as necessary to find the best solution.

Polarized Viewpoints

There are a lot of very polarized viewpoints in this area that go something like this:

  • Agile is good and
  • Waterfall is bad

Or alternatively:

  • Command-and-control management is bad and
  • Agile Servant Leadership is good

Those polarized points of view tend to over-simplify what is not quite so simple. It not as simple as drawing a black-and-white comparison between two extremes. 

  • There are lots of “shades of gray” in both the problem-solving approach and the leadership style that is most appropriate for a particular situation. 
  • An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any given situation.

Overall Summary

Here’s a summary of some key points:

  • There is not just one leadership style that fits all situations
  • Leadership styles are not necessarily good or bad. Saying a particular leadership style is good or bad is like saying “a car is better than a boat”.  Each has advantages and disadvantages depending on the environment you’re in.
  • Agile leadership is not really a radically different style of leadership. It is not totally separate and mutually-exclusive with other leadership styles. However, it significantly expands our definition of what “leadership” is.

Additional Resources

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

Blending Agile and Traditional Project Management