Is Agility Just a Toolkit?

I saw a blog post this morning that I have to respond to because it is so misguided and misleading. The blog post is entitled “Project Managers – Is Agility Just a Toolbox That You Can Simply Pick and Choose From?“.

The essence of this post is that there are project managers who have acquired “a PMI-ACP certification and little else in real-world Agile experience” and see “agile and traditional project management as a toolbox” that they can just mix-and-match together. There is an implication that I and others who have advocated blending the two approaches together as necessary to fit a given situation are in that category; however, that indicates a fundamental misunderstanding.

Learning to blend Agile principles and practices in the right proportions with traditional project management principles and practices to fit a given situation can be a difficult thing to do and it’s not just a matter of picking-and-choosing different “tools from different toolkits” and blindly mixing them together – it takes a lot more skill than that. It is more a matter of developing the right mindset to rise above the level of seeing different approaches as a collection of mechanical practices and seeing the principles behind the approaches at a deeper level as complementary rather than competitive. An additional obstacle is that there are many stereotypes and misconceptions on both sides of the fence that you have to get past to develop an objective point of view in order to see this in that kind of perspective.

In my book. I use the analogy of a project manager as a “cook” versus a “chef” (Bob Wysocki who originally created that analogy but I’ve used it a number of times). A “cook” knows how to prepare a limited number of recipes and does it “by the book” without much improvisation. A “chef” knows how to prepare a much broader range of recipes with more exotic ingredients and also knows how to prepare his or her own unique recipes to fit a given situation. I think that analogy fits this situation very well – in order to learn how to blend Agile and traditional plan-driven principles and practices, we need more people who are “chef’s” rather than “cook’s”. Being a good cook is not a matter of randomly picking out spices from different spice racks and mixing them together – it takes a lot more skill than that and learning how to blend Agile and traditional plan-driven principles and practices is the same way.

I’ve developed a free online training course called “Learn the Truth About Agile versus Waterfall” that is only 30 minutes long that is designed to help people see “Agile” and “Waterfall” in a fresh, new perspective as complementary to each other rather than competitive – you can check it out here:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/

Agile Contracts

A lot of people may think that it is inconsistent to impose constraints that the project needs to be completed within a certain expected cost and schedule on an Agile project. It is difficult, but it definitely can be done – one of the areas where that becomes essential is Agile contracts. For example, I once managed a large federal government project that had all the typical government contracting requirements for cost and schedule milestones; but, at the same time, the government customer wanted some level of flexibility to work out detailed requirements as the project progresses.

Does that sound inconsistent? It might be depending on the relationship you have with the customer. Obviously, this will only work if there is a spirit of trust and partnership with the customer to collaboratively agree to work out any tradeoffs between the scope of the requirements and the cost and schedule of the contract as it progresses. If there is more of a typical “arms-length” contracting relationship or some kind of adversarial relationship, it’s not going to work at all.

Doing this requires a hybrid Agile approach that blends an Agile development approach with a plan-driven “shell”. The plan-driven shell provides some level of predictability and control over the overall scope, cost, and schedule of the project while the Agile development approach operates within that shell to provide some level of flexibility and adaptivity in the detailed requirements. That approach is described in more detail in my article on the “Managed Agile Development Framework“.

Jeff Sutherland has created a very nice model for this called “Money for Nothing, Change for Free”. Jeff’s approach is based on two primary clauses in an Agile contract:

  • “Change for Free”

    The “Change for Free” clause is based on the idea that the customer can make any change they want provided that the total contract work is not changed. This allows new features to be added provided that lower priority items are removed from the project. I have documented a case study in my book on how General Dynamics, UK successfully used this approach on a large government contract in the UK.

  • “Money for Nothing”

    The “Money for Nothing” clause is interesting. It recognizes the fact that in many projects, the customer always asks for everything that they could possibly need but if you prioritize those items and deliver the highest priority items first, at some point you will reach a point of diminishing returns where the cost of developing incremental features exceeds the value that those features provide. This clause allows the customer to cancel the contract at that point and save 80% of the cost that would have been spent to complete the remaining items; however the contractor receives a fee of 20% of the cost for early cancellation which makes it a win/win for both the customer and the supplier.

This concept is not limited to fixed-price contracts – that’s only the extreme case. It can be applied to almost any Agile project where there is a need for some level of predictability and control over the costs and schedule of the project. Very few people get a “blank check” to do an Agile project without any expectations of what will be delivered and what the estimated cost and schedule of the project are likely to be.

