How Do You Choose the Best Methodology to Fit a Project?

I often see questions on “How do you choose the best methodology for a project?”

How do you choose the best methodology for a project?

What’s the Best Approach for Projects?

I don’t think that there is one single “best” approach that works for all projects.  A lot of people make the mistake of force-fitting a project to some standard methodology.

  • Some project managers will try to use a traditional plan-driven methodology for a project (what many people loosely call “Waterfall”) because it is the only thing that they know and it has been so widely-accepted as the way to do project management
  • Many other people have the misconception that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” and will attempt to force-fit a project to one of those extremes

The “best” approach is to go in the other direction and fit the methodology to the nature of the project.  That takes more skill but it definitely can be done.  You should also recognize that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.  There is a whole spectrum of different approaches ranging from heavily plan-driven at one extreme to heavily adaptive (or Agile) at the other extreme.

Range of Agility

How Do You Choose the Best Approach?

There are a number of factors that influence the selection of the best approach for a particular project.

    1. Level of Uncertainty – Probably the most significant factor in choosing an approach is the level of uncertainty in the project.  A project with a high level of uncertainty would be best-suited for a more adaptive (Agile) approach.  Attempting to force-fit such a project to a traditional plan-driven project management approach could be disastrous.
      • It would force you to make a lot of assumptions to try to resolve the uncertainty; and, in many cases, those assumptions may be wrong and require a lot of re-planning and possible re-work
      • The emphasis on planning and control in a traditional plan-driven project can create an environment that is not conducive to changes which will make it difficult to maximize the value of the solution in an uncertain environment
      • In today’s competitive environment, creativity and innovation can be very important to create very competitive business solutions and an approach with a heavy emphasis on planning and control can stifle creativity and innovation
    2. Customer Relationship – Managing customer expectations is probably one of the most critical aspects of any project.  If the results of a project are not consistent with customer expectations, the project will likely not be viewed as successful no matter how good you think it is.  The nature of the customer relationship can range from:
      • A contractual style of relationship where there are very definite and well-defined customer expectations that must be met.  In this type of relationship, the customer may not take any responsibility for the success of the project.  The customer defines what his/her expectations are and expects the project team to do whatever is necessary to meet those expectations with limited participation by the customer.
      • A collaborative style of relationship where there is a shared responsibility for the success of the project between the project team and the customer and the customer takes an active role in helping to define the direction of the project as it is in progress

      Naturally,  the contractual style of relationship is well-suited to a project with a relatively low level of uncertainty where it is possible to define the customer’s requirements in some level of detail prior to the start of the project.  It would be much more difficult to make a contractual-style relationship work in a project with a high level of uncertainty.

      Of course, the customer has to be amenable to whatever type of relationship you choose.  If the project has a high level of uncertainty, that would lean towards more of a collaborative relationship but the customer has to be open to that kind of relationship for it to be successful.  This is a big problem in many companies where it is difficult to break down organizational boundaries between organizations and establish truly collaborative relationships based on a spirit of shared responsibility, trust, and partnership.

    3. Project Team Capabilities – The final major factor in selecting a project approach is, of course, the capabilities of the project team.    An Agile approach requires a lot of training and skill and a hybrid Agile approach  can require even more training and skill.  Naturally, it does not make any sense to choose an approach that the team is not capable of implementing.

Why Is This Important?

There are two major factors that require us to broaden the way we think about “project management” today:

  • Solutions tend to be much more complex and the level of uncertainty is much higher
  • Competitive pressures frequently require much higher levels of creativity and innovation

For those reasons, force-fitting all projects to a standardized plan-driven approach that is oriented around planning and control to achieve predictability over project costs and schedules is not necessarily the best approach for all projects.

A project should be focused on producing value for the customer, meeting cost and schedule goals is only one component of value, and it may not be the most important component of value to the customer.  There have been many projects that have met their cost and schedule goals but failed to deliver an acceptable level of business value.  “Value” can be a very elusive goal but, in any case, it’s what the customer thinks that “value” is that counts.

Why is Change Management important for an Agile transformation?

Why is Change Management important for an Agile transformation? Implementing an Agile transformation can require a big shift in thinking and possibly also require changing a well-established corporate culture for many companies.  In general many companies need to move from an excessive emphasis on planning and control to a more flexible and adaptive approach with more emphasis on creativity and innovation in a very uncertain environment.  That requires:

  • Developing a spirit of trust and partnership among all parts of the organization at every level
  • Breaking down organizational barriers that might prevent a collaborative, cross-functional approach
  • Developing a clear, unifying vision for the organization that creates a common purpose that is well-aligned with the company’s business objectives

Those are not easy things to accomplish and creating lasting organizational change is difficult.  People resist change and will naturally revert back to the old, comfortable way of doing things if the change management effort is not successful.

Why is Change Management Important?

Kotter’s Change Management Principles

The best source on this is John Kotter’s book “Leading Change”. Kotter identifies eight errors that companies make in change management initiatives:

    1. “Allowing too Much Complacency” – This probably could be better stated…it isn’t necessarily a matter of “allowing too much complacency”. The real issue is that if there isn’t a feeling of urgency for making a significant change, it will be difficult to get support for making the change.
    2. “Failing to Create a Sufficiently Powerful Guiding Coalition” – Overall leadership is extremely important – all the key leaders have to be on board with making a broad-based, cross-functional change and providing the guiding leadership to make it happen.
    3. “Underestimating the Power of Vision” – A clear vision is needed for what the organization will look like after the change is complete. If there is no vision, it will be difficult to guide the change in the right direction.
    4. Under-communicating the Vision by a Factor of 10 (or 100 or Even 1,000)”. Major change is usually impossible unless most employees are willing to help, often to the point of making short-term sacrifices. But people will not make sacrifices, even if they are unhappy with the status quo, unless they think the potential benefits of change are attractive and unless they really believe that a transformation is possible.”
    5. “Permitting Obstacles to Block the New Vision” – The important points that Kotter brings up are:
      • Implementation of any kind of major change requires action from a large number of people
      • New initiatives fail when employees, even though they embrace a new vision, feel dis empowered by huge obstacles in their paths
      • Occasionally, roadblocks are only in peoples’ heads – In many cases, the blockers are very real
    6. “Failing to Create Short-Term Wins” Many times the best approach is to not take on too much at once but focus on some short-term wins that show progress.
    7. “Declaring Victory Too Soon”
      • People can be tempted to declare victory in a major change effort with the first major performance improvement
      • While celebrating a win is fine, any suggestion that the job is mostly done is generally a terrible mistake
      • Until changes sink down into the company culture(3-10 years) new approaches are fragile and subject to regression
    8. “Neglecting to Anchor Changes Firmly in the Corporate Culture” – Culture and values are extremely important – if people are simply mechanically implementing the change without any real change in corporate culture and values to support it, the change may be somewhat fragile and not long-lasting.

Three Most Critical Principles

All eight of the issues that Kotter has defined are important, but from my experience, there are three that are most critical that most frequently derail an Agile transformation.  These are:

  1. No “Burning Platform” – This is based on Kotter’s first error “Not Creating a Sense of Urgency”.  There needs to be something that creates some urgency about making a change because maintaining the current situation is very painful and untenable.The phrase “burning platform” originated with a fire on an oil-drilling platform off the coast of the United Kingdom some years ago.  The phrase can have several contexts –
    • One context was that there were serious safety issues with the platform that were not addressed until the platform caught fire because there didn’t seem to be a sufficiently urgent need to address them.
    • Another context was that once the platform was on fire, there was an urgent need for the employees to do something to save their own lives – staying on the platform at that point was an untenable situation.
  2. No Vision for the Future – This is based on Kotter’s third error “Underestimating the Power of Vision”.  Taking the time to define a vision for an Agile transformation is extremely important – many people make the mistake of using a one-size-fits-all approach to force-fit a company to some kind of “textbook” model.The best approach is to fit the model to the company’s business and a pure, top-to-bottom Agile approach may or may not be the best fit.  It may require more of a hybrid approach to achieve that kind of alignment, at least in the short-term.
  3. Failing to Show Short-Term Progress – This is based on Kotter’s sixth error “Failing to create short-term wins”.  There are always naysayers and skeptics who will remain on the sidelines waiting to see if the change is likely to be successful before they jump on the bandwagon.  That is why it is important to get started and demonstrate progress as quickly as possible.  From an Agile perspective, it is important to set clearly-defined and measurable goals that show progress and regularly communicate that progress to everyone involved.

