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:

  • It 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?

Agile Project Management 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:

  • The course design is focused on passing the PMI-ACP exam and not much more than that
  • It involves a lot of memorization of information. That 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
  • 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
  • The individual project manager needs to figure out how to put the two together

Design the Training Around a Real-world Role

The PMI-ACP certification is a good certification. However, it is not designed around preparing someone for a particular job role:

  • It’s important for a project manager to have a clear idea of what role that he/she might play in order to prepare him/herself for that role.
  • The role of an Agile Project Manager is not well-defined. 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
  • In order to take an adaptive approach, you have to understand the principles behind it 
  • Doing it very mechanically is not very adaptive.

Future of PMI-ACP Certification – What’s the Future Like?

Agile is having a significant and profound effect on the project management profession. We need to make some assumptions and develop a vision of where the future of the project management profession is heading.

  • The new vision of “project management” is not limited to taking a project with well-defined requirements and planning and managing 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
    • Leading a project management approach that is designed to maximize the business value of the overall solution

Overall Summary

PMI-ACP is a step in the right direction but it doesn’t go far enough in my opinion. To some extent, it still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two.

The big challenge for project managers that goes beyond the PMI-ACP certification is learning how to blend Agile and traditional plan-driven principles and practices in the right proportions to fit a given situation

  • The online Agile Project Management training is designed around that objective
  • This training will be of benefit to all project managers even if they are not involved in an Agile project. The training will broaden the range of project management capabilities that he/she has to offer.

Additional Resources

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

What is the Real Essence of Agile? What Are the Real Advantages?

It’s apparent to me that a lot of people have gotten so heavily focused on the mechanics of how Agile is implemented that they’ve lost sight of the big picture of what the real essence of Agile is all about. 

  • The term “Agile” has taken on a number of different meanings today that are largely based on how it is implemented
  • For many people, “Agile” has become synonymous with Scrum and if you’re not doing Scrum and doing it “by the book”, you’re not really Agile at all

I think it is useful to step back and take a look at “What is the real essence of Agile”?

What is the Real Essence of Agile?

What is the Real Essence of Agile?

The real essence of “Agile”, in my opinion, is that:

  • It puts an emphasis on being adaptive to customer and business needs in order to maximize the value of the solution; rather than
  • Following a rigidly-defined plan with an emphasis on managing costs and schedules of delivering the solution.

For that reason, I like to use the terms “adaptive” and “plan-driven” rather than terms like “Agile” and “Waterfall”.

What’s the Truth About “Agile” vs “Waterfall”?

There’s a lot of myths, stereotypes, and misconceptions about “Agile” and “Waterfall” that we need to get past:

Are Agile and Waterfall Distinct and Unique Methodologies?

The terms “Agile” and “Waterfall” make it sound like you’re comparing two specific methodologies:

  • One called “Agile” and
  • One called “Waterfall”

and that’s not really accurate: 

  • “Agile” is not really a specific methodology or framework like Scrum;
  • It is much broader than that – it is a way of thinking defined by the Agile Manifesto

In It a Binary and Mutually-Exclusive Choice?

The “Agile versus Waterfall” kind of thinking leads people:

  • To think that there is a binary and mutually-exclusive choice between those two approaches and
  • That causes people  to try to force-fit 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 blending the two approaches in the right proportions to fit the problem

Choosing the Best Approach

Here are some guidelines for choosing the best approach.

When Does Agile Work Best?

Agile works best in situations that have a high-level of uncertainty where it isn’t practical or possible to define the solution to the problem upfront.  In that kind of situation, it is much more effective to use an adaptive approach to incrementally and iteratively define the solution in more detail as the project is in progress rather than attempting to define detailed requirements for the solution upfront.

The example I like to use to illustrate this is finding a cure for cancer.  

  • If you set out to define a project to find a cure for cancer, it would be ridiculous to try to define a detailed plan upfront; there’s just far too much uncertainty. 
  • The only approach that is likely to work is an iterative, trial-and-error approach to find a solution.

Agile is based on what is called an “Empirical Process Control” model.  The word “Empirical” means “based on observation” and that means that in an Agile project, both the requirements for the solution AND the process for developing the solution are continuously refined as the project is in progress.

When Does a Plan-driven Approach Work Best?

