Category Archives: Agile Project Management

What are the Most Practical Ways to Do Project Planning?

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

Factors to Consider

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

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

Planning Quadrants

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

What are the most practical ways to do project planning?

Lets look at each of these quadrants individually:

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

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

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

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

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

What are the Most Practical Ways to Do Project Planning?

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

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

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

Is Agile and Scrum Anti-Engineering?

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

Is Agile and Scrum Anti-engineering?

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

Importance of a Systematic Engineering Design Approach

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

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

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

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

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

When Does a Systematic Engineering Design Model Make Sense?

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

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

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

It is primarily a pure engineering design decision.

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

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

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

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

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

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

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

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

What Does This Mean For Project Management?

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

Summary of Key Points

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

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

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

 

Are There Project Managers in Agile?

I recently responded to a question “Are there project managers in Agile?” It’s a good question and it comes up often so I thought I would share the answer here in my blog. There’s actually a lot of “project management” going on in an Agile project, but it’s a different kind of “project management” and you may not find anyone at the team level in an Agile project with the title of “Project Manager”.

Are there project managers in Agile?

What is “Project Management”?

Here’s a definition of “project management” that I copied from a Quora discussion forum I participate in:

“Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives within the time, cost, scope and other relevant constraints”

That’s a fairly well-established definition of what “project management” is that hasn’t changed significantly since the 1950’s and 1960’s at least.  In fact, it is so well-established that many people see that as the only way to do project management and don’t even recognize Agile as a form of project management at all.

What’s wrong with that definition?

There have been many projects that have met their cost and schedule goals for delivering well-defined requirements yet failed to deliver a sufficient level of business value to offset the costs of the project.  That happens frequently in situations where there is a high level of uncertainty and risk associated with attempting to totally define the project requirements in detail prior to the start of the project. When you attempt to force-fit all projects to a traditional, plan-driven project management approach, you’re openly inviting failure if there is a high level of uncertainty in the project.

What Does a Broader Vision of “Project Management” Look Like?

What’s needed is to adopt a broader view of “project management” that is focused on producing value  and not simply meeting cost and schedule goals for well-defined requirements.  (Meeting cost and schedule constraints may be one component of value that the project produces but not the only component) That’s the challenge for project managers of the future. Project Managers of the future need to be able to take on a project with fairly broadly-defined objectives in a dynamic and uncertain environment and develop a solution to meet those objectives using whatever blend of traditional plan-driven project management and Agile principles and practices makes sense for that situation.

I recognize that is an ambitious vision and it will be difficult to achieve for many project managers to achieve but I think the survival of the project management profession depends on it. In the not-too-distant future, project managers who only know how to manage projects using a traditional, plan-driven approach to project management will become dinosaurs in many industry and application areas, in my opinion.

What is Needed to Get There?

PMI is moving slowly in that direction. The creation of the PMI-ACP certification at least recognizes Agile is important for project managers to understand but it doesn’t go far enough in my opinion – Agile and traditional, plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two and it is left completely up to the individual project manager to figure out how to put the two approaches together.

That is exactly the goal I have established for the online Agile Project Management training curriculum I’ve developed – to help project managers see these two approaches in a fresh new perspective as complementary to each other rather than competitive and to learn how to blend Agile and traditional, plan-driven project management principles and practices in the right proportions to fit any situation.

What Else is Different in an Agile Environment?

Another thing that is significantly different in an Agile environment is that the functions that might normally be performed by a single individual with the title of “Project Manager” are typically distributed among the members of the team at the team level rather than being done by one designated individual. For that reason, you typically will not find anyone with the title of “Project Manager” at the team level in an Agile environment.

Distributing the project management functions among everyone on the team has a lot of advantages in a dynamic and fast paced environment. Having a single “Project Manager” as a single point of focus for project management is appropriate in a traditional, plan-driven project where the emphasis is on control, but it is less than optimal in an Agile environment where there is less emphasis on control and more emphasis on flexibility and adaptivity and a single point of control can easily become a bottleneck.

What’s Left for a Project Manager to Do in Agile?

If there is no formal role for a “Project manager” at the team level in an Agile environment, the logical question is “what’s left for a project manager to do?”. There are a number of possibilities but you might not recognize any of them as a traditional project management role and all of them go beyond the skills of a traditional, plan-driven project manager.

  • At the team level, although you may not find anyone with the title of “Project Manager”, there is a need for “project management” and many of the team members may not be well-prepared to take on those functions.  In that environment, an experienced Agile Project Manager can help coach the other members of the team in how to integrate the necessary focus on project management with their work in an Agile environment. That can be done either by an Agile Coach who also has project management skills to coach and mentor the team members or by integrating someone who has project management skills with one of the other team roles such as the Scrum Master or Product Owner.
  • For various reasons, many companies will choose to implement a hybrid approach that blends an Agile and traditional project management approach.  An example would be Agile contracts.  There is a big opportunity for Agile Project Managers in this environment
  • Finally, at a higher level, there are a number of opportunities for project managers to take on larger and more complex projects and programs with multiple teams and to help companies develop a strategy for integrating Agile and traditional project management principles and practices in the right proportions with their business environment

For more on this, I suggest taking my free online training course called “How to Prepare for PMI-ACP Certification”. There is some material in that course on the potential roles that a project manager might play in an Agile environment.

The Evolution of Agile Project Management

There is a lot of confusion about the evolution of Agile Project Management – the Project Management profession is evolving and maturing:

  • From a role that is practiced exclusively by someone with the title of “Project Manager”
  • To a broad-based discipline that is much more fully integrated into the way companies do business

And:

  • From simply using a plan-driven project management approach for managing projects against well-defined requirements to meet cost and schedule goals
  • To a much broader focus on blending Agile and traditional plan-driven project management in whatever proportions are needed to drive business results in an uncertain environment

We’re still in the very early stages of that transformation, it will likely take a long time to fully evolve, and its causing some confusion and turmoil because its not totally clear how it will evolve.  However, I have seen a similar transformation happen in the quality management profession years ago and we can probably learn a lot from that.

At one time, “quality management” was something that was practiced exclusively by someone with the title of “Quality Manager” who owned responsibility for managing the quality of products and services in their company or their area of responsibility.  I was in such a role at one time – I was a Quality Manager at Motorola in the early 1990’s.  Motorola was a very large and successful company in those days, there were multiple layers of management, and the quality management chain-of-command was parallel to the normal business and operational management structure.

We were frequently getting directives from higher in the quality management chain-of-command to “go over and make the business and operational managers improve their quality in some way”.  That was a thankless role because the Quality Manager had to lead through influence and had no direct control over the people and processes he/she was trying to influence just as a project manager today may have to lead through influence.  That is very similar to the role of many typical project managers who are part of a PMO organization that doesn’t necessarily have direct control of the resources assigned to projects.

My manager at that time was very astute and enlightened and one thing I remember him saying was that “Our role is to teach, coach, and audit”, in that order.  What that means is that to be an effective Quality Manager, you can’t be an “enforcer” and you can’t be the only one who is responsible for “quality” in the organization.  A more effective approach is to engage others in the effort to improve the quality of the company’s products and services.  By teaching and coaching others to integrate quality management into the way they do their work, you can develop a much more broad-based level of commitment to quality management which was much more effective than a typical quality management “enforcement” approach controlled by someone called a “Quality Manager”.

A similar thing is happening in the project management profession today.  If you look at the way “project management” is implemented in an Agile project at the team level, you may not find anyone with the title of “Project Manager” but there is actually a lot of “project management” going on.  It’s a different kind of project management and the project management functions are distributed among other roles in the Agile team.  That’s probably a much more effective approach to project management – instead of only one person with the title of “Project Manager” being responsible for everything related to “project management”, there is a much more broad-based commitment to project management.

How does that impact project managers and the project management profession?  It is having a major impact and it’s causing a lot of confusion and turmoil at the moment.  There is likely to be a shift in the way “project management” is implemented just as there was a shift in the way “quality management” was implemented years ago.

  • The role of a PMO will likely change from an organization with an emphasis on control of all projects with a lot of restrictions and rules on how projects are managed to more of a consultative and supporting role to help others manage projects more effectively using a more adaptive approach to fit the nature of the project.
  • The role of a dedicated “project manager” will likely also be impacted.   Companies recognize the importance of “project management” and don’t want to give up that discipline but having a dedicated role called a “Project Manager” may not be the best way to preserve that focus.   As a result, some companies are trying to find people with project management skills who can also play other roles such as a Scrum Master or a Product Owner.