An Agile Approach to Risk Management

I recently participated in a LinkedIn discussion on risk management that was heavily focused on a conventional approach to risk management built around a plan-driven approach to project management. I wanted to share my thoughts on how I think we need to take a broader view of risk management that would be appropriate for an Agile project environment as well as a traditional plan-driven project management environment.

First, let me preface this post by saying that I’m not an “Agile zealot”. If you’ve read any of my other posts or books or taken my training courses, I’m sure you recognize that I think that there is a widely-held misconception that:

  • “Agile” and “Waterfall” are polar opposites of each other, and
  • There is a binary and mutually-exclusive choice between the two approaches

I think we need to broaden our view of project management to see “Agile” and what is commonly called “Waterfall” as complementary to each other rather than competitive and recognize that traditional plan-driven project management is not the only approach to project management. I prefer to think of a continuous range of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme that looks something like this:

Agility Range

And, the right thing to do is to fit the approach to the project rather than force-fitting a project to some arbitrary model (whatever it might be – Agile or plan-driven). One of the biggest characteristics that would influence the choice of an approach is the level of uncertainty in the project.

If you think of a broader approach to project management in those terms, it has a big impact on how you might do risk management. Here’s how I see some of the key differences in a risk management approach that might be associated with a more adaptive approach to project management in a very uncertain environment:

Why is Risk Management Different in an Agile or More Adaptive Environment?

  1. Definition of “Failure” – Risk is associated with the failure of a project, so how you define “failure” has a big impact on how you do risk management.
    • In a traditional plan-driven project, the requirements of the project are typically well-defined and a “failure” would normally be associated with failing to deliver those requirements within the required cost and schedule budgets allocated for the project. In that kind of environment, it wouldn’t normally be considered a failure if the project met the requirements it was supposed to meet within the cost and schedule goals but failed to deliver the appropriate business value.
    • That approach works fine in an environment where it is possible to relatively accurately define the requirements of the project before the project starts and three is a reasonable level of certainty that if you meet the defined requirements, the project will automatically produce the appropriate business value that is required.

    • An Agile or more adaptive approach is best in situations where it is much more difficult to define detailed requirements for the project prior to the start of the project and there is far less certainty of what is required to produce the appropriate business value. In that kind of environment, there is a much larger risk that the project won’t produce the required business value even if it does meet the defined requirements within budgeted cost and schedule goals. That’s a very important difference between an Agile (or adaptive) approach and a more traditional plan-driven approach.
  2. Relationship to Upfront Planning – Since an Agile approach normally has a lot less upfront planning, it typically requires a more dynamic approach for identifying and managing some of the risks while the project is in progress rather than a comprehensive approach to identify and anticipate risks before the project starts.

    Note that this is not an all-or-nothing choice between zero upfront planning and highly detailed and rigid upfront planning – the approach to planning could be anywhere between those extremes and the approach to risk management should be consistent with the level of planning.

    The important point is that it just isn’t practical to take a comprehensive approach to identify and anticipate all risks in a project with a very limited amount of upfront planning.

  3. The Relationship to Business Value – The risk of not producing the appropriate business value in a very uncertain environment is a very different kind of risk and requires a different kind of risk management approach. That kind of risk isn’t necessarily totally black-and-white – you could produce a relatively mediocre product that met the letter of the requirements but really didn’t provide much business value.

    A conventional approach to risk management is generally based on avoiding and eliminating risks and uncertainty as much as possible so that the project will deliver predictable results, but that approach can work against you if you have a goal of maximizing business value. (See my previous article on Management of Uncertainty in Agile Projects).

    In many cases, risk is associated with opportunities to provide a higher level of business value. With a conventional approach to risk management, you might try to reduce the level of uncertainty and ambiguity associated with user requirements as much as possible prior to the start of the project and you might also tend to favor a low risk approach of using tried-and-true technology rather than “pushing the envelope” a bit to use riskier technology that might provide a higher level of value to the user. From a conventional risk management perspective, that may be the right thing to do but it could easily result in a very mediocre product that doesn’t provide much business value.

How is the Approach to Risk Management Likely to be Different in an Agile environment?

Some people might think that risk management isn’t appropriate in an Agile environment – I don’t believe that to be the case. You can do as much or as little risk management as needed depending on the nature of the project – it just requires a different approach to risk management.

  1. It needs to recognize a broader definition of “failure” – a project can fail by failing to deliver business value even if it meets defined requirements and meets its cost and schedule goals
  2. The approach to risk management needs to be consistent with the overall level of upfront planning in the project – that might mean a less comprehensive identification and analysis of risks prior to the start of the project and a more dynamic approach to risk management as the project is in progress.
  3. Instead of seeing all risks as a bad thing that should be avoided and eliminated, we need to recognize that some risks are related to opportunities. For that reason, a decision to avoid or eliminate risks needs to consider the impact of potential missed opportunities as well as the impact of the risk.

Advantages of an Agile or Adaptive Risk Management Approach

In fact, an Agile or adaptive approach can have a lot of advantages for developing a very effective risk management approach. Steve Gordon commented that Agile or adaptive thinking provides the ability to structure a project to fail early and inexpensively to minimize the impact of a risk on the overall project. Wayne Mack also suggested several more specific risk management advantages that an Agile or adaptive approach can provide:

  • “Technical risks are addressed through early prototypes (“spike stories”) and side-by-side comparison of alternatives (‘A/B testing’)”
  • “Integration risk is mitigated through early and continuous integration. User acceptance risk is mitigated through early product review”
  • “Cost and schedule risk is mitigated through incremental releases – we always have something to show for the money spent; it is no longer an all or nothing trade-off”

Why Should a Project Manager Care About Agile?

Many people in the project management profession seem to be in “denial” about the impact of Agile. Many seem to think it is something that they can ignore that has no impact on the project management profession. There are a number of potential reasons why project managers might believe that Agile doesn’t have any impact on them and that the project management will continue to be limited to traditional plan-driven approaches that haven’t changed significantly since the 1950’s and 1960’s:

  • There is a big misconception that “Agile” and “Waterfall” are binary and mutually-exclusive choices which might lead a project manager to believe that he/she can concentrate on “Waterfall” projects and ignore Agile.
  • Agile and traditional plan-driven project management are treated as separate and independent domains of knowledge with little or no integration between the two and it can be quite challenging for anyone to try to figure out how to blend the two approaches together in the right proportions to fit a given project
  • The role of a project manager at the team level in an Agile project is completely undefined and it would be a big risk for anyone to move their career in that direction for that reason. The path of least resistance is to continue to focus on traditional, plan-driven project management and ignore Agile for as long as possible.
  • There may also be an opinion that “Agile” is just a passing fad and will go away and/or the people who do Agile or just a bunch of “cowboys” and it really isn’t a legitimate form of project management at all.

Here’s my perspective:

  • There are many myths, stereotypes, and misconceptions about both traditional project management and Agile that have caused a lot of polarization between these two communities. I’ve developed a free online training course that is designed to help project managers get past some of these misconceptions and see Agile and traditional plan-driven project management in a fresh new light as complementary to each other rather than competitive. Check it out here:

    “Learn the Truth About Agile versus Waterfall”

  • Agile is precipitating a major transformation of the project management profession that will cause us to rethink many things we have taken for granted about project management for a long time. Anyone who ignores this trend risks becoming a “dinosaur”. I believe that in the not-too-distant future, a project manager who only knows how to do traditional, plan-driven project management will be like a carpenter who only knows how to use a hammer.
  • Even if you’re never involved in a real Agile project, learning the Agile principles and practices will broaden your thinking, expand the number of “tools” in your toolkit, and make you a better project manager.

I saw a similar transformation when I worked in the Quality Management profession in the 1990’s and early 2000’s. At that time, the Quality Management profession was shifting from an emphasis on quality control and inspection where someone with the title of “Quality Manager” was responsible for quality and played the role of enforcing quality standards. We learned that a much more effective approach was to engage everyone in feeling responsibility for the quality of products and services and integrating a proactive focus on building quality into the process rather than inspecting for quality at the end of the process.

That was a gut-wrenching change for many people in the Quality Management profession and I can remember that there were a lot of people who were out of work at that time who were slow to recognize and adapt to that transformation. The similarities to the Project Management profession are obvious to me and I hope I can help project managers see the need to recognize and adapt to this transformation. Check out my blog post on “The Future of Project Management” for more on this.

Making Agile Work for Your Business

Background

