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: