Category Archives: Agile Project Management

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

“Servant Leadership” is a commonly-used term in an Agile environment but 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 and How Does It Work in Agile?”

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.”

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”

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 but 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.

To learn more about “Servant Leadership” and “Agile Leadership” in general, check out my Advanced Agile Project Management course. I’ve just added twelve new lessons on Agile Leadership to the course.

What is Emotional Intelligence and Why Is It Important?

I just finished creating a significant training module on Agile Leadership and 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.”

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.”

What Are the Benefits of Emotional Intelligence?

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

  • Increased leadership ability because your leadership approach will be based on sound, rational principles rather than being dominated by emotional responses
  • Increased team performance because team members will feel much more comfortable and secure in a non-threatening team environment with no hidden agendas
  • Improved decision-making because decisions are made more objectively and rationally
  • Decreased occupational stress because there will be less emotional tension involved in the work environment
  • Reduced staff turnover because there will be fewer emotional flare-ups
  • Increased personal well-being because learning 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 (

  • 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.”
  • 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.”
  • 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.”
  • 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.”
  • 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.”
  • 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.

How Can I Learn More to Improve My Skills?

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 company’s 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.

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.  Check out the enhancements I’ve just completed in my Advanced Agile Project Management course.

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.

What’s Really Different About Agile Leadership?

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 seeing “Agile” and “Waterfall” 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 and sometimes that requires a blend of the two approaches.

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

Real-world Examples

Here’s how that might work out in different environments:

  1. Traditional Plan-driven Project Environment – 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.
    • Problem-solving Approach – In that 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.
    • Management Objective – If predictability is important, having a well-defined plan and conformance to that plan are also important.  Naturally, that requires some level of emphasis on control.
    • Leadership Approach – That calls for a style of leadership that 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.
  2. Agile Project Environment – Projects that have a high level of uncertainty generally lend themselves to a more Agile project management approach where the final definition of the solution is expected to evolve as the project is in progress rather than being well-defined upfront prior to the start of the project.
    • Problem-Solving Approach – This type of 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 – 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 Style – This type of project obviously calls for a different leadership style.  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.

Overall Summary

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 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.

  • 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 that is totally separate and mutually-exclusive with other leadership styles; however, it significantly expands our definition of what “leadership” is.

I’ve developed a significant amount of new content for my Advanced Agile Project Management online training course that goes into this in a lot more depth.

What is Project Management? Is it Mutually-exclusive with Being Agile?

I recently participated in an online discussion where someone made the statement that “Project Management and Scrum have nothing to do with each other. In fact, they mutually exclude each other.” I want to share my response with you because I think there is an important issue about rethinking “What is Project Management?”

What is Project Management? – A Narrow View

That view of project management is based on a very popular and widely-held stereotype about what “project management” is:

  • “Project management” is something that is only done by a single person called a “Project Manager”
  • There is only one way to do “project management” and that is using a traditional plan-driven methodology (what many people loosely call “Waterfall”)
  • “Project management” is completely incompatible with an Agile approach because an Agile approach must be dynamic and adaptive and project management emphasizes control and is inflexible

That’s a very narrow view of what “project management” is; however, that view is widely-held by a lot of people and the project management community has not done enough to change that perception:

  • 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
  • Many project managers are heavily indoctrinated in a traditional plan-driven project management approach and see that as the only way to do project management

If you look at the official PMBOK definition of “project management”, it is very consistent with that narrow view of what project management is:

“The application of knowledge, skills, tools and techniques to the project activities to meet project requirements” – (PMBOK version 5)

That definition implies that “project management” is mainly concerned with planning, organizing, and managing project activities to meet defined requirements. Which is exactly how a traditional plan-driven project works but it is not consistent with how an Agile/Scrum project works.

What is Project Management? – A Broader View

If you look at how an Agile/Scrum project works, there is actually a lot of “project management” going on but many people will not recognize it as “project management” because it doesn’t fit with the traditional stereotype of what “project management” is:

  • In an Agile/Scrum project you may not find anyone at the team level with the title of “Project Manager”
  • The project management functions that would normally be done by a single person called a “Project Manager” are distributed among all the members of the Agile team. For example:
    • Developers – All members of the project team are expected to take responsibility for planning and completing the tasks that they are responsible for to meet commitments that they have made. They are also expected to report progress and coordinate their work with other members of the team as necessary.
    • Scrum Master – The Scrum Master is expected to facilitate team meetings and take action to remove any obstacles if necessary
    • Product Owner – The Product Owner is expected to make any decisions or tradeoffs that might be needed to meet the project goals

    Those are all functions that would normally be performed by a project manager if there was one; they are simply distributed across a number of roles rather than being performed by a single person called a “Project Manager”.

  • It doesn’t use a traditional plan-driven approach to project management – the requirements may not be well-defined at the beginning of the project and it uses a more adaptive approach to further refine the requirements as the project is in progress

Does that mean that there is no “project management” going on?  I don’t think so – it’s just a different kind of “project management” that doesn’t fit the typical narrow stereotype that many people have of what “project management” is.

Here’s what I think a broader definition of “project management might look like:

“Project Management is the application of knowledge, skills, tools, and techniques to accomplish a meaningful objective and maximize the value that the project produces.”

What’s Different?

Here are a couple of key areas of difference that I believe are important:

  • My definition of project management doesn’t say anything about defined requirements.  It is based on a broader idea that a project manager should be able to be given a broadly-defined business objective and figure out what is needed to achieve that objective
  • The goal of a project manager should also be to produce business value, not just meet cost and schedule goals for delivering defined requirements.  There have been many traditional plan-driven projects that have met their cost and schedule goals but failed to deliver business value and they were still considered successful from a project management perspective

Why is this Important?

Many of the traditional notions of what “project management” is have their roots in the 1950’s and 1960’s and the fundamental nature of what “project management” is has not changed significantly since that time. We live in a different world today from what existed in the 1950’s and 1960’s:

  • Technology is rapidly changing
  • Solutions are much more complex
  • There is a much higher level of uncertainty in many projects
  • Time-to-market is extremely critical to keep pace with competition

Attempting to force-fit all projects to a traditional plan-driven model that hasn’t changed significantly since the 1950’s and 1960’s is probably not going to result in an optimal solution.  You have to fit the project management approach to the nature of the problem and that calls for a broader range of project management approaches not limited to traditional plan-driven project management.

The key message is that you need to fit the project management approach to the nature of the problem rather than force-fitting all projects to a single project management approach.

An Integrated and Dynamic Approach to Project Management

I think of this as an “integrated and dynamic” approach to project management:

  • It’s integrated because project management is fully integrated into the way the team works rather than being done by a single person called a “Project Manager”
  • It’s dynamic because the nature of the project management approach isn’t limited to a traditional plan-driven approach to project management.  It is expected that the project management approach will be adapted to fit the nature of the situation

I think you can see that if your objective is control, a traditional plan-driven approach to project management of putting one person called a project manager in control of a project might be a good approach; however, an emphasis on control can be inflexible and doesn’t work well in an uncertain environment that requires a more adaptive approach. We need to adapt the approach to fit the nature of the project and the level of uncertainty in the project is a major factor in choosing the right approach.

Transforming the Project Management Profession

Dealing with this challenge really requires a major transformation of the project management profession, in my opinion.

What is Project Management?

Here are some fundamental things that need to be done:

  1. We need to think of “project management” in broader terms than thinking that traditional plan-driven project management is the only way to do project management
  2. Project managers need to be trained in how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation
  3. We need to recognize that “project management” is a function, not a title, and the function of “project management” is not always exclusively performed by someone called a “Project Manager”

I’ve Been Here Before

There is a feeling of deja vu about this to me.  I’ve been here before.  In the early 1990’s, I worked in the Quality Management profession at Motorola.  Motorola was a leader at that time in developing a new approach to quality management.  The old approach to “quality management” was something like this:

  • There was a heavy emphasis on control.  Someone called a “Quality Manager” had responsibility for controlling the quality of the products being built.
  • The quality management approach relied heavily on  inspectors who enforced standards of quality through inspection of products before they shipped

The flaws in that approach should be obvious:

  • Relying heavily on inspection to find defects can result in a significant amount of rejects and rework – a far better approach is to go upstream in the process, remove the source of defects, and make the process that produces the products inherently reliable
  • Putting responsibility for quality in the hands of a single person or organization makes the employees who are responsible for producing the product feel that “quality is someone else’s responsibility”.  A far better approach is to engage everyone in the quality management functions so that everyone involved in producing a product feels that they are directly responsible for the quality of the products they produce

A similar thing could be said about project management today – putting all project management responsibility in the hands of someone called a “Project Manager” makes the workers feel like “project management” is someone else’s responsibility.  A far better approach in a complex and uncertain environment is to engage everyone in “project management” so that it is a shared responsibility among everyone on the team to make the project successful.

What are the Most Practical Ways to Do Project Planning?

I recently participated in an online discussion in response to a question that was asked on “What are the most practical ways to do project planning?” It’s a critical issue and it comes up a lot so I thought I would share some thoughts on this subject.

Factors to Consider

In my opinion, there are two very significant factors in determining what planning approach would make the most sense for a particular project:

  1. Uncertainty – The level of uncertainty in the project is probably the most important factor.  If there is a high level of uncertainty that cannot easily be resolved, it would probably be foolish to try to develop a highly-detailed, plan-driven approach.  An example would be attempting to find a cure for cancer.  It would probably be foolish to try to develop a detailed plan for that effort, there’s just way too much uncertainty.That doesn’t mean that you wouldn’t do any planning at all.  You would take stock of what you know and don’t know and try to develop at least a cursory plan based on that information and then continually revise the plan based on what you learn as the project is in progress.
  2. Customer Relationship – The second major factor is the relationship with the customer.   If you have a contractual relationship with the customer where the customer is expecting a firm set of deliverables for a given schedule and cost, you might be forced into a planning model to try to effectively manage and satisfy those customer expectations.  If there is more of a collaborative relationship with the customer, you probably have a lot more ability to optimize the approach based on the level of uncertainty in the project.

Planning Quadrants

Obviously, there may be a conflict between these two factors.  I’ve created a diagram below to show some of the possible combinations of these two factors:

What are the most practical ways to do project planning?

Lets look at each of these quadrants individually:

  1. Low Uncertainty, Contractual Relationship – This is the area that most project managers are most familiar with and it is the area that is most well-suited for a traditional plan-driven project management model.  In this area, the level of uncertainty may be low enough to permit developing a detailed plan that is consistent with managing customer expectations in a contractual relationship model.
  2. Low Uncertainty, Collaborative Relationship – If the level of uncertainty associated with a project is low, you might develop a more collaborative relationship with the customer but that might not be the most efficient way to do the project.  If the level of uncertainty is truly low and it is relatively easy to define the project requirements upfront, it may not make too much sense to engage the customer too heavily in a collaborative relationship to further define detailed direction for the project as it is in progress.
  3. High Uncertainty, Collaborative Relationship – This is the area where an Agile approach makes sense but the success of that effort will generally depend on a collaborative relationship with the customer to make it work.  In this area, instead of trying to develop a highly-detailed upfront plan prior to starting the project, you would probably:
    • Reach agreement with the customer on at least a vision for the project and at least some higher level objectives and requirements that the project must meet, and
    • Then further elaborate those requirements and the plan for meeting them as the project was in progress

    It’s easy to see how this kind of planning model may not work well unless there’s a collaborative spirit of trust and partnership with the customer since:

    • It may be almost impossible to accurately define the costs and schedule for completing the project prior to starting the effort; and
    • Further defining the plan as the project is in progress requires a close working relationship with the customer.
  4. High Uncertainty, Contractual Relationship – This area is the quadrant that is likely to be most problematic:
    • Attempting to do an Agile project with highly uncertain requirements without a collaborative relationship with the customer is not likely to work very well:
      • The customer may not be committed to actively engage in the project as it is in progress to help elaborate and resolve questions related to the requirements; and,
      • As a result, the project may either get stalled or go off in the wrong direction
    • Attempting to apply a contractual, plan-driven approach in this kind of environment is also likely to be problematic. There would likely be a very high risk associated with trying to develop a firm, plan-driven contractual relationship based on highly uncertain requirements. What is likely to happen is:
      • The project meets the defined requirements but the defined requirements were wrong, or
      • There are so many changes as the project is in progress that the scope of the project winds up being completely different from what the customer was expecting

    It’s easy to see how either of these scenarios might present a very high risk.

Of course, this is somewhat of an over-simplification and all projects don’t fall very neatly into one of these quadrants.  There is a very broad range of scenarios in the middle of this diagram that call for some kind of hybrid approach.

What are the Most Practical Ways to Do Project Planning?

There are a number of conclusions that I think we can draw from an from understanding of this model:

  1. There is not just one way to do project planning – Project Managers who have been heavily indoctrinated in a traditional, plan-driven model and attempt to force-fit all projects to that kind of planning model are likely to not have optimal results
  2. This is not a simple binary and mutually-exclusive choice between an Agile and traditional plan-driven planning model; it is much more complicated than that.  There’s a whole spectrum of different possible scenarios and it is a multi-dimensional problem
  3. The right approach is to fit the planning model to the nature of the problem based on the level of uncertainty and the relationship with the customer.  Attempting to use a single “one size fits all” planning model for all projects is not likely to work very well.

This creates a big challenge for project managers to learn how to blend an Agile and traditional plan-driven approach in the right proportions to fit a given situation.  And, that’s not an easy thing to do – PMI still treats these two areas as separate and independent domains of knowledge with little or no integration between the two.  This is exactly the challenge that my Agile Project Management training is designed to address.

Is Agile and Scrum Anti-Engineering?

I recently participated in an online discussion on the topic of “Is Agile and Scrum Anti-Engineering?”.  This question seems to be based on a number of popular stereotypes that people have about “Agile” and engineering design practices.  For example, a popular stereotype is that an Agile project consists of just a bunch of “cowboy software developers” who get together and start writing code without any plan and discipline about how it is done.

Is Agile and Scrum Anti-engineering?

If you have that view, it’s easy to come to the conclusion that Agile is not a very sound approach to engineering at all because it doesn’t necessarily follow a well-planned and systematic engineering design approach but it would be a mistake to draw that conclusion.  If it is well-executed, an Agile approach requires a considerable amount of discipline and skill and it’s not “anti-engineering” – it is just a different kind of engineering.

Importance of a Systematic Engineering Design Approach

Let’s step back and look at when and where a well-planned,  systematic engineering design approach really makes the most sense.  That kind of approach is most important for problems that have a high level of technical complexity and the aim is to find an optimum solution as quickly and efficiently as possible:

“A systematic engineering design process model aims at making it easier to find an optimal design for a product-to-be. To that end it is necessary to encompass the broadest range of solutions, that is, to search for solutions in a structured, systematic way. The breadth-first top-down strategy is adopted,  which means first finding the largest possible number of abstract solutions (breadth-first) and then more concrete ones (top-down)”

A good example of that might be a very data-intensive application that might start with a high-level, conceptual design phase, proceed to a logical design phase, and then finally wind up with a detailed physical design of the solution.  To do that efficiently, you will want to stabilize the requirements as early as possible because each phase cascades into the next.  You don’t want to get all the way into the detailed physical design and discover some of the critical assumptions made in the previous phases were wrong because it could require a significant amount of rework of the whole design.

However, there are many people who believe that a well-planned and systematic approach to engineering is the only way to do engineering.  Here’s an example:

“The design of complex, complicated or a family of products is usually beyond the intuitive skills alone of a designer or design team. Gerhard Pahl and Wolfgang Beitz [1] have set out a strategy for the development of solutions which aims to increase the probability of technical and economic success of product design. This is done by creating a dependable approach which allows careful planning and systematic execution so that the whole design task reduces to a logical and comprehensible exercise and also allows recovery from inevitable errors. It also allocates a time schedule for the design stages which in turn leads to a predictable project timetable. Systematic design is general enough to be applied in any branch of engineering.”

When Does a Systematic Engineering Design Model Make Sense?

That well-planned, systematic approach to engineering design has been the predominant approach to engineering design for a long time. It has proven to be a reliable and efficient process for converging on a design solution where the requirements are relatively well-defined and the technology is also relatively stable as shown in the Stacey complexity model below:

The primary question that the design team must answer in this environment is:

“Is this solution the most optimum design solution to the requirements for this problem?”

It is primarily a pure engineering design decision.

Why Doesn’t That Approach Work in Many Areas Today?

The major problem with that approach is that we live in a much more complex world with much higher levels of uncertainty today.  In terms of the Stacey complexity model, both the requirements and the technology associated with the solution might be much more uncertain.  In that kind of environment,

  • It is no longer a simple question of “Is this solution the most optimum solution to the requirements for this problem?” and
  • Its no longer limited to relatively straightforward engineering design decisions because the requirements themselves might be wrong and the assumptions about the technology might also be wrong

In an uncertain environment, the approach needs to be much more adaptive and involve some amount of “discovery” to determine what the requirements for the solution should be.  The approach should not be limited to just implementation of a predefined  solution.  There is also typically a lot of tradeoffs between the requirements for the solution and the technical implementation that optimizes both.   Converging on a solution to those requirements without considering those tradeoffs might not yield an optimal solution.

When that kind of situation has arisen in the past, a typical approach has been to do some amount of upfront prototyping to try to converge on the requirements of a solution before actually starting on the full-scale design and development effort.  That approach works in some cases but it isn’t the most efficient or the most effective approach if there is a large amount of uncertainty in the requirements.  If there is a large amount of uncertainty in the requirements, it may take multiple iterations to converge on the requirements for the design; and, for larger and more complex projects, there may be a number of different areas of uncertainty that need to be resolved.

That’s why an Agile approach can make a lot of sense for projects with a high level of uncertainty.  It’s not really “anti-Engineering”:

  • It’s a different kind of engineering approach that is different from a typical, well-planned, systematic engineering design approach,
  • It is much more appropriate for areas that have high levels of uncertainty

It’s important to recognize that Agile is not “cowboy engineering” – if it is done correctly it requires a lot of discipline and skill.

What Does This Mean For Project Management?

Project Management is not just an administrative task – project management needs to be designed around the most sensible engineering design approach for a given problem. Traditionally, the project management approach has been heavily-based on well-accepted engineering design practices that emphasize a well-planned, systematic engineering approach. As we rethink the way that engineering is done, we also need to develop new project management models that are also better aligned with higher levels of uncertainty.

Summary of Key Points

Here’s a summary of some key points from this article:

  • There  is an intimate relationship between project management processes and engineering design processes.
  • Many people have forgotten about that relationship and think of  project management as primarily an administrative management function to manage the execution of what many people loosely call “Waterfall”.
  • Project management is more than just an administrative function – it should be geared to effectively manage an underlying engineering design process.  And, that underlying engineering design process should be geared to the nature of the problem.
  • The underlying engineering design approach that has been assumed to be well-established for so many years can no longer be taken for granted as the only way to do engineering design.  It does not provide a sufficient level of flexibility and adaptivity for a highly uncertain environment.
  • Project management must adapt as well – it is no longer viable to force-fit all projects to a project management that is based on an underlying engineering design approach that has serious weaknesses in an uncertain environment.

The challenge for project managers is learning how to blend an iterative and adaptive Agile approach with a more traditional plan-driven approach in the right proportions to fit the nature of the project and one of the biggest factors in choosing the right approach is the level of uncertainty in the project.


What is a “Hybrid Agile” Approach? Is There Such a Thing?

What is a hybrid Agile Approach? Is there such a thing? I recently came across an article on the Internet that was posted in several places entitled “The Moment of truth: There Is No Hybrid Agile“. This article is so full of stereotypes and misconceptions about “Agile” and “Waterfall” that I felt that I had to respond to it.  It is typical of many articles that position “Agile” and “Waterfall” as two binary and mutually-exclusive alternatives with no middle ground between the two.

What Are the Flaws in This Thinking?

Here are some of the flaws in this thinking:

  1. This article and many others like it treat “Agile” and “Waterfall” as if they were individual, discrete methodologies and they position “Agile” and “Waterfall”  as diametrical opposites of each other.  That’s not very accurate.
  2. “Agile” and “Waterfall” are not really discrete, individual methodologies and both of those terms are used very loosely.  In common usage, neither of those are individual, discrete methodologies:

    • Many people  may think of “Agile” as being synonymous with Scrum but that is not really accurate.  “Agile” is much broader than Scrum – it is a way of thinking defined by the Agile Manifesto
    • “Waterfall” is also not a single, discrete methodology – in today’s world, many people use the term “Waterfall” for any plan-driven methodology that is not Agile.  What about RUP and other iterative approaches that probably wouldn’t be considered to be Agile?  Is that “Waterfall”?

    Instead of thinking of what people commonly call “Agile and “Waterfall” as individual discrete methodologies, it is more accurate to see it as a continuous spectrum of approaches from heavily plan-driven at one extreme to heavily adaptive at the other extreme like this:

    What is a hybrid agile approach?

    If you think of it in that way, it is much easier to see the possibility for lots of approaches in the middle of that spectrum that blend the right level of plan-driven principles and practices with more adaptive principles and practices to fit a given situation.

    Here’s what some methodologies would look like plotted on a spectrum of heavily plan-driven versus heavily adaptive:

    Adaptive vs Plan-driven

    As you can see from this diagram:

    • “Agile” is not a single approach and there is not just one way to do “Agile”:
      • Kanban is more adaptive than Scrum, and
      • Even within Scrum you will find different styles of implementation from simple team-level projects which may tend to be more adaptive to larger more complex multi-team projects which may tend to be somewhat more plan-driven
    • What people commonly call “Waterfall” is also not a single well-defined approach.
      • At one extreme, the original phase-gate model originally developed by Winston Royce in 1970 was very plan-driven but that approach is not widely-practiced any more in that form for software development
      • In the 1990’s and early 2000’s more iterative approaches such as RUP became much more popular for software development and provided a higher level of adaptivity
    • The most important point to get out of this is that there is not a clear and well-defined boundary line between “Agile” and what people commonly call “Waterfall” as many people seem to think.

  3. Many people make the mistake of performing a methodology mechanically and think they need to do it religiously and “by the book”(That’s true of both Agile and other non-Agile methodologies)
    • The right approach is to fit the methodology to the nature of the problem rather than force-fitting all problems to a given methodology (Agile or non-Agile).
    • It takes more skill to do that but it definitely can be done. It requires understanding the principles behind the methodology and why they make sense in a given situation rather than doing a given methodology mechanically.

    If you think of methodologies as being rigid and prescriptive, it will be difficult to see how two seemingly disparate methodologies could be blended together in the right proportions to fit a given situation. On the other hand, if you understand the principles behind the methodologies at a deeper level, it is much easier to see how they could be complementary to each other rather than competitive.

    Learning to be a “Chef”

    It can take a lot more skill to learn how to blend different approaches together in the right proportions to fit a given situation. In my book on Agile Project Management, I use the analogy of a project manager as a “cook” and a project manager as a “chef”.

    • “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.

    That’s the challenge for project managers and agile practitioners in today’s world – we need more chefs and fewer cooks.

What is a Hybrid Agile Approach?

In simple terms, a hybrid Agile approach is one that blends the plan-driven principles and practices with Agile (adaptive) principles and practices in the right proportions to fit a given situation. An example of that is the Managed Agile Development framework that I created. It simply wraps an outer layer of project-level planning around an Agile development process.

Managed Agile Development Framework

The outer layer can be as thick or thin as necessary to fit the situation. I originally developed this framework when I was managing a very large government program for a US government agency. The government agency had to have some level of predictability over the costs and schedules of the program. The program was so large that it actually had some level of congressional oversight so some level of predictability and control was essential; however, within that outer envelope, the government agency customer wanted to have flexibility in many of the detailed requirements. We were able to find the right balance of control and flexibility to satisfy both needs.

What Are Examples of Hybrid Agile Approaches?

Some of the most common examples of hybrid Agile approaches are:

  1. Agile Contracts
    • The government program I mentioned is a good example
    • I also have a case study in my book on General Dynamics UK, Ltd. who successfully used a hybrid Agile approach to manage a large defense contract for the ministry of defense in the UK
    • I just finished building a new house and I naturally had a contract with the builder that defined the cost and schedule for the home; however, the builder offered a lot of flexibility to make changes even as the construction of the house was in progress (He charges for changes, of course)
  2. Large, Enterprise-level Projects and ProgramsIt’s almost impossible to successfully implement some large complex enterprise-level projects and programs without integrating some level of project and program management. A good example of that is the Harvard Pilgrim Healthcare case study that is written up in my latest book. The project involved over 100 Agile teams and involved replacing almost everyone of HPHC’s most critical business systems over a period of time. The whole effort involved a lot of moving parts that had to be carefully planned and synchronized and it’s impossible to imagine how that could be done without a sufficient level of project and program management to guide and manage the overall effort.
  3. Other Business-driven Initiatives
  4. Many people have the mistaken belief that you need to force the entire company to be agile in order to adopt an Agile development approach. That isn’t necessarily true. A business has to be designed around whatever critical success factors are most important for the business that they’re in and becoming agile may not be the only factor and may not even be the most significant factor. For example, some companies are in very cost-competitive industries and succeed primarily based on operational excellence to lower their costs as much as possible. Becoming more agile may play an indirect role in that but it isn’t necessarily the most important factor. On the other hand, in a company that is technology-driven that succeeds on bringing leading-edge products to market as quickly as possible, it’s much easier to see how a pure Agile approach might be a very strong and direct driver of the business.

    Agile was originally developed for companies that do product development and that’s where it works best. In companies whose primary business is not developing products per se, there is typically more of a project-oriented approach. The company has to typically evaluate a potential portfolio of projects to determine what mix of projects and programs is going to have the greatest impact on their business and then they need to monitor the execution of those projects and programs to determine if it is really delivering the expected returns.

Why Are Tools So Important in an Agile Environment?

Have you ever thought about “Why Are Tools So Important in an Agile Environment?”. We all know that one of the very important values in the Agile Manifesto is “Individuals and interactions over processes and tools”. Some people might interpret that to mean that tools aren’t necessary or appropriate in an Agile environment. I don’t think that is the case but it’s important that they be used in the right context:

What’s the Right Context for Agile Tools?

  • In a traditional plan-driven environment (aka “Waterfall”), the process and the tool manages the efforts of everyone on the team
  • In an Agile environment, a lot more flexibility and adaptivity is needed so any tool that is used should play a supporting role rather than a controlling role

It’s important to understand that context in order to use tools appropriately in an Agile environment. The key idea is that

“You should manage the tool rather than the tool managing you”

Why Are Agile Tools So Important?

Why Are Agile Tools So Important?

As long as they’re implemented in the right context, I believe that tools are very important in an Agile environment for several reasons:

  • Agile projects are very dynamic and fast-moving and coordination of the efforts can be a challenge especially with distributed teams
  • Scaling Agile projects to large, complex enterprise levels and keeping the projects well-aligned with the business objectives they are intended to support can also be very challenging

How Are Agile Tools Different?

It’s also important to understand how Agile project management tools are very different from traditional plan-driven project management tools like Microsoft Project.

Traditional Plan-driven
PM Tool Emphasis
Agile PM Tool Emphasis
Structure of the project (WBS, Gantt, Pert, etc.) Maximizing flow of work and efficiency (Structure is considerably simplified, much more fluid, and not as important)
Tracking conformance to a plan baseline Much more dynamic environment; plan is continuously being updated and refined
Tracking completion of tasks Tracking delivery of value against a high-level road map
PM is the primary user of the tool The entire team uses the tool and the tool supports team communication and collaboration
Information in the tool is updated periodically by the PM for reporting purposes Information in the tool is updated in much more continuously by everyone on the team for coordination and tracking progress
PM prepares and distributes progress reports Anyone can view progress any time
(Information Radiator)

I’ve just finished adding two new sections and (13) new lectures to my “Mastering Agile Project Management” course to cover these topics. You can register for that course here:

Discounted Agile Project Management Academy Courses

University Project Management Curriculum With Agile

I had an interesting discussion with a major university about helping them develop an integrated university project management curriculum with Agile that included a master’s degree program in Agile Project Management. They correctly recognized that the world of project management is changing rapidly and they didn’t want to make a major investment in developing a project management curriculum based on an old and outdated notion of what “project management” is. I think they are absolutely correct in that; however, it isn’t totally clear how a master’s program in project management should be structured to reflect the evolution that I believe is going on in the project management profession today.

University Project Management Curriculum with Agile

Similarities Between Project Management and Modern Physics

We can learn a lot from how the science of physics has evolved because I think there are a number of interesting similarities to the evolution that is currently going on in project management. 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 phenomental success, as the Calculus of Newton and Leibniz gave it the tools to tackle even even problems not imagined by its pioneers.”

“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. It 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”

Simanek, Donald E., What’s Physics All About?,

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”

“Twenty-five years later, this complacency had been completely destroyed by the invention of three entirely new theories: special relativity, general relativity, and quantum mechanics. The outstanding figure of this period was Albert Einstein. His name became a household word for his development, virtually single-handedly, of the theory of relativity, and he made a major contribution to the development of quantum mechanics in his explanation of the photoelectric effect. “

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

How is This Transformation Related to 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. And 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. That is similar to classical physicists who believed for a long time that a model of the universe could be completely predicted based on some relatively simple and well-defined laws of classical physics. In recent years; however, it is apparent that we are in a much more dynamic and more complex universe with much higher levels of uncertainty where that traditional, plan-driven approach to project management no longer works well at all.

PMI is moving slowly towards recognizing the need to take a broader approach to what “project management” is; however, there are many project managers who still believe that traditional, plan-driven project management is the only way to do project management and there are some well-engrained stereotypes of what “project management” is that are also based on that notion. PMI has created the PMI-ACP certification that recognizes the need for project managers to know something about Agile and Lean; however, PMI still treats “Agile” and traditional, plan-driven project management principles and practices as separate and independent domains of knowledge with little or no integration between the two. It’s up to the individual project manager to figure out how to put the two together.

What Can We Learn from This Similarity?

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,

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


“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.”

Similarly, project managers also need to recognize that a traditional, plan-driven approach to project management only works reliably in a limited set of situations. In the project management world, this can be expressed with the 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 but 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 that 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

Implications for a University Project Management Curriculum with Agile

Just as “Modern Physics” is the integration of Classical Physics with a more modern approach to physics, I believe that there is a new vision of what “project management” is that integrates an Agile approach in the right proportions with a traditional, plan-driven approach. My view is that there is a “Modern Project Management” concept that is emerging that is analogous to the concept of “Modern Physics” that integrates these different approaches together in one discipline similar to the way that Physics has evolved. If someone were to get a Master’s degree in Physics today, it seems unlikely that the studies would be limited to Classical Physics with no mention of the other areas of Modern Physics. But that is, in fact, the way a number of universities have structured a Master’s Degree in Project Management program today. Universities need to move beyond that notion of project management and develop a much broader and well-integrated curriculum to address this need.

What’s Next After PMI-ACP Certification and What’s the Future Like?

What’s next after PMI-ACP certification? Over the past few years I’ve been progressively developing a new approach for PMI-ACP training that I think goes well beyond other training programs and lays the groundwork for what I see as the future of project management.

What's Next After PMI-ACP Certification?

Training Objectives

When I set out to develop this training, I wanted to try to anticipate the future of the project management profession and take a different approach to Agile Project Management and PMI-ACP Certification training. There were several objectives that were important goals:

  • Not a typical “exam prep” course. There are a lot of courses out there that are based on what I call an “exam cram” approach that is designed to get students through the PMI-ACP exam and not much more than that. It involves a lot of memorization of information which doesn’t generally lead to a deeper and lasting understanding of the material.
  • Go beyond the PMI-ACP exam. Although the PMI-ACP exam is a challenging exam, it doesn’t go far enough in my opinion. It is primarily just a test of general Lean and Agile knowledge and it doesn’t address one of the biggest challenges that a project manager faces of learning how to blend Agile and traditional, plan-driven project management in the right proportions to fit a given situation. 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. It is left up to the individual project manager to figure out how to put the two together.
  • Design the training around a real-world role. The PMI-ACP certification is not designed around preparing someone for a particular job role. I think it’s important for a project manager to have a clear idea of what role that he/she might play as an Agile Project Manager in order to prepare him/herself for that role. I think that’s particularly important since the role of an Agile Project Manager is not well-defined and it is even somewhat controversial among some people that there is a legitimate role for a project manager to play in an Agile environment.
  • Avoid the limitations of some typical Agile training. A lot of Agile training that is out there (like the typical CSM training) is very superficial in my opinion. The typical Agile training focuses on the “mechanics” of how to do Agile and really doesn’t go into the principles behind it very much at all. Agile is intended to be adaptive but in order to take an adaptive approach, you have to understand the principles behind it in order to know how to adapt it to fit a given situation.  Doing it very mechanically is not very adaptive.

What’s the Future Like?

In order to see why I think this training makes so much sense, we need to make some assumptions about where the future of the project management profession is heading. I believe that many aspects of traditional, plan-driven project management have not changed significantly since the 1950’s and 1960’s and we’re on the verge of a very major change.  What does that change look like? I don’t believe traditional, plan-driven project management will ever become obsolete. It definitely has a well-established role in some industries like construction that lend themselves to a plan-driven approach and require some level of predictability over costs and schedules. However,

  • Even in industries like construction, project managers are starting to learn how to take a more adaptive approach
  • In many other industries and application areas that have a high level of uncertainty that requires a more adaptive approach to project management, a project manager who only knows how to do a traditional, plan-driven project management approach and tries to force-fit all projects to that approach will have some serious limitations

We need to adopt a broader view of what “project management” is – force-fitting all projects to a traditional, plan-driven project management approach is just not very effective any more.

This broader vision of “project management” is not limited to someone who can take a project with well-defined requirements and plan and manage it to meet cost and schedule goals.  This new vision of Agile Project Management includes taking on an effort with some very broadly-defined business objectives in a very dynamic and uncertain environment and developing and defining and leading a project management approach that is designed to maximize the business value of the overall solution.

That means an Agile Project Manager needs to learn how to blend Agile and traditional plan-driven principles and practices in the right proportions to fit the situation.  And, even if a project manager is never involved in a true Agile project, it will make him/her a much stronger project manager by broadening the range of project management capabilities that he/she has to offer.  That’s where I see the future of project management going and that’s exactly how the online Agile Project Management training I’ve developed is designed.

Check out this new training curriculum in The Agile Project Management Academy.