Do Agile Methods of Management Make Any Sense?

I recently responded to a question on Quora that asked “Do Agile Methods of Management Make Any Sense?”. I thought it was an interesting question so I decided to make a blog post out of my response.Do Agile methods of management make any sense?

The “Program Du Jour” Effect

Agile has a similar pattern to many other new management approaches that have come before it.  This is what I call “The Program Du Jour Effect”:

  • Initially, there’s a lot of “hype” behind any new management approach that is fueled by the many consultants and trainers who have jumped on the bandwagon and want to sell their services
  • People start to see it as a universal solution for any problem you might have and all other previous management approaches are regarded as obsolete and are no longer relevant at all
  • The implementation becomes very superficial because people are looking for quick results without necessarily putting the effort that might be needed into really understanding it and making it work

I’ve Seen This Pattern Before

I’ve seen a similar pattern with Business Process Reengineering and Six Sigma. When I published my first book on Business Excellence in 2003, Six Sigma was very hot and everyone wanted to jump on the Six Sigma bandwagon. When I did the research for my book, I found that:

  • A number of companies did Six Sigma superficially, there was a lot of “hoopla” about it (Black Belts, Green Belts, etc.). That kind of effort wasn’t very effective and didn’t last long – they quickly threw out Six Sigma when it didn’t deliver magical results as quickly as expected and waited for the next management fad to come along.
  • In other companies, Six SIgma was simply a tool (and only one of many tools) that might have been used for process improvement, they might not have even called it “Six Sigma”, and it was so well-integrated into the way they managed their company that it might not have even been obvious that it was Six Sigma at all

Here’s a quote that I really like that I used in my first book on Business Excellence:

“Americans are our own worst enemy when it comes to new business concepts. We love novelty and newness. We become so enamored with new ideas, we burn through them the way a child rips through toys on Christmas morning – squeals of delight, followed by three or four minutes of interest, then onto the next plaything. That is our pattern with new management techniques, too.”
(Barry Sheehy, Hyler Bracey, & Rick Frazier, Winning the Race for Value, American Management Association, 1996  Page:  104)

Do Agile Methods of Management Make Any Sense?

If you understand the essence of what Agile is all about and use it appropriately in the context of how it is intended to be used, it has enormous value and makes a lot of sense. The essence of Agile is in being flexible and adaptive in a highly-uncertain environment and emphasizing an appropriate level of creativity and innovation in new product development and not simply emphasizing planning and control.

The alternative is to force-fit everything to a heavily plan-driven approach to management that heavily emphasizes planning and control only. That approach is clearly appropriate in some situations and not in others.  The key message is that:

  • We live in a complex world today with lots of uncertainty and a “one-size-fits-all” approach to project management no longer works well
  • You have to fit the project management approach to the nature of the project and that takes a lot more skill.  It is not simply a matter of picking up a standardized project management template with fill-in-the-blanks documentation

It is also not a simple matter of a binary and mutually-exclusive choice between Agile and Waterfall as many people seem to think.  It is  a matter of learning to blend those two approaches (and others) in the right proportions to fit a given situation.



Which Process Model is Best to Use In Software Product Development?

I recently saw a question on an internet discussion forum that asked “Which Process Model is Best to Use In Software Product Development?”.

Which Process Model is Best to Use In Software Product Development?

I’ve seen that kind of question come up over-and-over so it seemed like a good time to write a blog post to address it.

What’s Wrong With That Question?

