How Do You Apply Agile Techniques to Non-Software Projects?

Many people have asked “How do you apply Agile techniques to non-software projects?”.  I’ve done a lot of that myself in writing and publishing five books and designing and developing numerous online training courses so I thought I would summarize some of the techniques I’ve learned for doing that over the years.

Just Get Started

One of the most important principles I’ve learned is “just get started”.  When you’re faced with writing a book or developing a major online training course, it can be a daunting experience and just getting started is sometimes the hardest part:

  • We’re not sure how the final result is going to come out
  • We’re not certain how the final result will be structured – what should come first, etc.
  • We don’t want to produce something that is going to be a failure

You have to stop worrying about all of that and just get started.  I think of this kind of effort like developing a fine art sculpture.  You start with a lump of clay and you just keep molding and shaping it until it becomes a work-of-art.

How Do You Apply Agile Techniques to Non-Software Projects?

If you never get started, it will remain just a lump of clay.

  • It takes some courage and confidence in yourself to do this.  You’ve got to have courage and confidence that if you just get started, that somehow the final result is going to come out OK if you keep working at it
  • It also takes patience and commitment because you may have to go through a large number of iterations to get something useful out of it.  You may even have to throw something completely away and start over again

Use an Incremental and Iterative Approach

Many people don’t understand the difference between the words “incremental” and “iterative”:

  • “Incremental” means that you break up a solution into pieces and develop one piece (increment) at a time
  • “Iterative” means that if you’re not sure what a given piece should be, you develop something and then continue to refine that piece until you meet the customer’s expectations

Both of those are important:

  • Incremental Approach – using an incremental approach is very important.  In any large effort like writing a book or developing an online course, its best to break it up into “bite-sized pieces.  If you try to take on too much at once, you’ll never finish it.  The effort to write a book can easily take well over a year and it’s easy to get discouraged in that period of time that you will never finish if you don’t see progress in the work.
  • Iterative Approach – Taking an iterative approach is also important.  A close corollary to “Just Get Started” is “Don’t Expect Perfection”.  A major reason for not getting started sometimes is that we’re afraid to produce something that is less than perfect.  We have to accept that whatever we produce on the first iteration is certainly not going to be perfect and the final result may not be perfect either.  Get something done quickly and then continue to refine it as needed to meet customer expectations.There’s also a saying in Agile that is used a lot called “just barely good enough”.  We shouldn’t try to “gold-plate” or over-design something, it should satisfy the need to provide value to the customer and nothing more unless there is additional value in adding to the solution.  Keep it simple!

Know  Your Customers and Listen to Them

When I first started writing books, I had a lot of people who helped me.  I had a network of people on the Internet who provided me with lots of great feedback and inputs.  I would write a chapter or two of the book and put it out to my network for feedback and comments.  Part of doing that successfully is recognizing that you “don’t know what you don’t know”.  You have to be humble, listen to other people, and respect their needs and interests.  If you think that you know it all, you probably won’t be very successful.

In the online training I develop today, I get lots of feedback and inputs from students and I listen to it and take action.  As an example, I got some inputs from one of my students that one of my courses on preparing for PMI-ACP certification shouldn’t be a mandatory part of my overall Agile Project Management curriculum because some people didn’t care about getting the PMI-ACP certification.  As a result of that feedback, I split that course into two courses.

Refactor Your Work As You Go Along

I’ve done a fair amount of software development in my career and I’ve learned a lot from it.  I’ve learned the value of having clean and well-organized software because I have had to support a lot of the software I’ve developed.  Organization and flow of the material is particularly important in books and online training as well so it is essential to take time to go back and clean-up your work as necessary as you go along.  When I first write something, I get it done quickly but I may have to rewrite it and reorganize it 5-6 times before I’m satisfied with it.

Work at a Sustainable Pace and Do a Little at a Time

When you’re doing a long project like writing a book that can take well over a year and requires a lot of creativity and innovation, working at a sustainable pace is very important.  You can easily get burned out by trying to do too much too quickly and when that happens, your creativity can go downhill quickly.  Sometimes you need to put it down, walk away from it for a while, and come back when you’re refreshed to start work again.

Why Do People Have Trouble With This?

I think all of this is just good, common-sense things to do – why do people have trouble doing this?  I think many people think of Agile as Scrum and also think about doing it mechanically and aren’t sure how they would go about applying a Scrum process to this kind of effort.  Agile is not just Scrum – it is a way of thinking and we need to understand the principles behind it rather than attempting to follow a well-defined process and doing it mechanically and “by-the-book”.

Is Agile Just a Development Process? Are Project Managers in Denial?

Is Agile just a development process?  There seem to be a lot of project managers who are in “denial” about the influence of Agile on the project management profession.  They continue to think that there is only one way to do project management and that is the traditional plan-driven approach that hasn’t changed significantly since the 1950’s and 1960’s.

Is Agile Just a Development Process?

Is Agile Just a Development Process?

One rationalization I hear often is that some project managers will claim that Agile is not really a project management process it’s just a development process.  That’s fairly narrow thinking about what “project management” is that goes back to the days when the project management process could be separated from the development process.  In those days:

  • A project manager might have been somewhat of a high-level administrator who planned and managed projects and may or may not have had any direct role in managing the development effort needed to fulfill the project requirements.
  • He/she might have been a “middle-man” between the business customer and the development team.  He/she might have worked with the business customer to define and document the requirements and then worked with the development organization to negotiate resource commitments as well as the cost and schedule for completing the effort.

In many cases, the project manager might have had little or no direct role in managing the development team – that level of management might have been done through a functional development manager.  And, in some cases, the project manager simply held the development organization responsible for fulfilling the commitments that they had made and monitored their overall progress in fulfilling those commitments.

What’s Wrong With That Picture?

There are several limitations inherent in that style of project management.  The traditional plan-driven approach to project management  is optimized around achieving predictability by emphasizing planning and control.  For many years, a project was deemed to be successful if it met its cost and schedule goals for a given set of defined requirements.   That is how “success” has been defined for a long time.   In today’s world:

  • Levels of Uncertainty – There’s a much higher level of uncertainty in the world which makes a traditional plan-driven approach to project management very difficult to implement.  It’s just not very adaptive to uncertain and rapidly-changing requirements.  It typically forces you to make a lot of assumptions to try to resolve the uncertainty; and, many times, those assumptions will be wrong.
  • Creativity and Innovation – Competitive pressures create a significant need for creativity and innovation.  An overemphasis on planning and control is not very consistent with an environment that is needed for optimizing creativity and innovation.  Breaking down a lot of overhead and creating empowered, self-organizing teams that are in direct contact with the business users  creates an environment that is much better suited for creativity and innovation.
  • Need for Efficiency – Efficiency is also very important.  There is a lot of overhead in a traditional plan-driven approach to project management and there is not much emphasis on efficiency.  As long as the project was completed on time and under budget, no one typically looked very hard to see if there might have been a more efficient way of accomplishing that result.