That kind of empirical process control model approach is naturally not the most efficient approach if there is a low level of uncertainty and it is possible to easily define detailed requirements for the solution prior to the start of the project. In that situation, a trial-and-error approach really isn’t necessary and a plan-driven approach is much more appropriate and much more efficient.

The example I like to use to illustrate this scenario is building a bridge across a river. If you were defining a project to construct a bridge across a river, it would be ridiculous to say “we’ll take an adaptive approach, build the first span of the bridge, and decide how we will build the rest of the bridge after we’ve completed the first span. That wouldn’t make any sense.

This kind of situation calls for a plan-driven approach that is based on a defined process control model.

  • The key advantage of a defined process model is that it is predictable and repeatable and it is probably more efficient for projects with a low level of uncertainty.
  • If you designed a process for building a bridge and it has proven successful once, the same process or a variation of that process is likely to work in another similar situation with somewhat predictable results.

What if it is Between Those Extremes?

Very few real world situations are as extreme and clear-cut as the ones I’ve used of finding a cure for cancer and building a bridge across a river.

  • Most real-world situations fall somewhere between those two extremes.
  • There is some level of uncertainty but it’s not complete uncertainty.
  • You rarely start any project without at least some idea of what the solution is going to look like although the solution may be progressively refined in more detail as the project is in progress. There’s a range of approaches that look something like this:
Range of Agility

In this kind of situation, you have to tailor the approach to fit the nature of the project:

  • One of the biggest factors to consider is the level of uncertainty associated with the solution.
  • That requires more skill but it definitely can be done
  • It requires knowledge of a broader range of methodologies (both plan-driven and adaptive (Agile))
  • It also requires a deeper knowledge of the principles behind the methodologies in order to know how to tailor them to fit a given situation.
  • You can’t just force-fit a situation to some predefined methodology (whatever it might be) and do it mechanically.

Additional Resources

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

What’s Different About Agile Metrics?

What’s Different About Agile Metrics? Are metrics really consistent with Agile at all?

Agile Metrics

Different Views of Metrics

Metrics play a different approach in an Agile environment that is important to understand; however,

  • Metrics will be directly related to the level of planning and the project approach and
  • The project approach should fit the nature of the project

Customizing Metrics to Fit the Project

Metrics should be well-aligned with the success criteria for the project and need to be customized to fit the project. There are a number of factors that influence the need for metrics.

Impact of the Project Approach on Metrics

The project methodology and the success criteria for the project is likely to have a big impact on metrics. As a result, you’re likely to see very different types of high-level project metrics in an Agile project.

  • In a traditional plan-driven project, metrics are heavily used to show how closely the project is tracking against cost and schedule goals. As a result, you might see a dashboard with red/yellow/green status indicators that signify the amount of variation from budget and schedule goals
  • In an Agile environment, there is typically more focus on producing results. For that reason, a burn-down or burn-up chart might be a good way to show the performance of the project in producing results

Metrics Are a Form of Project Communications

Metrics are a form of project communications:

  • In a traditional plan-driven environment, communications are typically more limited and formal, as well as more controlled
  • In an Agile environment, the stakeholders are much more heavily engaged in the project on an ongoing basis. There is also lots of emphasis on openness and transparency

The impact is that Agile needs less extensive metrics to keep people informed of what’s going on in the project. In an Agile project, stakeholders should have direct, first-hand knowledge of what’s going on in the project without extensive metrics.

Metrics Should Support Decision-making

There is a different need for decision-making that will also impact metrics:

  • In a traditional plan-driven environment, management typically has to get engaged in projects at a much lower level. They need to make decisions related to resolving issues, assigning additional resources, etc.
  • Agile companies delegate more responsibility to empowered, self-organizing teams. As a result, there is less need for management to get engaged in tactical project decisions

Different levels of empowerment will cause a significant difference in the metrics needed at different levels:

  • Senior managers will be less heavily-engaged in tactical project decisions
  • That should enable them to focus more heavily on more strategic issues

Overall Summary

Metrics in an Agile environment will probably be very different and more limited; however,

  • Metrics still have value in an Agile environment
  • They should be customized to fit the project

Additional Resources

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

What is Agile Risk Management? How Is It Different?

Some people might think that Agile Risk Management is an oxymoron:

  • There is a common stereotype that an Agile project is totally unplanned
  • So, why would you take a planned approach to Agile Risk Management if the whole project is unplanned?   
Agile Risk Management

There is always some level of planning in an Agile project even though the level of planning may be limited.  Here’s an article with more detail on that:

Why Is Planning So Difficult? Is It a Waste of Time?

The gist of this is that you have to adapt the planning approach to the level of uncertainty in the project.  A similar thing is true regarding risk management:

  • There is no single approach to doing risk management and
  • It’s not a binary choice between zero risk management and a totally rigid and controlled approach to risk management. 

You need to fit the risk management approach to the nature of the project:

  • For high risk projects where the customer is very sensitive to risk, it makes sense to take a planned approach to risk management
  • For lower risk projects , a more informal approach to risk management may be appropriate.

Agile Risk Management Process

The overall process for doing risk analysis in an Agile environment is generally the same as a traditional, plan-driven project; however, it may not be as formal and it may not be as disciplined.  The general approach follows these stages:

PhaseDescription
Risk IdentificationThis might consist of a brainstorming session to identify potential risks in the project
Risk AnalysisThis involves further study to determine the probability and impact of each risk
Risk ResponseThis phase involves determining what, if anything, should be done to mitigate the risk
Monitoring and ControlFinally during the course of the project, the risks are monitored and controlled

Advantages of an Agile Risk Management Approach

An Agile approach is inherently well-designed for dealing with risks:

  • Risks are generally directly related to uncertainty in a project and an Agile approach is intended to be flexible and adaptive in order to deal with uncertainty
  • For that reason, it is easier to adapt to risks in an Agile environment as the project is in progress

Risk Management in a Plan-driven Environment

In a traditional, plan-driven project:

  • A considerable amount of re-planning may be necessary to adapt to risks as the project is in progress and
  • For that reason, it may be more important to plan for risks upfront in a plan-driven environment.

Structuring an Agile Project for Risk Management

Another factor is due to the iterative and incremental nature of development in an Agile project:

  • It’s not too difficult to structure the Product Backlog to address high risk items early in the project and,
  • If there is a lot of uncertainty associated with those risks, a “spike” can be performed to evaluate the risk without having a major impact on the project.

Responsibility for Agile Risk Management

It’s easy to lose focus on risk management in an Agile environment because there is no well-defined focal point of responsibility for risk management. Risk management is normally a project management responsibility and there is typically no project manager at the team level in an Agile project:

  • In an Agile environment, the entire team owns responsibility for risk management. In a similar way, the the entire team owns responsibility for project management
  • Another factor is that because an Agile approach is more adaptive to risks, there tends to be a “cavalier” approach to not worry about risks but it doesn’t have to be that way
  • You can do as much (or as little) risk management as necessary depending on the nature of the project and the sensitivity to risk

Overall Summary

Risk management is not inconsistent with an Agile approach. In fact, an Agile approach offers many advantages for doing risk management more effectively. Developing a risk management strategy for an Agile environment is primarily a matter of:

  • Deciding how much (and what kind of) risk management is needed based on the nature of the project
  • Training the team in the basics of risk management
  • Building in some focus on thinking about risks in all of the Agile/Scrum ceremonies
  • Determining how the risk management effort will be managed:
    • How will risk management be done and
    • How will responsibilities for risk management be distributed among the team?

Additional Resources

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

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

If:

  • 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:

http://managedagile.com/2013/04/28/systems-thinking-and-binary-thinking/

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.

What is an Agile Project Manager?

There is a lot of confusion and controversy about what an Agile Project Manager is. It’s understandable why this confusion exists:

  • There are many stereotypes and misconceptions about both Agile and traditional plan-driven project management and
  • The role of an Agile Project Manager might play is not well-defined
What is an Agile Project Manager?

Popular Stereotypes and Misconceptions

There are some very strong stereotypes of what “project management” is and what a “Project Manager” is:

  • Those stereotypes are centered around the belief that traditional plan-driven project management is the only way to do project management
  • Project managers are so heavily ingrained into that way of thinking that they can’t possibly adapt to an Agile environment

Agile Versus Waterfall

One of the biggest misconceptions that many people seem to have is that there is a binary and mutually-exclusive choice between Agile and “Waterfall” with nothing in between. That ignores the possibility of blending the two approaches to fit a given situation.

