Tag Archives: Agile

Lean and Agile – Is Lean in Conflict with Agile?

I’ve participated in several discussions and presentations lately where the subject of Lean and Agile came up and I think the relationship of the two is very interesting. If you pursued each of those approaches to the extreme and tried maximize what you would get out of both, they would tend to pull you in different directions:

  • Lean emphasizes reducing “waste” and Agile emphasizes flexibility and adaptivity to meet customer needs.
  • Those two approaches are not totally compatible with each other; however, they are not necessarily incompatible either. It just requires some skill to blend them together in the right proportions to fit a given situation.

Here’s an example, Michael Nir recently made a presentation at an Agile Boston meeting about “The Agile PMO” which was based on his book of the same name. Michael indicated that a key potential role of an Agile PMO is to reduce waste in an organization and that goal is very consistent with Lean. An example of that could be under-utilization of people in the organization.

How Does Lean Reduce Waste?

Michael indicated that a key potential role of an Agile PMO is to reduce waste in an organization and that goal is very consistent with Lean. For example,

  • Under-utilization of people in the organization,
  • Under-utilization of resources, or
  • Less than optimum utilization of resources

could certainly be a major source of waste in an organization. There are a number of ways that a PMO can reduce waste:

Utilization of Specialized Resources

If specialized resources that are not dedicated to project teams (such as DBA’s) are not well-planned and coordinated across teams:

  • Project teams may be idle waiting for these specialized resources, or
  • The specialized resources might not be fully-utilized waiting for work from project teams

Project Portfolio Management

If a project portfolio is not well-managed, allocation of resources to project teams may not be not well-aligned with company business goals and priorities

Project Management of Individual Projects

If individual projects are not well-managed and are allowed to go off track, the allocation of resources to projects may not be optimized to maximize the business results for the company

Development Process Definition and Training


  • The development process is not well-defined,
  • Tools aren’t adequate to support the process, and/or
  • Project teams are not well-trained to execute the process

the execution of the process will not be consistent across teams and may not be as efficient and effective as it could be

In all of those areas, a PMO might add value by reducing waste but how far do you go with that? 

Can You Reduce Waste to Zero?

Carried to an extreme, a focus on simply reducing waste could easily become dysfunctional.  Michael mentioned that waste in some organizations could be as high as 95%.  What would happen if you attempted to reduce waste to 0%?

  • First, reducing waste to 0% is probably an unrealistic and impossible goal. No business is totally predictable where everything is known in advance to enable perfect prioritization, planning, and scheduling of resources
  • Second, putting too much emphasis on reducing waste would would mean superimposing a level of control and standardization on projects. That could easily be inconsistent with achieving the flexibility and adaptivity required by an Agile approach

What’s the Right Answer?

Given that conflict, what’s the right answer?  This is not necessarily an easy problem to solve. It will take some skill to figure out the right blend of:

  1. Focusing on lean and reducing waste and
  2. Preserving the flexibility and adaptivity required by an Agile approach. 

There clearly seems to be an optimum point between the two extremes of focusing on those two extremes individually. A PMO could probably perform a value-added role in helping an organization find that optimum point.

Finding that optimum point is yet another example of the need for “systems thinking”.  Here’s a previous post I wrote on that subject:


People many times like to over-simplify what is really much more complex and reduce it to a simple, binary choice between two extremes: 

  • “Agile” versus “Waterfall” is one example of that and
  • “Lean” versus “Agile” is another example. 

Overall Summary

On the surface, Lean and Agile might appear to be in conflict with each other. If you pursued each approach individually and mechanically without really understanding the principles behind each at a deeper level, they could easily be in conflict. 

On the other hand, if you take take a systems-thinking approach to understand these seemingly disparate approaches at a deeper level. you will begin to develop a fresh new perspective to see them as complementary to each other rather than competitive.

Michael made a key point that it is a matter of focusing on value versus control and he’s absolutely right.  Here are some ways a PMO could add value:

  • Better defining processes and tools,
  • Providing training to people, and
  • Doing some level of project portfolio management and resource planning of people

Each of those can potentially add value; however, it does take some skill to determine the optimum point beyond which it stops producing value and starts to become dysfunctional.

Additional Resources

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

Fear of Failure Can Cripple a Project

What’s the Impact of Fear of Failure?

Many people have excessive fear of failure and do everything possible to avoid it. An excessive fear of failure can stifle the creativity and innovation that is often needed to maximize the business value of a solution in a project

Fear of Failure

How is the Attitude on Fear of Failure Different in Agile?

One of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:

Agile Environment

In an Agile environment,

  • A “failure” is seen in a positive sense as an opportunity for learning
  • There’s a very popular mantra of “fail early, fail often”

In other words, sometimes you just have to try something and see what works. Being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started may not produce the best results.

Traditional Plan-driven Environment

In a traditional, plan-driven environment,

  • The attitude towards failure is many times very different
  • Any significant unexpected event that occurs might be regarded as a failure and many times is regarded negatively
  • There is an inference that you didn’t do enough upfront planning to anticipate the problem and avoid it

Risk Management – What’s the Right Approach?

The approach for risk management is directly related to fear of failure. I don’t think either the Agile or the plan-driven approach is necessarily right or wrong. It’s a question of how much risk is appropriate to accept and what’s the best way to manage it.

  • Like many things, it depends on the situation
  • There are some situations that call for a more risk-averse approach and some that don’t

The Edge of Chaos

Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment. If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business. That would be a failure in itself to not do anything to “push the envelope”.

Another saying I like is “If you’ve never failed, you’re not trying hard enough”

  • Amazon.com is probably a good example of a company that has a lot of failures like the smartphone they tried to develop
  • Yet they continue to push the envelope to explore very risky new technology such as package delivery with drones
  • I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position

Other More Conservative Environments

In other environments,

  • The consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated
  • Sending an astronaut to the moon might be an example
  • Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that

The Gray Area

There’s a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be. Any project that involves a large amount of uncertainty might be an example. You need to determine:

  • How much uncertainty you can tolerate and let it be resolved as the project progresses, and
  • How much of it you can’t tolerate and need to resolve upfront before the project starts

It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks. However, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started. Trying to anticipate and mitigate every possible risk that could possibly happen could easily stop progress.

What Level of Risk Is Acceptable?

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about:

  • What the goals of the project are,
  • What level of risk is acceptable in the project, and
  • How those risks will be managed

Agile Projects

In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency. The Business Sponsor (represented by the Product Owner) should:

  • Have a sufficient level of judgment and maturity to make good, sound decisions on the project
  • Be intimately involved as the project progresses to provide ongoing direction

Traditional Plan-driven Projects

In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team.

  • The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all
  • That can lead to a fear of failure and a “CYA” approach by the project team:
    • It can cause the project team to over-analyze the project to avoid any possible problems and
    • It can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors

Overall Summary

There is generally a direct relationship between risk and opportunity:

  • Completely avoiding risks may lead to a very mediocre solution
  • An Agile approach provides an excellent environment for taking calculated risks that may be necessary to maximize the value of the solution
  • In an Agile environment, a partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is essential

Additional Resources

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

What is an Enterprise Agile Coach?

What is an Enterprise-level Agile Coach? There are very different Agile Coach roles and when people use the term “Agile Coach” it is often not exactly clear what role that they are referring to.

Enterprise Agile Coach

Typical Team-level Agile Coach Role

Most often, what they’re talking about as an “Agile Coach” is what I would call a team-level Agile Coach. Someone in that role works at a tactical level with individual members of an Agile team to help them become more proficient in executing a Scrum process.

What Is an Enterprise Agile Coach?

The role of an Agile Coach at an enterprise-level needs to be better-defined and differentiated from a normal team-level “Agile Coach” role. Beyond the team-level Agile Coach role, an enterprise-level Agile Coach:

  • Helps companies design and implement an effective Agile transformation for their business
  • Works at a more strategic level to integrate an Agile development process with a company’s business. (See diagram above)

An enterprise-level Agile Coach should be able to see the need for an Agile transformation from a broader business perspective. Check out this article for more on that:

The Impact of the Business Environment

The problem is that there is a big difference between companies whose primary business is focused on product development and other types of businesses.

Product Development Companies

  • Agile works very well in companies that are in the primary business of developing products (particularly software products). Intuit is an example that develops TurboTax, Quicken, and QuickBooks).
  • In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company
  • It is very easy to apply an Agile development process in that environment.

Non-Product Development Companies

It is much more difficult to apply an Agile development process in a company that is not in the primary business of developing products. In that kind of business, the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products:

  • You can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process
  • The company’s overall culture and business strategy needs to be optimized around the critical success factors for that business

Fitting the Approach to the Business

An enterprise-level Agile Coach role can be very challenging. It’s important to fit the approach to the business rather than force-fitting the business to some arbitrary approach, Here’s an example:

  • If a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and
  • That doesn’t necessarily align completely with just becoming more “Agile”.
  • In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach
  • The implementation of that strategy often requires fitting the approach to the company’s business environment rather than simply trying to force-fit the company to some kind of overall Agile approach

Blending Agile and Plan-Driven Project Management

The solution in that kind of environment could be a blend of Agile and traditional plan-driven management principles and practices. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices; as well as
  • Traditional project management principles and practices
  • And a deeper understanding of the principles behind both of them to know how to blend them together as necessary to fit a given situation

Business Perspective

An enterprise Agile Coach should have the ability to look at a very complex, broad-based, enterprise-level business from both:

  • A more strategic high-level business management perspective as well as
  • A more tactical product development process perspective to develop a strategy for integrating the two.

Overall Summary

An Enterprise Agile Coach is a different kind of Agile Coach role:

  • Instead of working at a team-level on improving team performance,
  • He/she needs to work at a much higher strategic level to help a company fit an Agile approach to their business

Additional Resources

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

What’s the Difference Between a Project and a Process?

What’s the difference between a project and a process? I have a very broad view of “project management” but there is a danger of broadening the definition too far. If the definition is broadened too far, almost anything could be “project management” and that would make it meaningless. 

Difference between a project and a process

For example: Is an effort to provide ongoing maintenance and enhancements for a product a “process” or a “project”?   To eliminate potential confusion, we need clearly-defined and objective criteria for drawing a line between the two. What is a “process”, and what is a “project”.

Difference Between a Project and a Process

I’ve summarized some distinctions between a “process” and a “project” below:

ObjectiveA “process” has an objective that is typically defined around the ongoing operation of the process. For example, “provide ongoing maintenance for GM vehicles”A “project” has an objective or outcome to be accomplished and the project ends when that objective is accomplished. That objective might be broadly-defined and might change or be further elaborated as the project is in progress. For example, “find a replacement ignition switch that will solve the problem with GM vehicles”.
Time DurationA “process” is generally ongoing and doesn’t normally have an end.A “project” has a beginning and an end (although the beginning and end may not be well-defined when the project starts and the end might be a long time in the future).
Process OrientationA “process” is a repetitive sequence of tasks and the tasks are known at the outset since it is repetitive.The sequence of tasks in a “project” is not normally repetitive and may not be known at the outset of the project.

Project Management Versus Process Management

Here’s a similar distinction between “process management” and “project management”:

Process ManagementProject Management
FocusThe focus of Process management is on managing a process such as a product manufacturing process. Such a process might be used across a variety of projects. Process management might involve some project management to define and improve the process.The focus of Project management is on managing a project typically using some process in achieving some kind of desired end result. Every project follows some kind of process even though it may not be formally defined.
EmphasisThe emphasis of Process management is on increasing “repeatability” of the tasks, improving efficiency (decreasing time needed, reducing cost), and improving quality of the work product produced by the process (including consistency in quality).The emphasis of Project management is on achieving the end result that the project is intended to accomplish. Higher efficiency is harder to achieve since it might require custom tools and methods that can only be developed if the project was turned into a repetitive process.

Overall Summary

In simple, terms:

  • The goal of “Process Management” is to manage existing business processes as efficiently and effectively as possible. An example would be managing a process associated with the current way the business operates.
  • The goal of “Project management” is on managing some kind of change in the way a business operates to make the overall business operate more effectively. An example would be introducing a new product, implementing new processes, etc.

Additional Resources

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

What is a Project? Do We Need to Redefine It?

What is a Project?

What is a project? I recently wrote a blog post on “What is Project Management?” that has generated some good comments on LinkedIn.  One of the comments was that “the change is not merely to redefine ‘project management’ but to redefine ‘project'”. That is absolutely correct.

What Is a Project?

PMBOK defines a project as follows:

“A project is a temporary endeavor undertaken to create a unique product, service, or result”. The temporary nature of projects indicates that a project has a beginning and an end.”

How Does This Apply to Agile?

There are potentially several problems with applying this definition to an agile project:

Beginning and End

An agile project may not have a well-defined beginning and end:

  • An Agile project will have an end at some point in time, but
  • The end may be indeterminate when the project starts

Temporary Nature

An Agile project may be:

  • More of an ongoing development effort with an end that is not well-defined and
  • The end, when it happens, may be a long time in the future. That kind of effort might not be considered to be “temporary”


An agile project generally creates “a unique product, service, or result”; however,

  • The “unique product, service, or result” might not be well-defined at the beginning of the project and
  • The goal of the project may be more broadly-defined at the beginning of the project.

The Value of a Project Manager

The traditional definition of a “project” is probably based on how people have seen the value provided by a project manager.

  • The value provided by a project manager has traditionally been in planning and managing the activities of a project to meet well-defined requirements within expected costs and schedules
  • Obviously, a project manager can’t do that unless
    • The project has a beginning and an end
    • The product, service, or result the project is intended to create also needs to be relatively well-defined at the beginning of the project

What is a Project? A More Broadly-Defined Definition

An Agile project may be a more broadly-defined initiative to meet a business goal or objective.

  • It may not have specific, well-defined requirements at the beginning of the project and
  • May not have a well-defined end-date at the beginning of the project probably wouldn’t fit this definition of a “project”

In that situation, the value provided by a project manager is likely to be very different. It may put more emphasis on guiding the people, process, and tools, to maximize the business value that the effort produces.

If we broaden the vision of what “project management” is, we also need to broaden the definition of what a “project” is. There are probably two key things that are needed to develop a more general definition:

  1. A project does not necessarily have a well-defined beginning and an end
  2. The goal of the project may be to satisfy a more broad-based business objective

The new definition of a project would come out something like this:

“A project is a endeavor undertaken to satisfy a broad-based business objective/outcome or to create a unique product, service, or result”.

Overall Summary

If we broaden the definition of “project Management” to embrace Agile as well as traditional plan-driven projects, we must also broaden the definition of what a “project” is as well.

Additional Resources

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

What is Agile Project Management? How Is It Different?

There’s a lot of confusion on the subject of “What is Agile Project Management?” and how is it different? Let’s start with the standard PMI definition of “Project Management” from PMBOK that exists today:

“The application of knowledge, skills, tools and techniques to the project activities to meet project requirements”

What’s Wrong With That Definition?

It seems to me that this classic definition that so many people seem to take for granted is way out-of-date. It:

  • Seems to be based on the narrow, traditional notion that a project manager is someone who manages the costs and schedule of a project to meet defined requirements
  • Implies that there is only one way to do project management and that is based on a traditional plan-driven approach to project management.

And the definition assumes that “Project Management” is only performed by someone called a “Project Manager”.

What Is Agile Project Management

We need to significantly expand that thinking to embrace the idea that a project manager may play a role in a much more uncertain environment where:

  • The requirements may not be not well-defined and
  • The project requires a more adaptive (Agile) approach

In that environment, the goal is typically focused more on:

  • Maximizing the value the project produces rather than
  • Managing costs and schedules to deliver well-defined requirements.

The person performing that function may not even have the formal title of “Project Manager”.

Many people may claim that is not “project management” because there have been so many well-established stereotypes that have developed over the years about what “project management” is. So the first challenge is to get past many of the stereotypes that exist about what “project management” is.

Project Management Stereotypes

Here are a few of the common stereotypes that exist about project management:

1. Project Managers Are Very “Command-and-Control” Oriented

One common stereotype is that Project Managers are very “command-and-control” oriented. There is some amount of truth in that. Project managers are held responsible for getting results and:

  • Sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams
  • Many times, a project manager is expected to perform that role by the businesses that they operate in
  • In many companies, the Project Manager is the one held responsible and is expected to take corrective action to get the project on track if there is the project does not meet expectations

2. Project Managers Are Rigid and Inflexible and Only Know How to Manage by the “Waterfall” Methodology

Another common stereotype is that project managers are rigid and inflexible. That also has some truth to it. For many years,

  • Project managers have been accountable for the costs and schedules of projects and
  • In order to meet cost and schedule goals, project managers have to control the scope of the project.
  • That, in turn, requires a disciplined approach to defining and documenting detailed requirements and controlling changes

The emphasis on managing costs and schedules naturally leads to extensive use of plan-driven or “Waterfall-style” methodologies. Those methodologies are based on

  • Trying to define the project requirements in-detail upfront before the project starts and
  • Controlling changes once the project is in progress

3. Project Managers Are Just Not Adaptive and Cannot Adapt to an Agile Environment

A final stereotype is that project managers cannot adapt to an Agile environment. Like the other stereotypes, there may be some amount of truth in this stereotype. However, it would be inaccurate to generalize and say that this is true of all project managers. For many project managers:

  • Agile will require some considerable rethinking of the project management approach and
  • It will also require a significant mindset change

Where Does Project Management Fit in Agile/Scrum?

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 the traditional stereotype of what “project management” is and
  • 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 more detail on that, check out this article:

What Is an Agile Project Manager?

A logical question would then be

  • What’s left for a project manager to do in that environment and
  • What is an Agile Project Manager?
  • What role does he/she play in the real world?

Those are not easy questions to answer because:

  • The role of an Agile Project Manager is not well-defined and
  • There may not be a role at all for a Project Manager at all at the team level in an Agile project

Basically, an Agile Project Manager is someone who knows how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation.

There are a number of different roles an Agile Project Manager might play in an Agile environment. Check out this article for more detail on that:

Overall Summary

In my opinion, we need to make some radical shifts in thinking about what “Project Management” is. The project management profession and PMI, in particular, seem to unintentionally perpetuate these stereotypes by not addressing these basic definitions that are published in PMBOK that many project managers have taken for granted for many years.

Here’s my suggestion for a broader definition of what “Project Management” is:

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

Project management is focused on maximizing business results within the context of the business environment that a project is part of in a way that is appropriate to the nature of the project.

I’m sure that definition could be fine-tuned, but the key points that I’m trying to get across are that:

  • There isn’t just one way to do project management and we need to fully embrace Agile as a legitimate form of project management
  • One of the greatest skills of anyone performing a project management function should be to select the right approach to fit the nature of the project

This definition of “Project Management” is not be limited to someone who has a title of “Project Manager”. In an Agile environment, “project management” functions are often distributed among other roles but it is still “project management”.

Overall Summary

We need to significantly expand our thinking on what “Project Management” is in order to adopt a broader definition that embraces Agile Project Management.

Additional Resources

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

Levels of Mastery in Agile – How Do You Measure Maturity?

I came across the diagram shown below that I think nicely summarizes different levels of mastery in Agile:

Levels of Mastery in Agile

Many people don’t seem to realize that there are these three different levels of mastery. Just learning the basic practices is only the beginning.

Levels of Mastery in Agile

The three levels of mastery are:

1. Practices (Doing)

The initial level of Practices is associated with learning the basic practices of Agile at a mechanical level.

  • There are many people who are at this level of learning.
    • They’ve received their CSM certification (or equivalent) and
    • They may have had some practice in the real world and know how to do the basics
  • The danger is that many people think that this is all they need to know. They think that their development is complete when they have mastered this level of learning
  • People who get stuck in this level of learning can become fairly ritualistic or dogmatic. They may insist that there is only one way to do Agile and that is doing it exactly by the book as they have learned to do it

2. Principles (Understanding)

People who have gone on to the “Principles” level of learning have gained a deeper understanding of the principles behind Agile. They understand why it makes sense rather than just doing it mechanically.

  • This deeper level of understanding gives people a broader perspective. Instead of seeing Agile as a mechanical process that must always be done ritualistically “by the book”; people at this level recognize that there may be a need to customize and adapt the processes to fit a given situation
  • People at this level are also able to see Agile in a much broader context.
    • They see beyond the basic team-level Agile implementation and
    • They recognize the need to make Agile work at much higher levels of complexity for large enterprise-level projects.

3. Values (Being)

Values is the highest level of mastery.

  • People at this level of learning go beyond only understanding the principles at a deeper level. They also understand the values behind those principles and have internalized those values into the way they work
  • People at this level are becoming Masters and are at the “top of their game”. They are able to:
    • Easily go beyond applying Agile to routine Agile project implementations.
    • Apply the principles and practices to much more demanding and difficult situations. They are also able to do it with much higher levels of consistency and success

The three levels of mastery shown in this diagram correspond to the “Shu-ha-ri” levels of mastery from martial arts. I have previously discussed that in this article:

Agile and Lessons Learned From the Martial Arts

How Does This Relate to Agile Project Management?

How does this relate to the idea of “Agile Project Management”? Many people in both the Agile and traditional plan-driven project management communities are at a very basic level of mastery of those two disciplines. They see them as firmly-defined processes to be followed. I believe that people who are at a higher level of learning and understand the principles behind these two disciplines will see things in a very different perspective. They will:

  • See these two areas as much more complementary rather than competitive
  • Recognize the reasons why one set of principles and practices makes sense in one situation and not another
  • Be able to easily blend the two sets of principles and practices together as needed to fit a given situation

Overall Summary

One of my favorite analogies for this that was originally created by Bob Wysocki is the difference between a “cook” and 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. 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 styles of cooking

This is the challenge that I believe we face in creating a more integrated approach for Agile Project Management. We need to develop more “chefs” who are capable of seeing both Agile and traditional plan-driven project management principles and practices in a very different light as complementary rather than competitive alternatives.

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 is the next generation of project management? What is the impact of Agile on the future of project management?

  • Does it mean that project managers who are heavily trained in a traditional plan-driven project approach will become obsolete over some period of time?
  • What do project managers need to do to adjust their career direction to adapt to the future direction of project management?

I believe that the project management profession is at a major turning point that requires:

  • Broadening our view of what “project management” is and
  • Reshaping the direction of the project management profession for the future

The new direction should fully embrace and integrate both Agile and traditional plan-driven project management as complementary approaches within an overall project management portfolio.

Reinventing Project Management

What sort of image comes to your mind when you think of the words “project management”? Does it have any relationship to Agile?

  • My guess is that many people have a very well-ingrained image of what “project management” is and
  • Many people wouldn’t associate “project management” with Agile at all

In fact, some people still see those two disciplines as polar opposites. To see things differently,

  • We have to broaden our thinking about what “project management” is and
  • Get past many of the well-established stereotypes of what “project management” is.

Why Is Reinvention Important?

Long-lasting companies have learned to “reinvent” themselves from time-to-time to keep up with changes in technology and the business environment they operate in. Here’s an excerpt from Harvard Business Review on that topic:

Harvard Business Review Excerpt

Sooner or later, all businesses, even the most successful, run out of room to grow. Faced with this unpleasant reality, they are compelled to reinvent themselves periodically. The ability to pull off this difficult feat—to jump from the maturity stage of one business to the growth stage of the next—is what separates high performers from those whose time at the top is all too brief.

“The potential consequences are dire for any organization that fails to reinvent itself in time. As Matthew S. Olson and Derek van Bever demonstrate in their book Stall Points, once a company runs up against a major stall in its growth, it has less than a 10% chance of ever fully recovering. Those odds are certainly daunting, and they do much to explain why two-thirds of stalled companies are later acquired, taken private, or forced into bankruptcy.”

Source: “Reinvent Your Business Before It’s Too Late”, Harvard Business Review, January 2011,

Another Excellent Article

Here’s another excellent article on that subject:

“A successful company is like a great white shark. In its prime, it chews up the competition, but if it dares to sit still for too long, it dies. Some of the world’s most profitable and enduring companies have achieved their long track record of success by constantly reinventing themselves.”

“Cell phone maker Nokia started off selling rubber boots. The oil giant Shell used to import and sell actual shells. But these companies and the eight others on our list adapted with the times, evolving their product lines and business strategies to stay one step ahead of their customers’ needs. In business, it’s better to be a chameleon than a great white.”