There is widespread knowledge that exists about almost every possible aspect of how to optimize an Agile development process at a team level; however, the knowledge about how to make Agile work at an enterprise level is much more limited. There have been numerous failures in trying to make Agile work at an enterprise level and I believe that there are some significant misconceptions behind these failures:

  • Agile versus Waterfall – At the project management level, there is a big misconception that there is a binary and mutually-exclusive choice between an Agile approach and a traditional plan-driven project management approach (or what people many times refer to loosely as “Waterfall”). The result of this misconception is that people often try to force-fit projects to one of those extremes when a much better solution is to fit the approach to the project and sometimes a hybrid of the two approaches is the best fit. (See my online training course “Learning the Truth About Agile versus Waterfall” for more on that)
  • Aligning Agile With a Business Strategy – Another big misconception is that whatever is good for the development process must be good for the company as a whole and that is also not necessarily the case. At the business management level, the approach should be designed around what makes the most sense for the company’s business and that may or may not be exactly the same as the approach used to manage projects at the development level. The people designing the enterprise-level strategy need to be able to understand the business strategy as well as the development strategy and fit the two together. It isn’t necessarily just a matter of forcing the entire company to become more agile.
    • An Agile development process is easiest to apply in companies whose primary business is developing software products (Such as Intuit QuickBooks and TurboTax) or companies where software development has a very direct and significant leverage effect on the company’s business (Such as Amazon.com). In those companies, there is a fairly direct alignment between a company’s overall business management goals and an Agile development process.
    • In companies where that is not the case, the alignment may be less direct. For example, it may or may not be totally realistic for a company to adopt a complete, top-to-bottom Agile approach for their entire business and a more traditional, plan-driven approach may be appropriate at the higher levels (at least as an interim solution). However, that doesn’t preclude implementing a totally Agile or hybrid Agile development process. The Managed Agile Development process is an example of a hybrid Agile approach that can be used in that kind of environment.
  • Enterprise-level Agile Transformation Strategies

    There are a number of different potential strategies at an organizational level for implementing an Agile transformation:

    • Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business – Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model. However, that can be a very ambitious and gut-wrenching change for many organizations and it also may not be the best solution.
    • Fortunately, there are other alternatives companies can select to fit an Agile approach with their business

    Organizations typically have different layers of management as shown in the diagram below; and, at each level, there is a choice of taking more of an Agile approach or more of a traditional, plan-driven approach:

    Enterprise Agile 3

    Overall Summary

    The important thing to recognize is that this is not a “one size fits all” decision. What is the right approach for one company may not be the best approach for another. It’s kind of like a chess game to choose the fit the right strategy to each level of the organization as shown in the diagram below:

    Enterprise Agile 2

    It should be apparent that making Agile work at an enterprise level isn’t necessarily as simple as it might seem and requires a broad understanding of both the business strategy and the development strategy to fit the two together. For more information on this subject, see:

Do You Have Excessive Fear of Failure?

I participated in a discussion on LinkedIn this morning that stimulated my thinking. The individual who started the discussion asked the question, “If a pilot project is discontinued because it didn’t achieve results it had hoped for, would that be considered project failure?” The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:

  • In an Agile environment, a “failure” is regarded in a positive sense as an opportunity for learning and there’s a very popular mantra of “fail early, fail often”. In other words, sometimes you just have to try something and see what works and take a risk rather than being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started.
  • In a traditional, plan-driven environment, the attitude towards failure is many times very different. Any significant unexpected event might be regarded as a failure and many times is regarded negatively. There is an inference that it’s a failure in planning that you didn’t do enough upfront planning to anticipate the problem and avoid it.

I don’t think either of these two approaches is necessarily right or wrong. Like many things, it depends on the situation. There are some situations that call for a more risk-averse approach and some that don’t:

  • Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment. If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business and that would be a failure in itself to not do anything to “push the envelope”.
    Another saying I like is “If you’ve never failed, you’re not trying hard enough”. Amazon.com is probably a good example of a company that has a lot of failures like their smartphone, yet they continue to push the envelope to explore very risky new technology such as package delivery with drones because I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position
  • In other environments, the consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated. Sending an astronaut to the moon might be an example. Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that
  • There’s also a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be. Any project that involves a large amount of uncertainty might be an example. You need to figure out how much of that uncertainty you can tolerate and let it be resolved as the project progresses and how much of it you can’t tolerate and need to resolve upfront before the project starts.
    It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks; but, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started trying to anticipate and mitigate every possible risk that could possibly happen.

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about what the goals of the project are, what level of risk is acceptable in the project, and how those risks will be managed.

  • In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency and the Business Sponsor (represented by the Product Owner) is expected to have a sufficient level of judgment and maturity to make good, sound decisions on the project. Because there is an understanding that some of the risks and uncertainties will be resolved while the project progresses, the Business Sponsor (represented by the Product Owner) is also intimately involved as the project progresses to provide ongoing direction
  • In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team. The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all. That can lead to a fear of failure and a “CYA” approach by the project team to over-analyze the project to avoid any possible problems and it can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors.