Agile is Not Limited to Small, Single-team Projects

Many people think of Agile in a very narrow sense as limited to simple, single-team Scrum projects.

  • Because there is no “Project Manager” role defined at that level, they assume that there is no role for project management at all in an Agile environment
  • However, there is more to Agile than simple, single-team projects

The Role of an Agile Project Manager is Not Well-defined

PMI has made a step in the right direction by introducing the PMI-ACP certification. That certification at least recognizes Agile as a legitimate form of project management; however,

  • PMI has never really defined what an “Agile Project Manager” is and what role he/she might play in the real world
  • The PMI-ACP certification is a general test of Agile and Lean knowledge and is not designed around a particular job role
  • To some extent, 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

A Broader Vision of Project Management

In order to better understand what “Agile Project Management” is, we need to get past these stereotypes and develop a broader vision of:

  • What “project management” is,
  • What “Agile” is, and
  • Finally, What an “Agile Project Manager” is

Important Goals

We need to recognize that:

  • The discipline of ”project management” isn’t limited to traditional, plan-driven project management and
  • An emphasis on planning and control is not the only way to do project management

A Different View of Project Management

For example, there is actually a lot of “project management” going on in an Agile project although:

  • You may not find anyone with the title of “Project Manager” and
  • It may not look like the traditional, narrow view of what project management is at all:

It’s a different style of project management with an emphasis on taking an adaptive approach to maximize the value of the project in an uncertain environment.

  • It may not have the traditional emphasis on planning and control
  • The project management functions that would normally be performed by an individual with the title of “Project Manager” have been distributed among the other members of the team

Distribution of Project Management Functions

Here is a summary of how the project management functions that might normally be performed by a Project Manager have been distributed among other roles at the team level in an Agile project:

Product Owner Role

The Product Owner has a lot of responsibilities that might be performed by a project manager in a traditional plan-driven project. 

  • He/she is responsible for the overall successful business outcome of the project which means delivering a valuable product in a timely and cost-effective manner and
  • Making all decisions that would normally be done by a Project Manager for risk management as well as planning and managing the overall effort

Scrum Master Role

The Scrum Master also has some responsibilities that might be done by a project manager including:

  • Removing obstacles that might limit progress and
  • Facilitating and coaching the project team

Team Role

And, finally every member of the development team has some project management functions on a very small scale for:

  • Planning, scheduling, tracking, and reporting on their own work
  • As well as the work of the team as a whole.

So, What is an “Agile Project Manager”?

In my opinion, an Agile Project Manager is:

  • Equally trained and skilled in applying both Agile and traditional plan-driven project management principles and practices
  • He/She should know how to blend them together in the right proportions to fit a given situation. 

What Role Might an “Agile Project Manager” Play?

I think it’s sad that some project managers see their only alternative in an Agile environment is to become a Scrum Master. That’s because the role of an Agile Project Manager is so ill-defined and poorly-understood.  I’ve identified several potential roles that an Agile Project Manager might play:

1. Team-level Role

There is officially no role for an “Agile Project Manager” at the team level in an Agile project; however, a project manager who is skilled in blending Agile and traditional plan-driven project management principles and practices can play a real value-added role as either a Product Owner, a Scrum Master, or an Agile Coach

2. Hybrid Agile Role

For lots of reasons, companies choose to implement a hybrid Agile approach and this is an ideal environment for an Agile Project Manager to work in. An example would be an Agile contracting situation.

3. Enterprise-level Role

As projects grow in scope and complexity to an enterprise level, there is a much more significant need for a dedicated Agile Project Manager role. As an example, I did a case study in my latest book on a project at Harvard Pilgrim that involved over 100 Agile teams – you just can’t do an effort like that without some form of project/program management.

Additional Resources

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

What Is an Agile Developer? How Is the Role Different?

The role of an Agile Developer is not well-understood and many developers may have difficulty making this transition.

In a traditional plan-driven environment (aka “Waterfall”), a developer might be able to sit in his/her cube with their headset on listening to some cool tunes. And, he/she could be fairly isolated from the rest of the world and simply write code. That isn’t possible in a true Agile environment.

What is an Agile Developer?

Agile Developer Role

The role of a developer in an Agile environment is significantly broader than that and includes:

AreaAdditional Responsibility
Task/Project ManagementTaking responsibility for estimating, planning, and managing all of his/her own tasks and reporting on progress.

This role is essentially what a project manager might do on a very small scale.
Effective TeamworkCollaborating closely with all the other members of the team to take shared responsibility for the overall efforts that the team has committed to.

This role is also similar to what a project manager might do but rather than being done by a single person with the title of “Project Manager”, the responsibility is distributed among all members of the team.
Software QualityTaking responsibility for the quality of the software the developer produces.

Instead of turning over some code to a separate and independent group for testing, the team, as a whole, takes responsibility for the quality of the work they produce.
A developer may or may not do the testing himself/herself but the key point is that the quality of the code is not someone else’s responsibility.
Understanding User NeedsInteracting with users as necessary to clarify requirements.

Developers will typically not be given a well-defined set of requirements. More often, the developer will get some general user stories that are intended to be a “placeholder for conversation” and the developer will be expected to interact with the Product Owner and users as necessary to better define what is needed.

This is essentially equivalent to a Business Analyst role on a very small scale.

Overall Summary

The role of a developer in an Agile environment is significantly different. Developers have additional responsibilities in an Agile environment that go beyond simply writing code.

Additional Resources

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

What’s Next After Agile? Is There Something Else Coming Next?

I recently saw a discussion on an online forum where an individual raised the question of “What’s next after Agile?”

  • Someone speculated that the next big methodology might be Lean
  • I’ve also seen some people suggest that Kanban will become the next big methodology

I’ve seen this pattern before – I call it the “Program Du Jour” pattern.  When something new comes along, everyone wants to jump on the bandwagon.

What's Next After Agile
Bandwagon with kids on a white background

Here’s one of my favorite quotes on this subject:

The “Program du Jour” Effect

“Americans are our own worst enemy when it comes to new business concepts. We love novelty and newness. We become so enamored with new ideas, we burn through them the way a child rips through toys on Christmas morning – squeals of delight, followed by three or four minutes of interest, then onto the next plaything. That is our pattern with new management techniques, too.”

Barry Sheehy, Hyler Bracey, & Rick Frazier, Winning the Race for Value, American Management Association, 1996

The above quote was about business concepts and management techniques but the same thing can be said about methodologies.

An Example – Six Sigma

Here’s an example:

  • When Six Sigma came into vogue in the 1990’s and early 2000’s, it was really hot, everyone wanted to jump on the Six Sigma bandwagon, and
  • Any other earlier process improvement approach was considered obsolete and passé.  

I published my first book on Business Excellence in 2003 and I interviewed a number of companies for my book at that time.  What I saw was that:

Superficial, Mechanical Implementation

Many companies were doing Six Sigma very superficially and mechanically.

  • In these companies there was a lot of “hoopla” and very visible ceremonies about Six Sigma including Black Belts, Green Belts, etc. 
  • The implementation in many of these companies was not very successful because the company was looking for a “silver bullet” and
  • When it didn’t meet their expectations, the company tossed it out and started looking for the next “silver bullet”.

More Successful Implementation

In other companies where I thought Six Sigma was more successful and lasting, there was a big difference.  

  • Six Sigma was seen only as a tool and not a “silver bullet” or panacea,
  • People in the company understood Six Sigma at a deeper level, and
  • The implementation was not just mechanical and superficial.  
  • Six Sigma was so well-integrated into the way the company did business that it might not even have been very visible that it was Six Sigma and
  • They might not even have called it “Six Sigma”

How Does That Apply to Agile Today?

I see a similar pattern with Agile today. 

  • Many people today see “Agile” as a “silver bullet” or panacea for almost any problem you might have.
  • In many cases the implementation of Agile is superficial and mechanical; and,
  • When it doesn’t work, there’s a tendency to toss it out and look for something new to replace it. 
  • I think that kind of thinking has some serious flaws.

Rather than Agile being replaced by something new, what I hope that will happen is that:

People’s Understanding of Agile Will Mature

People’s understanding of Agile will mature. They will start to understand the principles and values behind it at a deeper level, and they will go beyond superficial and mechanical implementations

People Will Stop Seeing Agile as a Panacea