Source: How Stuff Works, “10 Companies That Completely Reinvented Themselves”

Check out the link above for some great examples of companies that have done that successfully. As the article points out, the trick is recognizing that you are at a “stall point” and taking action before you have stalled for very long and that can be a difficult thing to do.

Project Management History

To understand the transformation that is going on, its useful to look at the history of project management and how we got to where we are today:

Early History

Project Management could probably be considered to be one of the world’s oldest professions. Think of the Egyptian pyramids and the Great Wall of China:

  • The level of “project management” at that time may have been very crude and they probably didn’t call it “project management” at all but large efforts like that don’t just happen without some kind of planning and organization behind them
  • In the US, the development of the Transcontinental Railway in the late 1800’s is another example of a very large effort that had to have some kind of planning and organization behind it.

Scientific Management Approach

Around the turn of the century, along came Frederick Taylor and his co-worker, Henry Gantt. Frederick Taylor started developing new theories on how to organize workers and Henry Gantt created his famous Gantt Charts to describe the order of operations in work.

World War II and the 50’s and 60’s

World War II resulted in the Manhattan project which was another huge effort and the 1950’s and 1960’s had more large scale efforts such as the Polaris missile program and the Apollo program to put a man on the moon. PERT and CPM were invented and then in 1969, PMI was founded.

The Next Generation of Project Management

The general approach for doing project management hasn’t changed significantly since that time and the big question is “What’s next?” and also “Why Now?”

  • Has the project management profession reached its peak or is there yet another major phase of growth that is just beginning to take place? I believe it is the latter.
  • Here’s why I believe it there is some level of urgency to rethink the way we think about “project management”. The diagram below shows how the adoption rate of new technologies has changed over the last century.
Consumption of New Technology Trends

“Source: Mulbrandon, Catherine, Visualizing Economics – Adoption of New Technology Since 1900, http://visualizingeconomics.com/blog/2008/02/18/adoption-of-new-technology-since-1900

This data only goes through 2005, but you can be sure this trend hasn’t slowed down since then. (Think of how quickly smartphones have evolved as an example) This rapid proliferation of new technology calls for a new approach to project management. The traditional, heavily plan-driven approaches of the past can’t keep pace with the speed that technology is changing in many areas.

This dynamic and rapidly changing environment calls for a more adaptive project management approach in many areas. However, that doesn’t necessarily mean that

  • We need to throw out everything we’ve learned about traditional, plan-driven project management and
  • Start over again

However, it does create some significant challenges for individual project managers and for the project management profession, as a whole.

What’s the Impact on Project Managers?

This “raises the bar” for project managers significantly:

  • In the past, if you had a PMP certificate, that was as far as you needed to go for many project management roles
  • PMI has now created the Agile Certified Professional (ACP) certification and that’s not an easy certification to get, but that’s only the beginning, in my opinion

I think the PMI-ACP exam is good certification but it doesn’t go far enough:

  • It is really a test of general knowledge related to Agile and Lean
  • It doesn’t really test whether you know how to integrate Agile and traditional project management principles and practices in the right proportions to fit a given situation. That’s the real challenge for project managers, in my opinion
  • It also doesn’t prepare a project manager for a specific job role. And, the role that an Agile Project Manager might play in the real-world is not well-defined

What Needs to be Done to Address These Challenges?

This is a huge challenge to transform the project management profession and broaden our thinking of what a “project manager” is and it will take some time. However, the alternative of ignoring these trends and continuing to think of a project manager in the narrow context of someone who only does traditional, plan-driven project management will seriously degrade and undermine the project management profession over time. Here’s what I think needs to be done to address this challenge:

1. Acknowledge the Need to Make a Change

The first step is to acknowledge that we have a problem. We cannot deny the impact of Agile on the project management profession and think that:

  • A traditional, plan-driven project management approach, as we know it, is the only way to do project management and
  • Agile is just a fad that will go away.

2. Get Past Sterotypes

There are many stereotypes about what traditional project management is and about what Agile is that we need to overcome. And, we need to change our thinking to see both Agile and traditional project management approaches as complementary to each other rather than competitive.

3. Redefine Project Management