This is an evolving transformation, we are in the early stages, and I don’t pretend to have all the answers of exactly how it will evolve but there is no question that there is a transformation going on that we can’t ignore.  The curriculum that I’ve developed in the Agile Project Management Academy is designed to help project managers transform themselves into a high impact Agile Project Management role to align with this overall transformation in the project management profession.

 

What is an Agile Project Manager?

I’ve participated in some discussions recently that indicate that there is still a lot of confusion and controversy about what is an Agile Project Manager is. It’s understandable why this confusion exists:

  • There have been some very strong stereotypes built up over many years of what “project management” is and what a “Project Manager” is.  Those stereotypes are centered around the belief that “project management” is limited entirely to traditional plan-driven project management and project managers are so heavily engrained into that way of thinking that they can’t possibly adapt to an Agile environment.
  • 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 but PMI has never really defined exactly what an “Agile Project Manager” is and what role he/she might play in the real world.
  • Many people think of Agile in a very narrow sense as limited to simple, single-team Scrum projects; and, because there is no “Project Manager” role defined at that level, they assume that there is no role for Agile project management at all in an Agile environment; however, there is more to Agile than simple, single-team projects.

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 what an “Agile Project Manager” is.

First, we need to recognize that the discipline of ”project management” isn’t limited to traditional, plan-driven project management with an emphasis on planning and control just because that’s the way project management has been typically practiced for many years.  There is actually a lot of “project management” going on in an Agile project although 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 rather than the traditional emphasis on planning and control; however, if you take a broader view of what “project management” is, it is still project management.
  • And, although you may not find anyone with the title of “Project Manager” at a team level in an Agile project, there’s a lot of project management going on – the project management functions that would normally be performed by an individual with the title of “Project Manager” have just been distributed among the other members of the team:
    • 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.
    • The Scrum Master also has some responsibilities that might be done by a project manager including removing obstacles and facilitating the project team.  It may be a different style of leadership, but it is still leadership.
    • 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.

A related stereotype is that many people think that there is a binary and mutually exclusive choice between “Agile” and “Waterfall” and try to force-fit their projects to one of those extremes when a better approach is to go in the other direction and fit the methodology to the project.  And, “Agile” and traditional plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two.  There are many projects that call for blending those two approaches in the right proportions to fit a given situation particularly as you get into larger, more complex, enterprise-level projects.

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 and knows how to blend them together in the right proportions to fit a given situation.  That is exactly what the training I’ve developed is all about – it is designed to:

  • Help people see “Agile” and traditional plan-driven project management in a fresh new perspective as complementary rather than competitive, and
  • Help project managers better understand what “Agile Project Management” is and what they need to do to prepare for it

So What role might an “Agile Project Manager” play in a real-world project?

I think it’s sad that some project managers see there only alternative in an Agile environment is to become a Scrum Master because the role of an Agile Project Manager is so ill-defined and poorly-understood.  I hope that the Agile Project Management training curriculum I’ve developed can help project managers see this new perspective and lead the rest of the profession into demonstrating successful Agile Project Management leadership. In my training, 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

My training includes much more detail on this and several real-world case studies illustrating each of these roles.

What’s Next After Agile?

I recently saw a discussion on another forum where an individual raised the question of “What’s next after Agile?” and 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.  Here’s one of my favorite quotes on this subject:

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

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:

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

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, 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” or “silver bullet” for any problem you might have and 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
  • People will also recognize that “Agile” does not make all other management approaches obsolete and passé 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

This is exactly the kind of thinking I’ve tried to help people develop in the curriculum in the new Agile Project Management Academy.  To learn more about that, you can check it out here:

Agile Project Management Academy

Agile Project Management Academy

I am very pleased to announce the opening of the Agile Project Management Academy! The Agile Project Management Academy is an online school that is dedicated to helping project managers and other students learn how to successfully integrate Agile and traditional plan-driven project management principles and practices in the right proportions to fit any situation and to develop a very high impact and adaptive project management approach that provides the best of those two worlds.

You can enroll in the Agile Project Management Academy at no charge by clicking this link. There is no obligation to purchase a course if you enroll in the school and enrolling in the school will keep you informed of new courses and discount offers that become available. You can also enroll in either of these two free courses to try it out with no obligation:

Any of my Udemy students will recognize the courses in the Agile Project Management Academy as courses that have been offered on Udemy that have drawn over 10,000 students and over 300 5-star reviews. I will continue to offer these courses on Udemy; however, offering these courses through the Agile Project Management Academy creates some new opportunities that were not available on the Udemy platform. The new platform provides:

  • A dedicated focus on Agile Project Management that will help students realize the full benefits of these courses in a much more integrated environment
  • More ways for students to take courses including bundled discounts and subscriptions
  • Much more capabilities for direct communication with students to create a more interactive learning experience
  • The ability to integrate courses from other providers with my own courses to provide a more complete learning experience
  • Better and more timely support for students

I hope you enjoy this new capability! I am very excited to make it available! Enrollment in the school is free and anyone who registers in the school will receive email updates of new courses as well as enhancements to existing courses. You can enroll in the school at no charge here:

Agile Project Management Academy

You can find a summary of the courses that are offered as well as some discount coupons for all of the courses here:

Course Summaries and Discount Coupons

Please send me an email if you have any questions or comments on this new capability:

Send email to Chuck

For any student who has previously purchased one of my courses through Udemy, I will be happy to provide access to the equivalent course in the new Agile Project Management Academy at no charge. If you would like to take advantage of that offer, just send me an email.

What Certification Should I Get?

I’ve gotten lots of questions from students in my Agile Project Management training along the lines of “What certification should I get?”. It’s understandable that there’s a lot of confusion about this because there is so much change going on in this area and it can be somewhat of a moving target to decide where to take your career direction; however, I’m not a big fan of chasing after certifications and I’d like to share some of my thoughts on that subject…

First, a lot of people seem to view a certification as a “ticket to get a new job”…For example, almost anyone can get a Certified Scrum Master (CSM) certification if they can pay the money to sit through a 2-day training course. And, various training companies have done their best to promote this idea in order to sell their training courses. There are literally hundreds of what I call “exam-cram” courses out there that are designed to get you through a certification exam and little more than that. I don’t think that’s healthy – it does a disservice to the profession and to the people getting those certifications.

I think a better way to view a certification is evidence that you already have an acceptable level of knowledge, skills, as well as actual experience to perform a given job. Unfortunately, that’s not universally true in the way many certifications are designed and implemented in the real world, but that’s a better way to look at certifications in my opinion.

Here’s the approach I recommend to my students:

  1. Get a good base of knowledge to make a sensible decision of what you think is the best career direction for yourself. This is not an easy thing to do because the whole area associated with Agile and; in particular, Agile Project Management is rapidly evolving and the roles in this area are also changing and evolving. It can be a moving target to try to plan your career direction in this environment.
  2. Once you’ve made a decision on your most logical career direction, work on developing some more knowledge that is specific to that career direction
  3. Acquire some real world job knowledge from working in that role
  4. Decide what certification is most relevant to that role and get a certification to show that you have the appropriate knowledge, skills, and experience to do that job

A lot of people seem to want to short-circuit this process and just go out and get a certification and get a job and I think that could be a big mistake without doing steps 1-3 above first.

All of the Agile Project Management training courses I’ve developed are designed around helping people take a sensible approach to exactly this problem but you have to realize that it’s not just a matter of taking an “exam-prep” course and then going out and taking a certification exam. My courses are not really designed to be “exam prep” courses – they go beyond that and try to focus on the knowledge and skills to do the job in the real world. You can find information plus current discount coupons on all of my courses here:

http://agileprojectmanagementacademy.com/courses

In particular, my “How to Prepare for PMI-ACP Certification” course is a free course and has some very good information to compare various certifications related to Agile and Agile Project Management. If you have any questions about your own career direction, feel free to send me an email and I’ll be glad to help:

Send email to Chuck

My Methodology is Better than Your Methodology

There are a lot of people who get caught up in what I call “methodology wars” where they are intent on their position that my methodology is better than your methodology and whatever methodology they advocate is better at solving any problem you can possibly imagine than any other methodology. You can see this in the many “agile versus waterfall” discussions and other discussions where SAFe, Kanban, or some other methodology/framework is positioned as a “silver bullet” for any problem you might have. They also tend to ignore all other methodologies as obsolete or irrelevant.

The truth is that all methodologies and frameworks have strengths and weaknesses depending on the situation and the right approach is to fit the methodology to the situation rather than force-fitting a problem to some pre-defined methodology. Sometimes that may require customizing a methodology to fit the problem and/or using a combination of elements from different methodologies. It’s a lot more difficult to do that, but it can be done – it requires:

  • Knowledge of a broader range of methodologies and frameworks,
  • Ability to see the strengths and weaknesses of those methodologies objectively, and
  • A deeper understanding of the principles behind those methodologies to know how they might be combined to fit a given situation

Here’s an example – I just finished adding some material on “Lean Software Development” to my online training courses on Agile Project Management.  Lean is not widely-used as a standalone methodology and it clearly didn’t win the “methodology wars” but the principles behind lean are the foundation for all Agile methodologies including Scrum.  If you look at the principles behind lean, they may appear to be at odds with other Agile methodologies:

  • Lean heavily emphasizes eliminating waste in a process to improve efficiency, while
  • Agile is more heavily-focused on taking a flexible and adaptive approach to meet customer needs and is less concerned about just eliminating waste

If you pursued each of these goals in isolation and to an extreme; they might be in conflict with each other, but if they are blended together in the right proportions to fit a given situation, they can be very complementary rather than competitive.

Here’s another example – many people seem to believe that all forms of traditional project management are obsolete and irrelevant and have been totally replaced by Agile.  On the surface; if you look at traditional, plan-driven project management and Agile, they may appear to be at odds with each other; and if each approach is pursued in isolation and to an extreme, they probably will be in conflict but that shouldn’t preclude blending the principles behind the two approaches together in the right proportions to fit a given situation.

This kind of thinking is commonly called “Systems thinking” – it requires seeing a problem in a holistic context and understanding the dynamics of the problem at a deeper level rather than mechanically imposing a predefined solution on a given problem.  This is the kind of approach I’ve tried to help students develop in all of my online Agile Project Management training courses.

Agile Project Management Roadmap

I recently published an article on “Preparing for the PMI-ACP® Exam“. I want to expand on that article in the broader context of: What is the “Agile Project Management Roadmap” for a Project Manager with little or no Agile experience to become a well-qualified Agile Project Manager and where does PMI-ACP® certification fit into that process? Here’s a simplified, high-level diagram that shows what I think that process looks like and how the online training I’ve developed fits into that “road map”:

Agile Project Management Training Roadmap

Here’s some notes on this “road map”

  • It’s important to recognize that the typical Project Manager who has little or no Agile experience can’t just go out and take the PMI-ACP certification exam (even if they took at least 21 hours of training first), you need at least 1,500 hours of experience in an Agile environment to qualify to take the exam
  • In order to get 1,500 hours experience in an Agile environment, you need some knowledge to be able to perform that role. That’s the primary need that my current online training courses fill. Those courses provide an excellent foundation and an equivalent level of knowledge for most of the topics required for PMI-ACP but it’s more focused on preparing someone to assume a real-world role rather than “exam prep” training
  • After you get the 1,500 hours of experience, you need to take an exam-prep course before you can take the PMI-ACP® exam. A total of at least 21 hours of training is required to qualify to take the exam. My courses, as they exist now, will satisfy about 7.5 hours of this requirement
  • Finally, it’s important to recognize that getting PMI-ACP® certification doesn’t immediately give someone the skills to get a job. PMI-ACP® certification is a test of general Agile knowledge and is not oriented around qualifying someone to perform a particular role. This is a very controversial topic; but, in general, there is no role for an Agile Project Manager at the team level in an Agile environment, the typical role for an Agile Project Manager would be at a higher enterprise level and PMI-ACP® definitely does not prepare someone for that role. That’s requires additional training beyond the level of PMI-ACP® certification and that’s the need my Advanced Agile PM Training course are designed to satisfy.

It’s very important to recognize that Agile will precipitate a dramatic transformation of the Project Management profession as we know it today and PMI-ACP® certification is a good step in the right direction but I think most people will agree that it’s just a test of general Agile knowledge and doesn’t go far enough to prepare project managers for a specific Agile Project Management role and to address the real challenge that many project managers face of “How do I blend Agile and traditional Project Management” principles and practices in the right proportions to fit a given situation?”