People will stop seeing Agile as a “panacea” or “silver bullet” for any problem you might have. Rather than force-fitting all problems to some particular methodology like Agile, they will recognize the need to go in the other direction and fit the methodology to the problem

Agile” Does Not Make All Other Management Approaches Obsolete

People will also recognize that “Agile” does not make all other management approaches obsolete and:

  • There’s a need to see Agile and more traditional plan-driven approaches in a fresh new perspective as complementary rather being competitive
  • Various Agile approaches such as Scrum, Kanban, and Lean are also complementary to each other rather than competitive

Trends in Agile Development and Project Management

Although I don’t see something else replacing Agile, there are a number of trends that seem evident to me:

1. Convergence

Traditional plan-driven project management is beginning to converge with Agile. Agile started out as a revolution against traditional plan-driven project management practices (what many people loosely call “Waterfall”). That pendulum is starting to swing back to the middle. 

  • People are beginning to recognize that there isn’t really a binary and mutually-exclusive choice between “Agile” and “Waterfall”.
  • Rather than force-fitting a project to one of those extremes, a better solution is to fit the methodology to the nature of the problem. That may require a blend of both approaches in the right proportions to fit the situation.

2. Hybrid Approaches

Learning how to blend those approaches together requires understanding a broader range of methodologies at a deeper level.

  • Many people today do Agile somewhat mechanically “by the book” without really understanding the principles behind it.
  • That results in a somewhat rigid approach to how to apply Agile. That is exactly the opposite of the adaptive approach that is intended for Agile.

3. Scaling Agile

Many companies and people are attempting to scale Agile to larger and more complex, enterprise-level projects. That will accelerate both of the above trends. Agile was originally designed around small, simple, single-team projects and it can be difficult to scale. Scaling Agile often requires thinking about how to blend it with typical enterprise-level management practices. Those practices include project/program management, project/product portfolio management, and overall business management.

4. Enterprise-level Agile Transformations

Sometimes, an attempt is made to force a whole company to be agile in order to adopt an Agile development approach. That just isn’t completely realistic or desirable in some cases. Becoming Agile is not necessarily a goal in itself. It has to be applied in the context of the company’s most critical business objectives. What problem will it solve and how will it solve it?

Additional Resources

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

Scaling Agile and Scrum for Large, Complex Projects

There is a lot of confusion and some fairly polarized opinions about scaling Agile and Scrum for large, complex projects involving multiple teams. There are a number of different competing approaches for doing this.

Scaling Agile and Scrum

Scrum-of-Scrums and LeSS

  • Some people think that it can be done simply by adding a Scrum-of-Scrums approach to provide a mechanism to coordinate the efforts of multiple teams.
  • A more comprehensive approach for integrating the efforts of multiple development teams is Large-Scale Scrum (LeSS).
  • A Scrum-of-Scrums approach is a loosely-coupled approach that only provides for basic coordination of the work between teams – each team still operates fairly independently.
  • LeSS is a much more tightly-coupled approach that goes beyond the very basic level of coordination of work that the Scrum-of-Scrums approach provides.

The table below shows a comparison of the two approaches:

AreaScrum-of-ScrumsLeSS
Coordination of WorkFormal Scrum-of Scrum’s MeetingInformal, “Just Talk”
Product Backlog Management
(Single or Multiple Backlogs)
Not SpecifiedSingle Product Backlog
Sprint Planning
(Separate or Joint)
Not SpecifiedJoint
Sprint Review
(Separate or Joint)
Not SpecifiedJoint
Allocation of Work
(Component or Feature)
Not SpecifiedFeature

Selecting the Right Approach

The right approach will depend on the project and the need for a more loosely-coupled or tightly-coupled approach for integrating the development efforts. However,

  • Both of these approaches only address integration of the teams from a technical, development perspective and do not explicitly provide any mechanism for integration of the efforts from a business perspective.
  • It is assumed that the normal Product Owner role provides that level of integration but that may not be very realistic for very large, complex projects. This is really a multi-dimensional problem as shown in the diagram below:
Agile Scaling Dimensions

Scaled Agile Framework (SAFe)

The Scaled Agile Framework (SAFe) and other enterprise-level Agile frameworks recognize the need to provide this level of business integration with an appropriate level of program management and/or product/project portfolio management to ensure that the development efforts are well-integrated and well-aligned with the company’s business strategy.

