Is Agile and Scrum Anti-Engineering?

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

Is Agile and Scrum Anti-engineering?

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

Importance of a Systematic Engineering Design Approach

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

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

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

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

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

When Does a Systematic Engineering Design Model Make Sense?

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

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

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

It is primarily a pure engineering design decision.

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

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

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

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

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

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

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

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

What Does This Mean For Project Management?

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

Summary of Key Points

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

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

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


How Do You Use Agile for Business Processes?

I was recently asked: “How do you use Agile for business processes?” Here’s my response:

Many people confuse Agile with Scrum and when they say “Agile”, they really mean “Scrum”. Scrum is not a solution to every problem but you can apply general Agile principles and Agile thinking to almost anything. It’s mostly just a shift in thinking rather than attempting to follow a well-defined Agile methodology like Scrum.  For example, I have written several books on Agile Project Management and I used a somewhat Agile process to publish the books:

  • I started out with a vision of what I wanted to do with the book and further elaborated it as I went along rather than having a highly detailed outline of exactly what the book would look like to start with
  • I engaged a group of people over the Internet to provide feedback and inputs. These people represented potential customers of the book as well as subject matter experts
  • I took an adaptive approach to adapt the design of the book based on the feedback I received
  • I used an incremental development approach. As I wrote each chapter or section of the book, I put it out for feedback and inputs and made adjustments as necessary based on that feedback and inputs

You can use that kind of thinking process on almost anything without necessarily following all the rituals of Scrum.

A lot of people also want to try to use Agile for business process improvement and that’s not necessary. There are lots of ways to improve business processes that are totally independent of Agile. For example, Agile is based on the ideas of continuous improvement that have their roots in Total Quality Management (TQM), Lean, Six Sigma, and other approaches that go back long before Agile. It isn’t essential to fully adopt Agile if what you really want is business process improvement.

Many people seem to want to jump on the Agile bandwagon because it is the latest and hottest buzzword to adopt but it isn’t necessarily a solution to any problem you might have.

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

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

What Are the Flaws in This Thinking?

Here are some of the flaws in this thinking:

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

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

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

    What is a hybrid agile approach?

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

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

    Adaptive vs Plan-driven

    As you can see from this diagram:

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

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

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

    Learning to be a “Chef”

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

    • “A good ‘cook’ may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.”
    • “A ‘chef’, on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.

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

What is a Hybrid Agile Approach?

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

Managed Agile Development Framework

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

What Are Examples of Hybrid Agile Approaches?

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

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

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

Why Are Tools So Important in an Agile Environment?

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

What’s the Right Context for Agile Tools?

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

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

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

Why Are Agile Tools So Important?

Why Are Agile Tools So Important?

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

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

How Are Agile Tools Different?

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

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

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

Discounted Agile Project Management Academy Courses

University Project Management Curriculum With Agile

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

University Project Management Curriculum with Agile

Similarities Between Project Management and Modern Physics

We can learn a lot from how the science of physics has evolved because I think there are a number of interesting similarities to the evolution that is currently going on in project management. For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”.

What is Classical Physics?

“Classical physics is the physics of everyday phenomena of nature, those we can observe with our unaided senses. It deals primarily with mass, force and motion. While its roots go back to the earliest times, to the Ancient Greeks such as Aristotle and Archimedes, it later developed into a cohesive system with the contributions of Galileo, Kepler and Newton. Classical physics achieved phenomental success, as the Calculus of Newton and Leibniz gave it the tools to tackle even even problems not imagined by its pioneers.”

“Around 1900, give or take a decade, surprising new experimental evidence, primarily about atoms and molecules, showed us that these small-scale phenomena behave in ways not anticipated by classical theory. This ushered in a new era called “modern” physics. New laws and methodology were developed to deal with the rapidly expanding experimental evidence. Relativity and quantum mechanics added new tools to the study of nature. These did not make classical physics “wrong”, for the old laws were working just as they always had, within their limited scope—which was the study of large objects (not atomic scale ones) moving relatively slowly (not near the speed of light). “

“So classical physics is still the starting point for learning about physics, and constitutes the bulk of the material in most introductory textbooks. It is the theory underlying the natural processes we observe everyday. It is the key to understanding the motion of pulleys, machines, projectiles and planets. It helps us understand geology, chemistry, astronomy, weather, tides and other natural phenomena”

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

What Happened to Cause People to Rethink Classical Physics?

That notion of physics that was intended to define how the entire universe worked held together for a long time; however, serious weaknesses began to appear around the early 1900’s:

“By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena. There was clearly a lot of cleaning up to do, but it looked like a fairly mechanical job: turn the crank on the calculator until the results come out. Apart from a few niggling problems like those lines in the light emitted by gas discharges, and the apparent dependence of the mass of high-speed electrons on their velocity”

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

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

How is This Transformation Related to Project Management?

Classical Physics is analogous to traditional, plan-driven project management. Similar to the laws of classical physics, the traditional, plan-driven project management approach has been widely accepted as the only way to do project management for a long time. And the way traditional, plan-driven project management is done hasn’t changed significantly since the 1950’s and 1960’s. It assumes a very predictable view of the world where it was possible to completely define a project plan with a fairly high level of certainty prior to the start of a project. That is similar to classical physicists who believed for a long time that a model of the universe could be completely predicted based on some relatively simple and well-defined laws of classical physics. In recent years; however, it is apparent that we are in a much more dynamic and more complex universe with much higher levels of uncertainty where that traditional, plan-driven approach to project management no longer works well at all.

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

What Can We Learn from This Similarity?

Traditional, plan-driven project management (just like Classical Physics) will never be totally obsolete and will continue to be a foundation for many areas of project management:

“…classical physics retains considerable utility as an excellent approximation in most situations of practical interest. Neither relativity nor quantum theory is required to build bridges or design cellphone antennas.”

The never-ending conundrums of classical physics,

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


“Classical Physics is usually concerned with everyday conditions: speeds much lower than the speed of light, and sizes much greater than that of atoms. Modern physics is usually concerned with high velocities and small distances.”

Similarly, project managers also need to recognize that a traditional, plan-driven approach to project management only works reliably in a limited set of situations. In the project management world, this can be expressed with the Stacey Complexity Model:


In this model there are two primary dimensions – one is requirements complexity and the other is technology complexity.

  • Traditional, plan-driven project management still works in areas of low complexity such as some construction projects but even in some of those areas, project managers have recognized a need for a somewhat more adaptive approach
  • As you get further out on either complexity axis, there is typically a need for more of an adaptive Agile approach that is better suited for dealing with uncertainty but this is not a binary and mutually-exclusive proposition. There is a need to blend both approaches in the right proportions to fit the situation

Implications for a University Project Management Curriculum with Agile

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

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

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

What's Next After PMI-ACP Certification?

Training Objectives

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

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

What’s the Future Like?

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

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

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

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

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

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

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.

What is the Real Essence of Agile?

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 “Agile” is really 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”.

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

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.

What’s the Alternative?

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 and 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)) and it 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.

In my book on Agile Project Management, I use the analogy of a project manager as a “cook” versus a project manager as a “chef”. A “cook” knows how to prepare a few simple “recipes” by the book; a “chef” knows how to prepare a much broader range of recipes with more exotic ingredients and even knows how to improvise his/her own recipes when required. This clearly raises the bar for a lot of project managers – it is no longer sufficient in many situations to force-fit a project to some predefined approach (whatever it might be). You have to fit the approach to the nature of the problem and that’s exactly the challenge that my online Agile Project Management training is designed to address.

When is Agile NOT Totally Appropriate?

I am often asked by my students “When is Agile NOT Totally Appropriate?”. 

When is Agile NOT Totally Appropriate?
Here’s a good example…

My wife and I are in the process of purchasing a new home that is now under construction.  This is the second new construction home we’ve bought in our lifetime.  The first time we built a new construction home, the builder did not allow much customization at all – there were very few choices that the builder allowed making in the house.   He gave us a price for the house and we had only a few minor choices to make.  It was clearly a traditional, plan-driven project management approach – changes were very limited and there was a very disciplined and well-documented process for managing any changes.

The builder that we’re currently working with is not that way – there are several different floor plans to choose from and almost anything can be customized.  For example, my neighbor wanted a 3-car garage instead of a 2-car garage and that was no problem (he had to pay for it of course).  Aside from customizations, there are also many detailed decisions that need to be made to select light fixtures, plumbing fixtures, floor tiles, cabinets, countertops, etc.

This is definitely more of an Agile approach that is adaptive to customer needs but there’s definitely a downside of allowing this level of customization without some level of control.  This particular builder has at least 20 houses in various stages of construction and all of them have some level of customization; so the builder has a lot of balls in the air at the same time and some problems have become apparent:

  • The first problem we experienced was when the foundation for the house was poured and we found that the floor plan was a mirror image of what we were expecting
  • Recently we did a walk-through of the house to see how it was coming along and we found several things that didn’t match what we thought we had agreed to with the builder
    • There was a window in the sunroom where there was supposed to be a sliding door
    • There was a door to a hallway where there should have been just an entranceway with no door
  • My next-door neighbors had problems with cabinets in their kitchen not fitting in as they expected them to fit

This is a perfect example of the need to blend Agile and traditional plan-driven project management practices in the right proportions to fit the situation.  This builder has been very responsive to customer needs for customization; however, there is still a need for a more disciplined approach to stakeholder management and  change control normally found in a traditional, plan-driven project management approach to manage all these detailed decisions and changes.  The builder corrected all of these problems but I’m sure that there was a cost involved in making those corrections that could have been avoided by doing it right the first time.

Another key point is that it is also not a binary and mutually-exclusive choice between a totally uncontrolled “Agile” approach and a rigidly planned and controlled “Waterfall” approach as many people seem to think.  It is very possible to blend a level of flexibility and adaptability to be responsive to customer needs and changes and still have a sufficient level of control to manage the project effectively.  It takes more skill to do that but it definitely can be done.  Having the right processes, systems, and tools to support that approach is also essential.   In this particular situation, there were some obvious problems:

      1. There was a contract defining what the builder will deliver; however, there have been multiple revisions of the contract still in circulation that have not been well-controlled so it is difficult to determine what has been agreed to and what has not been agreed to
      2. The process for making changes was not well-defined and was somewhat loose.   Many changes were often based on an email conversation or, even worse, on a simple hallway conversation that was not well-documented at all

The key lesson to be learned from this is that you need to fit the approach and the methodology to the nature of the situation rather than force-fitting all projects to either a pure “Agile” or pure “Waterfall” approach.  And, sometimes that requires blending Agile and traditional, plan-driven project management principles and practices in the right proportion to fit the situation.


Help Promote an Agile Project Management Approach

Would you like to help promote an Agile Project Management approach that could potentially rejuvenate the whole project management profession? (By the way, what I mean by “Agile Project Management” is the ability to blend Agile and traditional, plan-driven project management principles and practices in the right proportions to fit a given situation)

  • Are you as passionate about Agile Project Management as I am?
  • Do you agree that any project manager who only knows how to do traditional plan-driven project management will be at a serious disadvantage in many industries and application areas in the not-too-distant future?
  • Would you like to help the project management profession move into the next generation of project management?
  • Would you like to also earn some extra cash helping to bring about that change?

As many of you may know, I have developed a very comprehensive online training course on Agile Project Management with over 17,000 students.  However, that is only the beginning and I need help to try to dramatically expand the number of students the courses reach.

The new platform at the Agile Project Management Academy has some very interesting new capabilities such as  “affiliate marketing” that allows me to offer the capability for any student to be an “affiliate”.  If you are an “affiliate”, you will receive a commission of 25% for any new students you bring into the Agile Project Management Academy.

This is an opportunity for any student to earn a little extra cash to defer their own training expenses; or, if you are a PMI member, this could be an opportunity for your entire PMI chapter to get some additional revenue and get PDU’s for your members at the same time. If you’re interested in taking advantage of this opportunity, send me an email  and I’ll sign you up.

Blending Agile and Traditional Project Management

Protected with Antivirus