It seems to me that the partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is a lot more sensible and has numerous advantages.

Multi-Dimensional Project Management

I recently wrote a post on “Adaptive versus Plan-driven Project Management”. It occurred to me that this same framework would be useful to help people understand the migration that I believe is happening in the project management profession. Here’s how I see the migration of project management roles that is likely to take place in the future:

Project Management Migration

I don’t think that anyone today would disagree that “Project Management”, as we’ve known it, is heavily defined by plan-driven principles and practices as shown by the oval in the left-hand column of this diagram and there are many stereotypes that heavily associate “Project Management” with plan-driven practices. What I believe is likely to happen within the project management profession in the future is this:

  • At a team level, a large percentage of project management roles are likely to migrate towards a more adaptive approach over some period of time. That means that many of those project management roles might disappear and project managers who are only qualified to do plan-driven project management at a team level may have to move in one of two different directions:
    • Move up to assume a higher-level enterprise-level role managing larger, more complex projects
    • Develop more adaptive project management skills
  • Project Managers who are already managing larger, more complex projects and enterprise-level projects may be less impacted by this migration; however, even at that level, the demand for project managers who only know how to do plan-driven project management will likely decline significantly.
    • Some of these new roles may not even be recognizable as we know project management today and may not even have the title of “Project Manager” associated with them. For that reason, I think we need to shift our thinking about what “Project Management” is. Instead of thinking of it as a narrow vertical column that is dominated by plan-driven thinking, what I believe is needed is more of a broader, multi-dimensional view of project management that goes beyond just doing traditional, plan-driven project management functions and also embraces a more adaptive approach to project management.

      In my opinion, project managers of the future will need to take on a broader range of roles and must be able to operate in either a plan-driven role or a more adaptive project management role and should be able to select the appropriate blend of those two approaches to fit a given situation rather than force-fitting all projects to a plan-driven approach.

      It seems to me that the Project Management profession needs an image makeover to shift the image of how people think of what “Project Management” is to prepare people for this migration that I believe is likely to happen. I think that there are a lot of people in the project management profession who are in “denial” and seem to think that the way we’ve been doing project management will go on unchanged into the future. I hope this post has helped people more clearly see this migration trend.

      (See my blog post on “Reinventing Project Management” for more on this.)

Learn the Truth About “Agile” versus “Waterfall”

Background

How many times have you heard people compare “Agile versus Waterfall”? It happens a lot, I do it myself, and I keep hearing presentations that talk about how Agile has displaced “Waterfall”. But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date – true “Waterfall”, as a methodology, died a long time ago for most projects outside of some specialized areas like construction yet people continue to make that comparison.

The problem is that the word “Waterfall” is used very loosely and indiscriminately. In many cases, when people use the word “Waterfall”, they’re not using it to refer to the specific “Waterfall” methodology that was originally defined by Winston Royce in the 1970’s, they’re using it loosely to refer to a general style of project management that obsessively emphasizes predictability and control over agility.

The word “Waterfall” actually has some fairly specific connotations. For example, a true “Waterfall” project is broken up into phases based on functional activities (design, develop, test, etc.) that typically happen sequentially with phase gates that control the progression from one phase to the next. I think the usage of that methodology for software development today is practically zero, yet people continue to compare Agile to “Waterfall”.

Some Examples of Sloppy Terminology

Don’t get me wrong – I think Agile has huge benefits. I just want people to objectively understand the benefits of Agile versus Waterfall and the sloppy use of terminology to compare the two is often misleading and confusing. Here are a couple of examples I’ve taken from some real world sources to illustrate what I mean by sloppy use of technology when people talk about “Waterfall”:

Blue Line

From the 2011 Chaos Report: “Agile Succeeds three times more often than Waterfall”
The report goes so far as to say, “The agile process is the universal remedy for software development project failure.”

What do they mean by “Waterfall”? (Are they talking about a specific methodology – like the Waterfall that was defined by Winston Royce in the 1970’s or are they talking about a broader range of plan-driven methodologies?)

Blue Line

From an invitation to attend a local Agile group presentation: “It would be so easy if everyone at our companies just used Scrum — or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it — an all-Agile organization isn’t always possible. Maybe you have a Project Management Office (PMO). Maybe you work for a government contractor. Maybe you have regulatory requirements. Maybe you’re the first Scrum/Agile project at your company. Maybe your company simply *likes* it this way. Whatever the reason, Agile teams frequently report into Waterfall organizations.”

What do they mean by a “Waterfall organization”?

Blue Line

When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and even Winston Royce himself had reservations about it
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of attempting to complete all of the project requirements all at once? Long before Agile became well-known, iterative approaches like the Rational Unified Process (RUP) provided a way to solve that problem and break up a project into iterations.

A More Meaningful Comparison

A more meaningful and more objective comparison is between an “adaptive” approach to project management and a “plan-driven” approach to project management. “Plan-driven project management” is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent prior to implementing the project. In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and the requirements and plan for the project are expected to evolve as the project progresses.

No project is ever totally plan-driven or totally adaptive; you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all, and you won’t find many projects that have no plan whatsoever of how the project will be done. There is a broad range of alternative approaches between those two extremes as shown in the diagram below:

Agility Range

It is a matter of choosing the right level of upfront planning to be applied to a project based on the level of uncertainty and other factors in the project and it takes some skill to do that.

There is nothing inherently wrong with either of these approaches (adaptive or plan-driven). They both have advantages and disadvantages for a given project and they should be seen more as complementary approaches rather than competitive. Instead, many people see “Agile” and “Waterfall” as binary and mutually-exclusive choices and that causes people to try to force-fit a project to one of those extremes rather than selecting and tailoring the approach to fit the project. For example,

  • If I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be very dismal
  • Similarly, if I tried to use an agile approach for building a bridge across a river, the results would be equally dismal

Why does that happen? It takes much more skill to fit a methodology (or combination of methodologies) to a project – you have to know a broader range of methodologies and you have to understand the principles behind the methodologies at a deeper level to know how to tailor the methodology and blend different methodologies together to fit a given situation. Some people are primarily skilled in one particular methodology and tend to implement that methodology mechanically “by the book”. It’s like being a carpenter and the only tool in your tool bag is a hammer.

Overall Summary

The impact of misusing the word “Waterfall” is significant:

  • It causes people to “throw out the baby with the bath water”. By misusing the word “Waterfall” and categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and to regard any kind of upfront planning as inconsistent with an Agile project.
  • It has caused a lot of polarization between the traditional project management community and the agile community. The perception is that project managers are associated with the Waterfall approach and, as a result, project management skills are not needed because the Waterfall approach is an out-of-date approach for many projects.

The true Waterfall approach has been obsolete for many projects for a long time (the exception being some selected industries like construction where it is still very useful and relevant). Even prior to Agile, many people were widely using iterative approaches like RUP for software development in place of Waterfall. So, I don’t think comparing Agile to Waterfall is very meaningful any more, but its very difficult to get people to stop thinking in those terms because it has been so prevalent for such a long time.

The difference between a highly adaptive project and a highly plan-driven project is how much of that planning is done upfront in the project rather than being deferred till later. It’s not a black-and-white decision to have a totally plan-driven approach or a totally adaptive approach and it requires some skill and judgment to determine what level of upfront planning makes sense in a given project. When people present this decision as “Agile versus Waterfall” it distorts what the real decision is and makes it look like a binary, all-or-nothing choice and that’s not the case.

Additional Resources

I’ve created a new online training course on Udemy that provides more information on this topic:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/#/

This new course on Udemy is free.

Learning the Truth About “Agile” versus “Waterfall”

When I originally created this post, it drew almost 200 hits in the first day which is an indicator of how important this topic is! In response to that level of interest, I’ve expanded the original video I posted below on YouTube and turned it into a 30 minute Udemy course. The new Udemy course is at the following location:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/#/