Enterprise Agile Scaling Frameworks

Overall Summary

The ability to scale Agile to handle large, complex enterprise-level projects is a relatively new area that has a lot of confusion and conflict associated with it. It also poses some very significant challenges.

Confusion and Conflict

There is a lot of confusion and conflict in this area:

  • A number of people who see this from a development perspective tend to think that SAFe and other enterprise-level frameworks that address the problem of business integration are just unnecessary overhead and bureaucracy
  • Many people who see this from a business strategy perspective don’t understand the need for integrating development efforts from a technology perspective

Challenges

There are three major challenges that need to be considered:

  1. Integrating the efforts of multiple teams from a development perspective
  2. Aligning the efforts of all teams with the organization’s business objectives
  3. Coordination with other related efforts outside of the project team and providing tracking and progress reporting to management

Both the development integration perspective and the business integration perspective have merit and need to be considered when scaling Agile/Scrum to large, complex projects and all of the above challenges may need to be addressed to make a large, complex, multi-team Agile project successful.

Additional Resources

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

How to Prepare for PMI-ACP Certification

I think there is a lot of confusion among project managers about how to prepare for PMI-ACP certification – some people may think that:

  • Getting PMI-ACP certification is a matter of buying an “exam prep” book or taking an “exam prep” training course and then going out and taking the exam, and
  • Once you’ve taken and passed the exam, that is your “ticket” to get a job working in an Agile environment as a project manager

Both of those assumptions are far from reality, in my opinion:

How to Prepare for PMI-ACP Certification
Beautiful female graduate wearing a graduation gown

An Exam Prep Approach Doesn’t Work

You can’t just do some “exam prep” training and/or buy an “exam prep” book and go out and pass the exam for several reasons:

  • PMI won’t allow that – PMI requires a  minimum of 1,500 hours of working in an Agile environment before you can even apply to take the exam
  • There’s such a broad range of topics on the exam, it would be very difficult or impossible to pass the exam for someone who just “crammed” to pass the exam with little or no real-world Agile experience
  • Even if you could do that, simply “cramming” to pass the exam would have very limited value because it would have little credibility without some real-world experience to go along with it

PMI-ACP Isn’t a Ticket to Get a Job

Just getting a PMI-ACP certification is not likely to be a “ticket” to get a job as a project manager in an Agile environment for a  couple of reasons:

  • PMI-ACP is just a test of general Agile and Lean knowledge – it’s not designed to test your ability to perform a particular Agile role
  • The role of an Agile Project Manager is not well-defined and there is also some controversy that there is a role for a project manager in an Agile environment at all

How to Prepare for PMI-ACP Certification -What’s the Right Approach?

I think it’s a mistake for anyone to think that getting PMI-ACP certification is just a matter of going out and passing the exam and getting a job in an Agile environment. People have to develop more realistic expectations about it.  I recommend:

1. Understand the Real-world Role of an Agile Project Manager

First, it’s important to understand the roles that an Agile Project Manager can potentially play in the real-world:

  • Develop a vision for yourself of what that target role is
  • Understand the overall “road map” for moving into that role
  • Focus your training around that role

2. Understand the Role of PMI-ACP Certification

Next, its imporatnt to understand how PMI-ACP relates to other Agile certifications and where it fits into that road map.  For example:

  • A project manager who is new to an Agile environment may have to start out in a Scrum Master role to get some experience and
  • PMI-ACP isn’t the best approach to become a Scrum Master
  • CSM or PSM is much better-suited for getting into that kind of role as a first step

3. Don’t Limit Your Focus to Passing the Exam

Don’t limit your focus to simply passing the exam:

  • Focus on developing solid, credible, real-world experience and
  • Use the PMI-ACP certification exam to validate that you do have the knowledge and experience needed to perform that role

Overall Summary

It’s important to develop a strategy for preparing yourself for PMI-ACP certification.

  • Simply passing the certification exam should not be the primary goal
  • Focus on preparing yourself for a real-world role as a primary goal

My online Agile Project Management curriculum includes a training course for project managers called “What Is the Future of Agile Project Management”. That course is designed to help project managers develop a strategy for themselves and helps them understand how to position my other Agile Project Management courses in this strategy. 

Additional Resources

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

Blending Agile and Traditional Project Management