There are at least a couple of things inherently wrong with that question to begin with:

    1. It implies that there is one process model that will work “best” in any possible software product development project

      If we just figure out which one is best, we can simply use that model for any software product development project you might imagine.  Wouldn’t that be wonderful if it were true?

      Unfortunately, software product development is not quite that simple.  You have to fit the methodology to the nature of the project  – you can’t just force-fit all software products to some universal development process.   And, that requires some good judgement, knowledge, and skill to know how to pick an appropriate model and adapt it as needed to fit a given project.  It isn’t as simple as having one universal model that works for all projects with a “cookbook style” checklist of what you need to do to make it work.

    2. It also implies that there is some way to easily make a determination that one model is inherently better than another.

      How would you make that judgement?  What would make one model “better” than another?  How can you make that determination objectively?

      There are many different factors that you might consider to determine which model is best but it certainly isn’t an easy determination to make.  It’s also difficult to create a side-by-side comparison of two models on the same project to really compare the performance objectively.

      That hasn’t stopped people from making a judgement that “Agile is better than Waterfall”. I’ve even seen studies that say that “Agile projects are statistically 2X more likely to succeed, and 1/3 less likely to fail than waterfall projects”.

      Reference to Standish Group 2018 Survey

      How do you make that determination?  How was “success” defined?  Was “success” really  defined the same way in both projects?

Which Process Model is Best to Use In Software Product Development?

So, what’s the real answer? Saying that “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’re in:

  • An Agile model tends to work best in projects where:
    • There is a relatively high level of uncertainty where a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
    • Creativity and innovation are needed to maximize the business value of the solution
  • A traditional plan-driven model (what many people loosely call “Waterfall”)  tends to work best where:
    • There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
    • The organization is not really  well-prepared to implement an Agile approach and/or the project team is not trained in Agile

The two factors that are making Agile so attractive in today’s environment are:

  1. A higher level of uncertainty in the environment
  2. Competitive pressures require more creativity and innnovation

However, that does not mean that there is no need for a traditional plan-driven model at all.  It would also be a mistake to think that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.

You have to fit the approach to the nature of the project and to the business environment.

Fit the approach to the project

There are many ways to create a hybrid model that blends Agile and traditional plan-driven project management principles and practices in the right proportions to fit a given situation.  And, sometimes it is necessary to do that to fit the model to the nature of the project rather than trying to force-fit a project to some arbitrary, predefined model.

What Are the Key Attributes of Post-Agile Development? What Problems of Traditional Agile Does It Try To Solve?

I recently responded to a post with the question: “What are the key attributes of post-agile development? What problems of traditional agile does it try to solve?”  I think people are looking for a new “silver bullet”

>What is Post-Agile Development?

What is Post-Agile Development?

I don’t really believe that there is such a thing as “post-Agile development”.  That implies that Agile will become obsolete and something really different will replace it.  However, I do believe that the use of Agile methodologies will continue to evolve and mature.

Trends in Agile Development and Agile Project Management

Some of the trends that are evident to me are:

    1. Traditional plan-driven project management is beginning to converge with Agile. Agile started out as a revolution against traditional plan-driven project management practices (what many people loosely call “Waterfall”) and that pendulum is starting to swing back to the middle.  People are beginning to recognize that there isn’t really a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. Rather than force-fitting a project to one of those extremes, a better solution is to fit the methodology to the nature of the problem which may require a blend of both approaches in the right proportions to fit the situation.
    2. Learning how to blend those approaches together requires understanding a broader range of methodologies (both plan-driven and Agile) and understanding them at a deeper level.Many people today do Agile somewhat mechanically “by the book” without really understanding the principles behind it. That results in a somewhat rigid approach to how to apply Agile which is exactly the opposite of the adaptive approach that is intended for Agile.
    3. A very big trend is that many companies and people are attempting to scaleAgile to larger and more complex, enterprise-level projects and that will accelerate both of the above trends.Agile was originally designed around small, simple, single-team projects and it can be difficult to scale without thinking about how to blend it with typical enterprise-level management practices including project/program management, project/product portfolio management, and overall business management.
    4. In some cases, an attempt has been made to force a whole company to be agile in order to adopt an Agile development approach and that just isn’t completely realistic or desirable in some cases. Becoming Agile is not necessarily a goal in itself – it has to be applied in the context of the company’s most critical business objectives – what problem will it solve and how will it solve it?

The “Program Du Jour” Effect

I’ve seen this pattern before – I call it the “Program Du Jour” effect.  Everyone is looking for a silver bullet that will magically solve all of their problems.  When one thing doesn’t work, they toss it out and try something else.

I saw that with Six Sigma in the early 2000’s.  When Six Sigma was hot, everything that came before it was obsolete and no longer relevant.  And, some companies made a fairly superficial attempt to apply Six Sigma, decided it didn’t work, and tossed it out waiting for the next “silver bullet” to come along.  Here’s a quote from my original book on Agile Project Management on that subject:

“Agile methodologies have the potential to have an enormous impact; however, like many other new and hot methodologies:”

  • “Consultants tend to swarm all over them and sell it as a cure for almost anything that ails you, and
  • Many companies and managers want to jump on this bandwagon and that further builds the hysteria in the market.”

“The result of this can be:

  • “Jumping into agile looking for a ‘quick fix’ without fully realizing that it takes a significant commitment to make it successful; resulting in superficial implementations that are likely to fail
  • Attempting to implement agile methodologies in a business environment or organizational culture that is inconsistent with an agile approach
  • Attempting to use agile methodologies for projects that they are inappropriate for or failing to blend a sufficient level of agility with the level of control that is needed”

If Agile is done correctly, it is a very broad, flexible, and adaptive approach for solving a number of different problems; however, it is not a “silver bullet” – it won’t solve any problem you might have.  I hope we’re getting past the “silver bullet” phase and starting to put the right amount of thought into applying Agile intelligently and continuously improving and refining it.

What is Agile? How Would You Define It? What Does It Really Mean?

What is Agile? I’ve seen a lot of discussions where people have attempted to answer the question of “What is Agile?”.   I’m sure that you could find at least 100 definitions of what “Agile” is on the Internet.

What is Agile?

Feeling the Elephant

It’s like the old fable of “The Blind Men Feeling the Elephant”:

“It was six men of Indostan
    To learning much inclined,
Who went to see the Elephant
    (Though all of them were blind),
That each by observation
    Might satisfy his mind[18]”

Each man came away with a different opinion depending on which part of the elephant he touched:

“Each in his own opinion concludes that the elephant is like a wall, snake, spear, tree, fan or rope, depending upon where they had touched”

The way people define Agile is somewhat similar,  Depending on which part you touch, you may come away with a different impression of what Agile is:

  • Many people will define Agile in terms of how it is done – for example, many people will say that it is defined by the Agile Manifesto.  Here are a couple of examples of that:

“Agile is a set of methods and frameworks that embody the principles  and values of the Agile Manifesto”

“Agile is a term used to describe approaches to software development emphasizing incremental delivery, team collaboration, continual planning, and continual learning. The term “Agile” was coined in 2001 in the Agile Manifesto.”

  • Some people will say that it is just a mindset or way of thinking.  Here’s an example of that.

“Being ‘Agile Is a mindset. It’s about finding the right thing to build, faster (and not just building things faster)”

  • Some people will define it by comparing it to “Waterfall” to tell you what it is not.  Here’s an example of that:

“Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.”

None of those definitions are incorrect, but it’s like “feeling the elephant” – they don’t really get to the real essence of what the “elephant” is, in my opinion.

What Is Agile?

Personally, I like the definition that is published by the Agile Alliance:

The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

I think that is a better definition because it gets to what I consider the real essence of what Agile is.

“Agile is best suited for situations that have some level of uncertainty where creativity and innovation are important to maximize the business value of the solution as opposed to other situations with lower levels of uncertainty where planning and control to achieve predictability are more important.” (My own definition)

We should acknowledge that Agile is not a solution to every problem you might have and one way to define it is in terms of what problems it is useful for.  When you step back and consider that Agile is not a solution to every problem you might have, I think the first thing you would want to know is “what problems is it useful for?”  You don’t need to get too far into the mechanics of how to do it until you’ve determined that it is a useful solution to the problem you’re trying to solve.

There is an interesting observation you might draw from this – people get very immersed in the mechanics of how to do Agile and that’s how they define it.  Isn’t it more important to know what problems it’s useful for solving before you get into the details of how to use it?

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.

Blending Agile and Traditional Project Management