Where Does that Leave the Project Manager?

All of that can be very threatening to many project managers because it might easily put them out of a job.  In fact, there is typically no role for a project manager at the team level in an Agile project.

I personally believe that there continues to be a role for project managers but it may be a very different kind of role and it requires rethinking what “project management” is and developing some new skills.  Project Managers who continue to insist that traditional plan-driven project management is the only way to do project management and who attempt to force-fit all projects to that approach will have a difficult time in the not-too-distant future.

I am sincerely interested in helping people in the project management profession better understand this challenge and to develop a strategy for reinvigorating their careers.  To that end, I have developed a very short training course that is called “What Is the Future of Agile Project Management?”  This course is eligible for one PDU and I am offering it to any project manager who wants to take it for a token amount of only $5:

What Is the Future of Agile Project Management?

This course should help you develop a new, broader, and more modern vision of what a project manager int he future might look like and help you answer the question: “Is Agile Just a Development Process?”.

New Course – What Is the Future of Agile Project Management?

I’ve just launched a new course entitled “What Is the Future of Agile Project Management?”  This is a very confusing topic for many project managers because the role of an Agile Project Manager in the real-world is not well-defined:

What Is the Future of Agile Project Management?

I frequently see questions from project managers asking like:

  • What certification should I get?
  • Should I become a Scrum Master?

It’s understandable that there is a lot of confusion about this because there is no defined role for a project manager in a typical Agile project at the team level.  There are roles that a project manager can play in an Agile but:

  • It may not be the typical, team-level project manager role,
  • It does require a big shift in thinking for a project manager to adapt to an agile environment, and
  • It’s a very different kind of “project management” that emphasizes creativity and innovation to maximize the value of the solution as well as some level of planning and control to achieve predictability

To fill this role, an Agile Project Manager has to learn how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation and that is exactly what my training curriculum  is designed to do.

This particular course is designed to help project managers understand the impact of Agile and Lean on the Project Management profession and on their own career paths and to develop a strategy to adapt to this new environment.   The course is a little over an hour long and includes material on the impact of Agile and Lean on the future of project management as well as some real-world scenarios where an Agile Project Manager can provide a lot of value in an Agile/Scrum environment.  It is designed to help project managers  understand how toreinvigorate their careers into a very high-impact Agile Project Management role.

I am offering this course for only $5 to anyone who would like to take the course.  You can click on the link below to take advantage of this offer:

What Is the Future of Agile Project Management?

Why Should Project Managers Care About Agile? What Is the Impact?

Why Should Project Managers Care About Agile? There are many people in the project management profession who are in “denial” about the influence of Agile. Here are some of the common reasons for a project manager might ignore the influence of Agile:

  • Many people seem to think that there is a binary and mutually-exclusive choice between an “Agile” approach and a “Waterfall” approach and “Agile” really only applies to software
  • Some project managers don’t see Agile as a legitimate form of project management although PMI has slowly come around to recognizing that with PMBOK v6

The truth is that Agile is changing the very nature of “project management” and, as a result, “project management is taking on a much broader meaning.

Why Should Project Managers Care About Agile?

A Modern View of What “Project Management” Is

The table below shows how the very nature of project management is changing as a result of Agile:

Views of “Project Management”
Traditional, Narrow View Modern, Broader View
Traditional “Project Management” is heavily associated with planning and control The competitive environment today requires an emphasis on creativity and innovation in addition to planning and control.

Simply planning and controlling a project is no longer sufficient. Can you imagine a leading-edge, high-technology product like a new iPhone being developed with a traditional, plan-driven project management approach?

Success in project management is defined by delivering well-defined project requirements within an approved budgeted cost and schedule Today’s world has a much higher level of uncertainty which makes it difficult to always start a project with well-defined requirements.

Business value is what is important and costs and schedules are only one component of business value. There have been many projects that met their cost and schedule goals but failed to deliver an appropriate level of business value.

Project management is only done by someone who has the title of “Project Manager” In an Agile environment, there is actually a lot of “project management” going on although you may not find anyone with the title of “Project Manager”.

The project management functions that might normally be performed by someone with the title of “Project Manager” have been distributed among all the members of the team and its a different kind of “project management” with an emphasis on producing business value in an uncertain environment.

Many project managers have difficulty accepting this kind of change because it fundamentally changes the definition of what “project management” is which can be very unsettling. They want to hold on to traditional notions of what “project management” is that haven’t changed significantly since “project management” was first formalized as a profession in the 1950’s and 1960’s, but project managers who ignore this change run the risk of being left behind.   In the not-too-distant future, project managers who only know how to do a traditional, plan-driven approach to project management may have a limited future in a number of industries and application areas such as software development.

Similarity to Quality Management

I worked in the Quality Management with Motorola in the early 1990’s and that profession went through a similar gut-wrenching change at that time. The old approach to quality management was heavily-based on inspection and control.

  • Lots of QC inspectors were employed to find defects in products before they shipped and
  • The role of a Quality Manager was to control the quality of products that were shipped and enforce quality standards.

Companies began to realize that approach was very inefficient and resulted in a lot of unnecessary scrap and rework of defective products. A much more proactive approach was needed that involved eliminating defects at the source by designing processes that were inherently reliable.

Implementing that kind of change required a very different approach to quality management…instead of an emphasis on control and inspection, it required coaching and mentoring people to integrate an emphasis on quality into any job and process that had anything to do with producing products.  The results were enormously successful, it resulted in levels of quality that were unattainable with a typical quality control approach, and that was how Six Sigma was originally conceived.

In those days, my manager used to tell me that “Our job as a Quality Manager is to teach, coach, and audit” in that order. In other words, you had to be a missionary to spread an emphasis on producing quality throughout the whole company rather than attempting to be totally responsible for “quality” yourself.  That’s exactly what is happening today with the project management profession – instead of a Project Manager attempting to be in control of all of the project deliverables, he/she needs to teach and coach others to take some level of basic project management responsibility including functions such as:

  • Planning and estimating their own work,
  • Building quality into the product rather than relying on someone else to find defects later,
  • Integrating with the rest of the team as a whole to produce an overall solution, and
  • Reporting on progress

It’s essentially a distributed approach to project management that engages everyone in the project management process instead of one Project Manager attempting to control everything.  In a very uncertain and dynamic environment, that has got to be a much more flexible and adaptive approach.

Why Should Project Managers Care About Agile?

The impact of Agile on the role of many project managers is likely to be significant. On small, single-team Agile projects, you may not find someone called a “Project Manager” at all; however, there certainly is a need for someone to coach and mentor the team on Agile Project Management practices. There is also a need for project managers on larger and more complex enterprise-level projects but even at that level, some understanding of Agile is essential. This “raises the bar” for project managers significantly. It requires project managers to develop a fresh new perspective to see Agile and traditional, plan-driven project management approaches as complementary to each other rather than competitive and to learn how to blend the two approaches in whatever proportions are needed to fit any situation.

What’s Needed to Adapt to This Change?

I’ve given a lot of thought to this problem and I am very passionate about helping project managers adapt to this change. Here are a number of articles I’ve written on this subject that should help project managers understand the impact of this change and begin adapting to it:

 

Articles on Agile Project Management
Article Synopsis
What Does Physics Teach Us About Agile Project Management Training? There’s a lot of similarity between the way that the science of physics has evolved and how project management has evolved:

  • For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”
  • “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.”
  • “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.”

In other words, the universe turned out to be much more complex, more dynamic, and less predictable than people thought it was. Isn’t that exactly what has happened with the project management profession?

What Does PMBOK v6 Mean For the Future of Project Management?

What is the Purpose of the New PMI Agile Practice Guide?

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

Up until this time, “Agile” and traditional, plan-driven project management have been treated as separate and independent domains of knowledge with little or no integration between the two.

What Does PMBOK v6 Mean For the Future of Project Management?

What is the Purpose of the New PMI Agile Practice Guide?

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

The PMP certification, as we have known it for a long time has been the mark of a very professional and well-qualified project manager; however, up until March 2018, the PMP exam has been totally based on traditional plan-drive project management.

PMI has recognized this limitation and in March of 2018 will begin to incorporate more Agile content in the PMP exam.

Is Project Management Obsolete? What Do You Think? Talks about the need to rethink what project management is if it is to thrive in the future.
Learn the Truth About Agile versus Waterfall Helps to overcome some misconceptions about Agile and Waterfall to see these two approaches in a fresh new light as complementary rather than competitive.

What Does Physics Teach Us About Agile Project Management Training?

What does Physics teach us about Agile Project Management Training?   We can learn a lot from how the science of physics has evolved and how universities have developed Physics curricula.  I think there are a number of interesting similarities to an Agile Project Management training curriculum.

Agile Project Management Training

What is the Similarity of Agile Project Management Training To Physics?

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?, https://www.lhup.edu/~dsimanek/ideas/allabout.htm

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”, https://www.trentu.ca/physics/history_895.html

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.

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, https://www.trentu.ca/physics/history_895.html

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:

modern-physics

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

https://en.wikipedia.org/wiki/Modern_physics

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:

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

What’s the Impact on Project Managers?

Just as new theories about Physics have significantly extended the notion of what “Physics” is beyond the traditional world of Classical Physics, Agile will have a similar impact on project managers.  The way this will probably evolve is very likely similar to the way that Physics has evolved:

  • In today’s world, there are people who specialize in Classical Physics and people who specialize in the more esoteric areas of Modern Physics; however, neither one of those areas can ignore the existence of the other area and a truly broad-based Physicist has a fairly solid knowledge of both of those areas
  • I believe that a similar thing is likely to happen in Project Management.  There will be project managers who continue to specialize in a traditional plan-driven approach to project management and project managers who specialize in Agile; however, just as in Physics,  neither one of those areas can ignore the existence of the other area and a truly broad-based Agile Project Manager has a solid knowledge of both of those areas

An Agile Project Manager is not a project manager who only works in an Agile environment.  It is someone who has a broad-based knowledge of both Agile and traditional plan-driven project management and knows how to blend those two approaches in the right proportions to fit any given situation.  The online Agile Project Management Training in The Agile Project Management Academy is designed around exactly this need.

 

What Does PMBOK v6 Mean For the Future of Project Management?

Background

PMBOK version 6 and the new PMI Agile Practice Guide signal a new direction for project management that, for the first time, starts to integrate Agile and traditional plan-driven project management. What does that mean for the future of project management?

I’ve written a number of articles on the future of project management and I still get a lot of questions from project managers who are confused about the impact of Agile on project management and ask questions like “What Agile certification should I get?”. Unfortunately, it’s not as simple as just going out and getting another certification like PMI-ACP and suddenly you are an Agile Project Manager.  The PMI-ACP certification is a step in the right direction and it’s not an easy certification to get but it’s just a test of general Lean and Agile knowledge and is not aligned with a particular role. In fact, the role of an Agile Project Manager Is not well-defined and there is even some controversy among some people that there is a role for an Project Manager In an Agile environment.

Confusion Over Project Management Direction

It’s totally understandable why there would be a lot of confusion among project managers as to how Agile and the future of project management impact their career direction.

  • There are some project managers who are in “denial” and want to assume that traditional, plan-driven project management is the only way to do project management, will go on forever unchanged, and Agile isn’t really a valid form of project management at all.
  • On the other hand, there are people in the Agile community who believe that there is no need at all for traditional plan-driven project management at all and Agile is a solution to almost any problem you might have

I’m not an Agile zealot – I try to take a very objective and pragmatic approach. In one of my courses I have a slide that says “Saying Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment. You have to be able to fit the approach to the problem rather than force-fitting all problems to one of those extremes. I am convinced that project managers who only know how to do traditional, plan-driven project management and try to force-fit all projects to that approach will be at a severe disadvantage relative to other project managers who know how to blend Agile and traditional project management in the right proportions to fit the situation.

What’s Wrong with Traditional, Plan-driven Project Management?

There’s nothing inherently wrong with the traditional, plan-driven approach to project management; the problem is in how its applied. The primary problem with the traditional, plan-driven approach is that it works for situations where the requirements are well-defined and the primary concern is planning and managing a project to meet those well-defined requirements within a given budgeted cost and schedule. That approach just doesn’t work well in situations where the requirements are much more uncertain and the primary concern is not just managing costs and schedules but taking an adaptive approach to maximize the business results and value that the project produces.  In today’s rapidly-changing business environment the need for taking that kind of approach is becoming increasingly common.

The Future of Project Management

There’s essentially two sides of this equation: value and cost – in the past, with most traditional plan-driven projects, the value side has been assumed to be well-defined and fixed and project managers only needed to worry  about the cost side.  In this new environment, that is no longer true – project managers now need to worry about both maximizing value as well as managing costs and schedules.  That’s a fundamental shift in thinking for many project managers – it means:

  • Taking a broader focus on maximizing the business value that a project produces and using whatever methodology (or combination of methodologies) that makes sense to achieve those goals
  • Fitting the project management approach to the nature of the business problem rather than force-fitting all projects to a standard, plan-driven approach.

That raises the bar significantly for many project managers.

What Certification Should I Get?

Some people seem to think that it is only a matter of getting another certification and I’ve participated in several discussions lately where project managers were asking questions like: “What certification should I get in order to get into Agile (CSM/PSM, CSPO, or ACP)?”  The answer to the question of “what certification should I get” depends on what role you want to play and it requires some thought and planning because there is no well-defined role for a project manager in Agile at the team level.  There are several possible career directions for project managers with regard to Agile.  You may not have to completely throw away your project management skills, but you would have to rethink them considerably in a very different context and you may not use some project management skills very fully at all depending on the role you choose.

  1. Become a ScrumMaster –  A ScrumMaster is what’s known as a “servant leader”. The Scrum Alliance defines the primary responsibilities of a ScrumMaster as follows:
    • Ensures that the team is fully functional and productive
    • Enables close cooperation across all roles and functions
    • Removes barriers
    • Shields the team from external interferences
    • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
    • Facilitates the daily scrums

    There’s a few project management skills that might be useful (at least indirectly) for that role but it doesn’t utilize much of the planning and management skills that a project manager typically has.  For that reason, becoming a ScrumMaster may or may not make sense as a career direction for many project managers.

  2. Become a Product Owner –  The Scrum Alliance defines the primary responsibilities of a Product Owner as follows:
    • The product owner decides what will be built and in which order
    • Defines the features of the product or desired outcomes of the project
    • Chooses release date and content
    • Ensures profitability (ROI)
    • Prioritizes features/outcomes according to market value
    • Adjusts features/outcomes and priority as needed
    • Accepts or rejects work results
    • Facilitates scrum planning ceremony

    The Product Owner role actually includes a lot of project management functions but it is actually much more similar to a Product Manager than a Project Manager.  The major differences are that:

    • The Product Owner is a business decision-maker and requires some business domain knowledge that a project manager may not have.
    • The Product Owner role doesn’t typically include many team leadership skills. In an Agile environment, team leadership is more a function of the ScrumMaster and the team itself.
  3. Hybrid Agile Project Management Role – For a lot of good reasons, many companies will choose to implement a hybrid Agile approach that blends the right level of traditional plan-driven project management with Agile. This is a very challenging role for a project manager to play because it requires a deep understanding of both Agile and traditional plan-driven project management to know how to blend these two seemingly disparate approaches together in the right proportions to fit a given situation.
  4. Project/Program Management of Large, Complex Enterprise-level Agile Projects – There is a legitimate role for project managers in managing large, complex enterprise-level projects; however, there are several things to consider about planning your career in that direction:
    • This role is limited to large, complex projects that typically require multiple Agile teams and require blending together some level of traditional plan-driven and Agile principles and practices in the right proportions to fit the situation. This role doesn’t exist at all on most small, single-team Agile projects.
    • This role requires some very significant skills that can be very difficult to attain. Many people may assume that the PMI-ACP certification qualifies you to perform this role. It is a step in the right direction, but a lot more experience and knowledge is needed to perform this role including:
        • Knowing how to blend traditional, plan-driven principles and practices in the right proportions to fit a given project,
        • Adapting an agile approach to fit a business environment, and
        • Scaling Agile to an enterprise level.

      You have to be a “rock star” Agile Project Manager to perform this role.

In many industries and application areas, the project management role associated with small, single-team projects may be completely eliminated by Agile. There may be some project managers who are not significantly impacted by this such as project managers in the construction industry, but even in those industries some knowledge of Agile principles and practices may be essential.

This creates difficult choices for a Project Manager to make, but the key message for any project manager should be that Agile will force them to make some significant choices about their career direction and it isn’t as simple as just going out and getting another certification (like ACP).

Agile Project Management Training

That’s exactly the challenge for the future of project management profession that the courses in the Agile Project Management Training I’ve developed are designed to address:

The Future of Project Management

What is the Purpose of the New PMI Agile Practice Guide?

PMI recently published PMBOK version 6 as well as a new document called “The Agile Practice Guide”.   The Agile Practice Guide is a totally new kind of document for PMI and raises some questions about “What is the purpose of the new PMI Agile Practice Guide?”

For a long time, PMI has treated Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two.  A major goal of these two new documents is to start to develop a more integrated view of these two areas and I think this is a major step forward to begin to close this gap.

A lot of people may have thought that integrating these two areas might be as simple as adding more content about Agile to PMBOK version 6 and that PMBOK version 6 would become a universal guide to both of these areas.  I don’t believe that to be a realistic way to accomplish that goal at all (See my article on Does PMBOK Version 6 Go Far Enough to Integrate Agile? )  As I mentioned in that article, that would be like trying to get Christians and Muslims to develop a unified view of religion by adding more words about Christianity to the Koran or more words about the Muslim religion to the Bible.  That approach just wouldn’t work.

What is the Purpose of the New PMI Agile Practice Guide?

Agile and traditional plan-driven project management are two radically different approaches to project management that each require significant individual focus; however, at the same time, we need to build a much more unified view of these two areas and I think that is exactly the role that the Agile Practice Guide attempts to fill.  Here’s how I see these various documents fitting together:

What is the Purpose of the New PMI Agile Practice Guide?

Here’s how I see this all fitting together:

  • PMBOK has become well-accepted for many years as the “bible” for a traditional plan-driven approach to project management; and, to some extent, some (not all) of the practices in PMBOK provide a general foundation for a general project management approach
  • Documentation related to Agile takes on a very different format which is based on some very simple and succinct values in the Agile Manifesto as well as other more specific documentation related to Agile practices such as Scrum, Kanban, etc.

Those two formats are very incompatible with each other in my opinion, but there is some commonality and we need to start to developing a more unified view to tie these two different worlds together.  That is the major purpose that the PMI Agile Practice Guide attempts to serve in my opinion.

What Does This Mean for the Future of Project Management?

This strongly reaffirms what I’ve been saying for a long time. The way of the future seems very clear:

  • There is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people have seemed to think and those two areas are actually complementary to each other rather than competitive.
  • There is a continuous spectrum of different approaches ranging from to heavily plan-driven (predictive) at one extreme to heavily adaptive (Agile) at the other extreme and the right approach is to fit the methodology to the nature of the problem rather than just force-fitting a problem to some predefined methodology (whatever it might be).
  • The project manager of the future needs to be proficient in both of these approaches and also know how to blend the two approaches as necessary to fit a given situation.  In the not-too-distant future, any project manager who only knows how to do traditional plan-driven project management and attempts to force-fit all projects to that approach will be at a serious disadvantage.

What is My Review of the Agile Practice Guide?

Here’s a brief summary of my review of the Agile Practice Guide:

General Comments:

  • Overall, I think this document is well-written and really helps to close the gap between Agile and traditional plan-driven (aka predictive) project management; however, that is a huge gap and there is still a lot more work to be done to create a truly integrated project management approach.
  • Agile and traditional plan-driven project management are two very different ways of thinking and it will be very difficult to fully integrate the two.  This is a great step in the right direction but it’s not the final step to close that gap.

Specific Comments:

  • Agile PM Role – I don’t think this document has gone far enough to address the real “elephant in the room” of “What exactly is the role of a Project Manager in an Agile environment?”. There are many project managers who are in denial about that and think that their project management role will go on indefinitely unchanged.  There is a need to address this issue more directly so that project managers can plan their future career direction.

In the back section of the document where it talks about the PMBOK Guide knowledge areas, in a number of different places it says that the role and expectations of a project manager don’t change in an Agile environment.  I don’t agree with that at all – the role of a project manager at the team level (if there is one at all) will likely change radically to more of a coaching and facilitation role than a traditional PM role.

  • Organizational Perspective – The authors of The Agile Practice Guide made a decision to limit the scope of this document to project and team-level work and to exclude discussion of the context of implementing Agile at an enterprise and organizational level.  I think that is serious a mistake.

Treating it as a project level function is much too limiting because most Agile implementations cannot be successful without some level of organizational transformation.  Furthermore, the role of a project manager is either non-existent or very limited at the team level and that will force many project managers to move up to more complex enterprise-level projects.

  • Agile Mindset – The section on “Agile Mindset” is really important and probably could be beefed up a lot. There is a big shift in mindset that is needed but it’s not just a matter of a choice between adopting an “Agile Mindset” or a “Traditional Project Management Mindset”.

In many cases, you need to blend the two approaches and take a broader view of what “project management” is that fully embraces both of those approaches.Many people would not view “Agile” as “Project Management” because it doesn’t fit the normal stereotype of what “project management” is; however it’s just a different form or “project management”.  That’s a big mindset change that PM’s need to make – we need to rethink what “project management” is in broader terms that include all forms of project management including Agile.

  • Relationship of Lean and Agile – I don’t agree with the graphic on page 11 showing that Lean totally encompasses Agile.  It does not – there is a lot of overlap between the two; however, taken to an extreme, each would tend to pull you in somewhat different directions.  Both are focused on customer value but lean is more heavily focused on efficiency where Agile is more heavily focused on flexibility and adaptivity.
  • Agile versus Predictive – The document talks about a spectrum of alternatives with predictive at one end point and Agile at the other end point.  The idea of a spectrum of approaches is right on but I don’t think that the use of the word “Agile” for an end point is the right choice.  Agile should not be an end point because there is not just one way to do Agile – there is a range of choices for Agile.  This spectrum should reflect different levels of planning and I think the end-points are “adaptive” and “plan-driven” (or “predictive”).
  • Hybrid Approach – The section on hybrid approaches needs to be improved. This is a critical area for PM’s to understand and, as it is currently written, this is too high level and not specific enough to help a PM understand how to really implement a hybrid approach.
  • Team Roles – I would like to see the discussion of team roles expanded.  One particular subject that is not covered is how many project functions that might normally be performed by a project manager have been assimilated into other roles in an Agile environment.  Agile uses a distributed form of project management.

Overall Summary

If you are a PMI member, you can download a copy of the Agile Practice Guide from the following link:

https://www.pmi.org/pmbok-guide-standards/practice-guides/agile

I am very pleased to see the PMI Agile Practice Guide being published.  It is definitely a step in the right direction and is very consistent with the integrated approach to Agile Project Management that I’ve developed in the Agile Project Management Academy.

This raises the bar significantly for project managers and will require a lot of retraining of project managers and rethinking of what “project management” is in much broader terms.

 

Does PMBOK Version 6 Go Far Enough to Integrate Agile?

PMBOK® version 6 was released recently and one of the big areas of change is that it has incorporates more guidance about Agile. Does PMBOK version 6 go far enough to integrate Agile?  I think that the release of PMBOK version 6 and The Agile Practice Guide is a huge step forward and is a noble attempt to create a more integrated approach for integrating Agile and traditional plan-driven project management. However, the full integration of Agile and traditional project management requires some very major shifts in thinking and it even involves something as fundamental as adopting a much broader definition of what “project management” is.

Does PMBOK version 6 go far enough to integrate Agile?

I don’t think that simply adding some words about Agile to PMBOK is going to be sufficient to bring about the kind of shift in thinking that I think is needed.

What is “Project Management?

The crux of the problem is that for many years the essence of what “project management” is has been centered on some very well-established stereotypes of what “project management is that are based on achieving predictability and repeatability as shown below:

Traditional Project Management Emphasis

That’s the primary way people have thought about what “project management” is since the 1950’s and 1960’s.  A successful project manager is one who could plan and manage a project to meet budgeted cost and schedule goals and that obviously requires an emphasis on planning and control.

The way to achieve predictability and repeatability has been to have a detailed and well-though-out plan and then control any changes to that plan.

Many people loosely refer to this approach as “Waterfall” because, in many cases, it has been implemented by using a sequential phase-gate process.  However,  I don’t believe that description is entirely accurate and I prefer to refer to it in more general terms as “traditional, plan-driven project management”.  (PMI has started using the term “predictive” to describe this kind of project management approach because the emphasis is on predictability).

What’s Wrong With That Definition?

In the 1950’s and 1960’s that approach worked well and it was particularly in high demand for large, complex defense programs that were well-noted for cost and schedule overruns.  At that time, the primary goal was to achieve predictability.  In fact, that approach has been so prevalent that it has essentially defined what “project management” is since that time and many project managers don’t see any other way to do project management.

The problem with that approach is it only works well in environments that have a fairly low level of uncertainty where it is possible to develop a fairly detailed plan prior to the start of the project.

In today’s world, there are several major factors driving change:

  1. The environment we live in has a much higher level of uncertainty associated with it which makes it very difficult, if not impossible to develop detailed plans prior to the start of a project in many situations
  2. Solutions are more complex and are much more difficult to design and optimize
  3. Competitive pressures demand high levels of creativity and innovation in spite of the level of uncertainty in the environment.  Producing high-value business results is more important than predictability in many cases.

This new environment demands a very different kind of project model that looks more like this:

Think of a typical new product today like the next generation of  the iPhone.  Do you think that a traditional plan-driven approach to project management with an emphasis on predictability, planning, and control would work well to develop that kind of product?

How Are These Two Approaches Different?

The differences in how these two approaches have been defined and implemented in actual practice are very significant:

Traditional Plan-driven Approach Agile
Approach
Process
Control
Model
Based on what is called a “Defined Process Control Model” which means that the process is well-defined and is not expected to change over the course of the project.

It is also repeatable and consistent across similar projects.

Based on what is called an “Empirical Process Control Model“.  The word “empirical” means “based on observation”.

That means an adaptive approach where both the product that is being developed and the process to create that product are continuously modified as necessary based on observation as the project is in progress.

PM
Emphasis
The emphasis of is on planning and control to achieve predictability over project costs and schedules The emphasis is on using an adaptive approach to maximize business results in an uncertain environment
PM
Role
Project management functions are typically implemented by someone with clearly-defined responsibility for that role called a “Project Manager” The functions that might normally be performed by a “Project Manager” at the team level have typically been distributed among other roles
Process
Definition
Relies on detailed process guidance such as PMBOK on almost every possible aspect of managing the project Based on some fairly simple and succinct principles and values (Agile Manifesto)
Project
Methodology
Typically uses a well-defined methodology Typically based on Scrum which is really more of a framework than a prescriptive methodology
Implementation Following a well-defined plan and process are typically important Reliant on the judgement, intelligence, and skill of the people doing the project to fit an adaptive approach to the nature of the project

Is the Agile approach shown above in the right-hand column not “project management?  A lot of people would not recognize it as “project management” because it doesn’t fit with many of the well-defined stereotypes of what “project management” is.  I contend that it is just a different kind of “project management” that will cause us to broaden our thinking about what “project management” is.

“Project Management” should not be limited to a particular methodology.  A project manager should be capable of delivering results using whatever methodology is most appropriate to achieve those results.

Is One Approach Better Than the Other?

There are a lot of Agile enthusiasts out there who will advocate that Agile is a better approach for almost any problem you might have.

My opinion is that saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – they both have advantages and disadvantages depending on the environment that you’re in.

  • An Agile approach works best in situations that have a relatively high level of uncertainty where creativity and innovation to find an appropriate solution are more important than predictability.   For example, if you were to set out to find a cure for cancer, it would be ridiculous to try to develop a detailed upfront plan for that effort.
  • A traditional plan-driven approach works well in situations that have a relatively low level of uncertainty and where predictability, planning, and control is important.  For example, if you were building a bridge across a river, it would be equally ridiculous to say “We’ll build the first span of the bridge, see how that comes out , and then we’ll decide how to build the remaining spans.

Are These Two Approaches Mutually-Exclusive?

A lot of people have the mistaken belief that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”:

  • There has been a lot of polarization between the Agile and project management communities for a long time and many people in these two communities have seen these two approaches in conflict with each other
  • PMI has treated these two areas as separate and independent domains of knowledge for a long time with little or no integration between the two

It takes a higher level of skill and sophistication to see these two approaches in a fresh new perspective as complementary to each other rather than competitive and to learn how to blend the them together in the right proportions to fit any given situation but it definitely can be done.

Does PMBOK version 6 go far enough to integrate Agile?

I have ordered a final copy of PMBOK Version 6 and haven’t actually seen it yet; however, I have seen early preview editions and I think I understand where it is trying to go. I have several concerns:

  1. As I’ve mentioned, I think that there is a huge and fundamental shift in thinking that is needed to rethink what “project management” is.  I’m not sure that simply adding some words about Agile to PMBOK is going to help people make that shift in thinking to see “project management” in a fundamentally and radically different perspective.
  2. The whole concept of PMBOK does not seem to be very consistent with an Agile approach:
    • Agile is based on some very simple and succinct principles and values and relies very heavily on the training and skill of the people performing the process to interpret those principles and values in the context of a project
    • The latest version of PMBOK is over 700 pages long – it’s supposed to be a “guide” but it seems to try to provide a detailed checklist of things to consider for almost any conceivable project management situation

    Putting those two things together is like trying to mix oil and vinegar – they just don’t blend together very well and attempting to blend the two approaches at that level doesn’t seem to make much sense to me.

What is the Solution?

This is definitely a challenging problem.   It’s sort of like trying to get Christians and Muslims to agree on a unified view of religion.  They both believe in God but they  have very different ways of worshiping that we’re not likely to change.  A similar thing could be said about Agile and traditional plan-driven project management – they both have a common goal of delivering business results but the way each approach goes about doing it is very different.

There are two significant components of the solution to this problem:

  1. Developing an Integrated View of Project Management – Somehow, we have to create a much more unified view of what “project management” is that fully embraces Agile as well as traditional plan-driven project management.  However, modifying PMBOK to totally integrate Agile would be like trying to modify the Koran to totally integrate a view of Christianity into it.  It just wouldn’t work at all.  If you were to set out to create a unified view of religion, that approach would be ridiculous.  A better approach would be to cross-reference the Bible and the Koran to identify areas of similarity and then create an over-arching guide to blend the two approaches together to create a unified view of religion.
    I believe that is essentially what PMI has attempted to do with The Agile Practice Guide which I  discussed in a separate article.  For a long time, PMI has treated Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two areas.  The new Agile Practice Guide attempts to bridge that gap and show a more integrated approach to those two areas.  I think that is the only reasonable strategy that makes sense.
  2. Develop a New Breed of Agile Project Managers – This “raises the bar” significantly for the whole project management profession.  In my Agile Project Management books, I have often used the analogy of a project manager as a “cook” versus a project manager as a “chef” that was originally developed by Bob Wysocki:
      • 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

    I think that sums up the transformation that needs to take place – Agile “raises the bar for the project management profession significantly and what we need to develop are more project managers who are “chefs” rather than “cooks”.  PMBOK is based on a “cookbook” approach to project management and attempting to blend an “Agile” cookbook with PMBOK is not going to make it much better.

    This is exactly the challenge that the Agile Project Management training I’ve developed is designed to address.

Is a PMP Certification Still Relevant in Today’s World?

I recently participated in an online discussion where someone asked the question “Is a PMP certification still relevant in today’s world?” I thought is was a good question. I am a PMP myself, I have had a PMP certification since 2004, and I’m proud to be a PMP but I recognize the limitations of a PMP certification.

IS a PMP Certification Still Relevant?

What Are the Limitations of PMP®?

PMP is heavily based on a traditional plan-driven project management approach (what many people loosely call “Waterfall”) and the world is rapidly changing today.  There’s nothing inherently wrong with a traditional plan-driven approach to project management under the right circumstances, but we definitely shouldn’t try to force-fit all projects to that approach.

  • A traditional plan-driven approach to project management works well in situations where there is a relatively low level of uncertainty and predictability is important
  • It does not work well in situations with a high level of uncertainty where creativity and innovation are more important than predictability

In today’s world, a project manager needs to be capable of using a broader range of methodologies (Agile and plan-driven) to fit the nature of the project rather than force-fitting all projects to a traditional plan-driven approach.  Situations are becoming increasingly common that require a more adaptive approach due to rapidly-changing technology and a very dynamic and very competitive business marketplace.

For those reasons, Agile is having a profound effect on the project management profession in many areas that will cause us to rethink the way we do project management.  That doesn’t mean that traditional plan-driven project management and PMP are obsolete but we’ve got to think of project management in broader terms and recognize that traditional plan-driven project management is not the only way to do project management.  Check out this article for more on that:

What is “Agile” and Why Is It Important to Project Managers?

Is PMI-ACP® the Answer?

PMI-ACP is a step in the right direction but it doesn’t go far enough in my opinion.  PMI-ACP is only a general test of Lean and Agile knowledge and it doesn’t really address the big challenge that many project managers face today of “how do I blend Agile and traditional plan-driven project management in the right proportions to fit a given situation?”  Unfortunately, PMI still treats Agile and traditional plan-driven project management as fairly separate and independent domains of knowledge with little or no integration between the two.

What About PMBOK® Version 6?

We all know that the final edition of PMBOK version 6 is due to be released in September 2017 and it is supposed to contain more references to Agile.  I haven’t seen the final version of PMBOK version 6 yet but I can’t imagine that it will solve this problem either.  The whole concept behind PMBOK is not very compatible with an Agile approach.  These are two very different ways of thinking:

PMBOK Agile
PMBOK is based on the idea that you can develop a checklist of things to consider in almost every conceivable project management situation that you can imagine. Agile requires a very different mindset.  An Agile approach needs to be much more adaptive and it would be impossible to develop a checklist defining what to do in every conceivable situation you might find yourself in in an Agile environment.
PMBOK and traditional plan-driven project management are based on a defined process control model Agile is based on an empirical process control model which means that both the product and the process to produce the product are continuously adapted based on observation throughout the project
PMBOK  is over 500 pages long with lots of details on what to do or consider  in various situations Agile is based on some very brief and succinct principles and values without a lot of detail and expects you to figure out what to do in a given situation.
PMBOK  is also based on compartmentalizing a project into distinct and well-defined process groups Agile requires a much more holistic and integrated approach to project management

So What is the Long-term Solution?

This is not an easy problem to solve. In the long-term, the solution to this problem is likely to involve some very significant rethinking of both PMBOK and PMI certifications to create a much more integrated approach for blending Agile and traditional plan-driven project management principles and practices; however, that is a very difficult problem to solve and is not likely to happen for a while.

Some elements of PMBOK and PMP are definitely useful as a foundation for any kind of project management; however, the depth of study and knowledge required for PMP certification tends to “brainwash” people into thinking that is the only way to do project management and that is not the case.  Someone who only wants a foundation of knowledge in traditional plan-driven project management principles probably doesn’t need that depth of knowledge.

What’s probably needed in the long-term is something like a “PMP Lite” that provides a foundation of project management knowledge without the depth of knowledge that is in PMP for someone who wants to ultimately move into an Agile Project Management role. Here’s what this new certification structure might look like:

Is PMP Still Relevant in Today's World?

The full PMP certification (as it exists today) would still be appropriate for any project managers who plan to specialize in traditional plan-driven project management; however, that depth of knowledge in plan-driven project management should not be needed for someone who wants to develop an integrated Agile Project Management approach.

What’s the Short-term Solution?

In the short-term:

  • If you already have a PMP certification today, that knowledge is a good foundation to begin to develop a broader focus on an Agile Project Management approach; however, it does require a lot of rethinking of how to do project management and also requires a very different mindset.
  • If you don’t already have a PMP certification today and are early in your career as a project manager, you have a much more difficult choice to make between two directions:
    1. Getting a PMP – Making a significant investment in time and money to get a PMP certification and then perhaps moving on to learn an Agile approach sometime later.  If you are working in an industry or application area where traditional plan-driven project management is still the dominant way of working, that might be  a reasonable choice.
    2. Skipping PMP – If you’re not working in an industry or application area where traditional plan-driven project management is the dominant way of working, getting a PMP may not make sense.  Certainly, some foundation of traditional plan-driven project management is worthwhile but you may not need a full PMP.  An alternative is to skip getting a PMP and just focus on developing an integrated approach to  Agile Project Management.

In my opinion, skipping PMP and developing a more integrated Agile Project Management approach seems reasonable for anyone who doesn’t already have a PMP and is interested in an Agile Project Management role.  However, it is a very difficult path to follow in the short term  because there is currently no certification built around an integrated approach to Agile Project Management and the knowledge base is not well-developed either.  For that reason, you have to be somewhat of a “pioneer” in choosing this direction and with no certification, “you don’t know what you don’t know”.

What is ‘Agile’ and Why Is It Important to Project Managers?

I think a lot of people are confused about “What is ‘Agile'” and the importance of Agile to project managers.  The word “Agile” has many different connotations and many project managers think that it is something that only applies to software development and doesn’t apply to them at all.

What is ‘Agile’?

What is 'Agile'
“Agile” means a lot of different things to different people:

  • To some people it means just developing software faster,
  • To some people, it means creating a more people-oriented project environment,
  • To others, it means making the project management process a lot more efficient by streamlining the whole process and eliminating unnecessary documentation

Those are only a few different connotations – there are many, many more. There are also many more stereotypes, myths, and misconceptions about what Agile is. All of those things are potential outcomes of an Agile process but that’s not the fundamental essence of what an Agile process is all about in my opinion.  The fundamental essence of an Agile process is adaptivity.

What’s Wrong With the Typical Project Management Approach?

Many project management processes, as we know them today, were designed around what is called a “traditional plan-driven project management” model (what many people loosely call “Waterfall“).  In this model, achieving predictability over the outcome of a project and the costs and schedule associated with achieving that outcome is very important.  Therefore, it is also very important to have clearly defined requirements as well as an adequate level of planning to be able to somewhat accurately predict the outcome, costs, and schedule of the project.

That’s the predominant way that project management has worked since the 1950’s and 1960’s. A project was considered successful if it delivered what the requirements for the project called for within the defined budget and schedule. That kind of predictability can be important – for large investments, it allows a company to:

  • Attempt to calculate with some level of certainty what the return on their investment is likely to be from a project
  • Make a go/no-go decision as to whether the project should be funded or not based on that information.

The primary problem with that approach is that it requires developing a fairly detailed plan for the project upfront and that is very difficult, if not impossible to do in projects with a very high level of uncertainty.

Why Is Adaptivity Important?

We live in a different world today from the world that existed in the 1950’s and 1960’s when formalized project management approaches were first defined.  There is a much higher level of uncertainty:

  • Technology is rapidly changing,
  • Solutions are much more complex, and
  • The business environment that we operate in is dynamic and constantly changing.

In that kind  of environment, if you attempt to develop a detailed plan for a project with a lot of uncertainty upfront, it will typically require you to make a lot of assumptions, many times those assumptions will be wrong,  and that may require significant re-planning and possible rework later.

Rather than force-fitting a project that has a high level of uncertainty to a traditional plan-driven approach, it’s much better to fit the methodology to the nature of the project and that’s where a more adaptive approach really makes sense.  It doesn’t mean that you don’t do any upfront planning; it means that you use a level of planning that is appropriate to the level of uncertainty in the project:

Traditional Plan-driven Approach Adaptive (Agile) Approach
Atempt to develop a detailed set of requirements and a detailed project plan for the project upfront Limit the amount of upfront planning based on the level of uncertainty in the project and use a “rolling-wave” planning approach to further define the requirements and plan for the project as the project is in place

What’s an Example of a Project Requiring an Adaptive Approach?

I use an example in my Agile Project Management training that is a somewhat extreme but it gets the point across. The example I use is:

Suppose you were given the task to find a cure for cancer and you were asked to outline what the solution will be, how long it will take to develop it, and what the total cost of the research will be to develop the solution.

In that situation, it would be ridiculous to attempt to develop a detailed project plan with accurate cost and schedule estimates – there is just way too many uncertainties to resolve. So what would you do? Give up and do nothing? That doesn’t make sense either.

In that situation, we do know some things about finding a cure for cancer based on years of research that have gone into that area but there are still way too many unknowns to develop a detailed project plan for a solution. What you would do is take advantage of what is known as much as possible and then take an iterative, trial-and-error approach to find a solution.

That’s the way Edison invented the light bulb…here’s a quote from Edison on that subject:

“I speak without exaggeration when I say that I have constructed three thousand different theories in connection with the electric light, each one of them reasonable and apparently to be true. Yet only in two cases did my experiments prove the truth of my theory. My chief difficulty, as perhaps you know, was in constructing the carbon filament, the incandescence of which is the source of the light.” (1890 Interview in Harper’s Magazine)

In a 1910 autobiography of Edison, Edison’s friend and associate Walter S. Mallory is quoted as asking “Isn’t it a shame that with the tremendous amount of work you have done you haven’t been able to get any results?”  The book goes on to say that “Edison turned on him like a flash, and with a smile replied: Results! Why, man, I have gotten lots of results! I know several thousand things that won’t work!”

What Makes This Kind of Project Different?

There are two things that make this kind of project fundamentally different:

  1. The level of uncertainty is very high and makes it impractical or impossible to develop a detailed plan for the project upfront
  2. Creativity and innovation required for finding a good solution are far more important than predictability

How Does an Agile Approach Solve This Problem

An Agile process is built on an “Empirical” Process Control model. The word “empirical” means “based on observation”. In the context of an Agile development process, it means that during the course of a project, both the product as well as the process to produce the product are continuously refined as the project is in progress to produce the right product and to optimize the value of the product being produced.

Empirical Process Control Model

Why Is This Important to Project Managers?

You might ask “Why is this important to project managers?” Isn’t Agile something that only applies to software development? (That’s a common misconception) The truth is that all projects have some level of uncertainty associated with them and if you try to force-fit all projects to a traditional plan-driven project management approach, its just not going to work in many cases. Imagine, for example, trying to develop the next generation of the iPhone or any other new and innovative product. In that kind of project, creativity and innovation is just as important, if not more important, than predictability.

In this new environment, a project manager who only knows how to do a traditional plan-driven approach to project management will be at a serious disadvantage. What makes this even more difficult is that this is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. It’s a matter of figuring out how to blend a traditional plan-driven approach with an adaptive (Agile) approach in the right proportions to fit a given situation.

That requires a lot of skill to do that but it definitely can be done and that is exactly what the Agile Project Management Training I’ve developed is designed to address.

Blending Agile and Traditional Project Management

Protected with SiteGuarding.com Antivirus