We have to better define and develop the concept of what an “Agile Project Manager” is and better define the role that an “Agile Project Manager” might play. In my view,

  • An “Agile Project Manager” is not someone who only does Agile projects
  • It is someone who has a deep knowledge of both Agile and traditional plan-driven principles and practices and knows how to blend them together in the right proportions to fit a given situationIndent1

4. Develop Agile Project Management Training

We need to develop training programs and resources to help project managers reach the goal of becoming an “Agile Project Manager”.

5. Influence Enterprise-level Management Practices

Project Managers are a product of the environment that they work in. For example,

  • Many project managers take a heavily plan-driven approach to controlling costs and schedules of a project because that’s what their organizations expect of them
  • To change the behavior of project managers, we must change what companies expect of project managers and that can require some significant changes in organizational culture

Overall Summary

The Project Management profession is going through some very rapid and profound changes that will radically shift the way we think about project management. This will present a challenge to many project managers to adapt to these changes

Additional Resources

Here’s a related article on comparing the evolution of the science of Physics to the evolution of project management. There are many parallels:

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

I encourage any project manager who needs help in making this transformation to check into my online training courses and to contact me directly if I can be of help.

Was Steve Jobs an Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking. 

Was Steve Jobs an Agile Leader?

Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people. 

I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

Was Steve Jobs an Agile Leader? – Higher-level Values

Focus and Simplicity“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things… “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
Leadership Style“It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”
Planning“Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
Seeing the “Big Picture”“A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”

Was Steve Jobs an Agile Leader? Project-level Values

Requirements and Customer Needs“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”
Innovation“Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
Quality“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
Continuous Improvement“I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
Tools“It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”. 

Was Steve Jobs an Agile Leader? Overall Summary

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

Additional Resources

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

Enterprise-level Product Backlog Organization

A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives. Scaling small, single team projects to large, complex, enterprise-level initiatives is a relatively new area. It also requires a different approach to structure an enterprise-level product backlog.

Product Backlog Planning

Product Backlog organization can be very different on large, enterprise-level projects.  On small single-team Agile projects, the predominant thinking seems to be that

  • You only need to plan the backlog a few sprints in advance
  • You just prioritize the stories in the backlog, and
  • Then pull them off as needed to start a sprint. 

That method starts to break down as you scale projects to large, complex enterprise levels.  There are a number of problems I’ve seen with that approach:

The Importance of Planning

If you don’t plan the backlog further in advance, it’s difficult to assess the overall scope of the project and determine the resources required for the project. For example,

  • I’ve seen a project that just started development with a small, single Agile development team and
  • After two years of development still had no end-in-sight of when the project would be completed 

When we re-planned the entire backlog at a high level, the company management was very surprised to find that the project was going to take more than two years to complete with the current level of resources.

Large Product Backlogs

When you have a large product backlog with hundreds or perhaps even over 1,000 stories, understanding the inter-relationship of the stories becomes important.  When you make priority changes among stories in the Product Backlog, it often doesn’t make sense to do it the level of individual stories:

  • If one story up in the Product Backlog is moved, what about the other stories that are inter-related with it? 
  • Wouldn’t you want to move all of those stories together as a group? 
  • Organizing the Product Backlog into epics and perhaps themes provides a way to make priority decisions at a higher level that is more appropriate for enterprise-level projects
  • At that level, priority decisions are often more based on a higher-level of epics and themes rather than at the level of individual stories within an epic or theme


Another major problem area is architecture.

  • If you take a piecemeal approach to doing individual stories without planning and considering the entire solution,
  • It can lead to poor architectural decisions and possibly significant rework later on

Multiple Teams

Finally, it becomes even more essential to organize the work to be done with multiple-team projects. Properly segmenting the work among multiple teams is essential to avoid requiring excessive amounts of coordination overhead among the teams.

Higher-level Decision-Making

I recently wrote an article on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies. Those levels (such as Program Management and Product/Project Portfolio Management) need to be integrated.  In a large company,

  • Organizing the Product Backlog is essential to support effective decision-making at those higher levels of management and
  • That is often critical to ensure that all of the projects in an organization are well-aligned with the company’s overall business strategy.

Overall Summary

There are many things that need to be done differently on large, enterprise-level projects. Product Backlog organization can be one of them.

Additional Resources

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