This new course on Udemy is free. The original 10 minute video is still available on YouTube at the link shown at the end of this article. Here’s a summary of both the training course and the shorter video…

Many businesses and project managers are faced with a choice of choosing a traditional plan-driven approach (or what is sometimes called “Waterfall”) or a more Agile approach for critical projects which can be a very important decision with significant business impact but there are many misconceptions about “Agile versus Waterfall” that can be very misleading.

One of the big misconceptions is that “Agile” and “Waterfall” are often thought of as binary and mutually-exclusive alternatives. The result of that misconception is that businesses sometimes force-fit their business and projects to one of those extremes when the right solution is to go in the other direction and fit the approach to the project. Sometimes projects require a blend of both approaches – it takes more skill to do that, but it definitely can be done.

Since this is such a critical decision that has such a big impact, I think it’s very important to have a clear understanding of what we mean when we talk about “Agile versus Waterfall”. In this video, I want to try to help you see these two approaches in a fresh new perspective to get the best of both of these two worlds. You can view the video here (it is about 10 minutes long):

http://youtu.be/pp8-jFpa-G4

What is an Enterprise-level Agile Coach?

When people use the term “Agile Coach” it is often not exactly clear what they mean. Most often, what they’re talking about is what I would call a team-level Agile Coach. That is someone who works at a tactical level with individual members of an Agile team to help them become more proficient in executing an Agile development process such as Scrum. There is very little standardization or certification for what it takes to become an “Agile Coach” at that level and almost anyone could claim to be an “Agile Coach”.

Beyond that; however, there is a different kind of Agile coaching role at an enterprise-level that needs to be better-defined and differentiated from a normal team-level “Agile Coach” role. The enterprise-level role is someone who works at a more strategic level to integrate an Agile development process with a company’s business. That role is not well-defined at all and the difference between the team-level role and the enterprise-level role is also not clearly differentiated. It is assumed that someone who has “Agile Coach” on his/her resume can do all of that and I don’t believe that is necessarily correct.

What often happens in applying Agile at an enterprise level is that an “Agile Coach” attempts to plan and organize an enterprise-level agile transformation. However, that person is probably only trained in Agile from a team-level development process perspective and makes the assumption that whatever is good for the development process must be good for the business as a whole. They also may assume that it is a binary and mutually-exclusive decision to be either “Agile” or “Waterfall” and attempt to force-fit the entire company into an Agile model when the right solution is to fit the approach to the company’s business. I don’t believe that either of those assumptions is necessarily correct.

The problem is this – Agile works very well in companies that are in the primary business of developing products (particularly software products – Intuit is an example that develops TurboTax, Quicken, and QuickBooks). In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company and it is very easy to apply an Agile development process in that environment. It is much more difficult to apply an Agile development process in a company who is not in the primary business of developing products and is in some other kind of business where the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products, you can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process. The company’s overall culture and business strategy needs to be optimized around whatever the critical success factors are for the business that they are in. For example, if a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and that doesn’t necessarily align with just becoming more “Agile”. In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach. The implementation of that strategy often requires fitting the approach to the company’s business environment rather than trying to force-fit the company to some kind of overall Agile approach.

The approach that you might wind up with in that kind of environment also could be a blend of Agile and traditional plan-driven management principles and practices blended together in the right proportions to fit the situation. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices as well as
  • Traditional project management principles and practices

and a deeper understanding of the principles behind both of them (not just the mechanics) to know how to blend them together as necessary to fit a given situation. Beyond that; however, it also requires the ability to look at a very complex, broad-based, enterprise-level business from both a more strategic high-level business management perspective as well as a more tactical product development process perspective to develop a strategy for integrating the two.

What often seems to happen is someone who is trained in “Agile” from a development process perspective attempts to steer the company in the right direction and that person typically doesn’t have the breadth of business management experience and agile development process experience to know how to successfully integrate the two. Is it any wonder why some of these “Agile transformations” are not successful?

I’ve developed some on-line training that should be helpful to people who want to understand this better:

  • Agile Project Management Overview for Project Managers – addresses this from a project management perspective to help project managers see Agile and traditional project management principles and practices as complementary rather than competitive and to learn how to blend the two together to fit any given situation.
  • Agile Project Management Overview for Executives – addresses this from a business management perspective and provides some essential principles and guidelines of how to successfully develop a well-integrated enterprise-level approach for any business.