Is the Idea of a PMO Obsolete?

I think the traditional notion of a PMO is becoming obsolete rapidly in many industries; however, that doesn’t mean that the idea of a PMO is no longer needed at all. A PMO can play a value-added role but it is a somewhat different role than what a PMO may have played in the past. It’s a difference in emphasis between providing control versus producing value. The traditional emphasis of a PMO has been primarily on providing control of spending to ensure that individual projects were well-managed from a fiscal responsibility perspective and that the overall portfolio of projects produced an acceptable return.

What’s wrong with that picture? We’ve learned that many projects may seem to be successful from a financial perspective yet fail to deliver business value. Business value is a much more elusive target that is much more difficult to measure. So what is the answer? It’s a significant shift in emphasis for a PMO to put more focus on producing value versus providing control; however, that’s not an all-or-nothing proposition. Many people tend to see things in black-and-white, binary terms – either you’re focused on value or you’re focused on control and there’s no middle ground. I don’t believe that to be the case.

It takes a lot more skill to find that middle ground” but it definitely can be done. It requires seeing “control” in a different perspective – it’s a more dynamic kind of control. There’s a lot of similarities to the difference between traditional plan-driven project management and a more dynamic form of Agile Project Management at the project level.

  • Instead of having very well-defined plans at the project portfolio level that aren’t expected to change at all, plans are much more broadly defined and are expected to change and become further defined over time
  • It also requires a partnership with the business and much more active participation in the development and implementation of the project portfolio strategy by the business

What needs to happen at the project portfolio level is very similar to what needs to happen at the project level; it’s just at a higher level. There is a direct parallel between the role of a modern, PMO and the role of an Agile Project Manager. Both need to play much more of a facilitation role and add value based on a much more dynamic style of management rather than a controlling role. They both need to put in place the right people, process, and tools to execute the strategy and intervene only as needed. For more on this, check out my article:

What is an Agile PMO?”

Also check out this online training course:

Making Agile Work for Your Business

Modifying and Extending Agile/Scrum

I recently participated in a discussion on LinkedIn that was initiated by someone who suggested several possible roles for a Business Analyst in Agile/Scrum that didn’t seem consistent with Agile principles at all. I believe that Agile/Scrum can and should be modified and extended as necessary to fit the situation, but it has to be done intelligently and I think it takes some skill to figure out what makes sense and what doesn’t.

We all know that there are Agile “zealots” who insist on rigid adherence to doing Agile/Scrum “by the book” without any deviation. On the other hand, there are people who “wing it” and treat Agile/Scrum practices like a “cafeteria menu” where you can pick and choose the principles and practices you want to adopt and which ones to ignore. Neither one of those approaches makes sense in my opinion but there’s a lot of “gray area” between those extremes. So, how do you determine what makes sense and what doesn’t make sense? I don’t think there’s a clear answer to that question but here’s some guidelines that I think are useful.

  • There’s a big difference between:
    1. Taking a proven framework like Scrum and modifying it and extending it in a way that is consistent with Agile principles and practices, and
    2. Just starting from scratch ignoring Scrum and all other Agile methodologies, principles, and practices and attempting to put together some kind of ad-hoc approach
  • There’s an analogy to the martial arts that I think fits pretty well. There are a variety of different kinds of martial arts but they all have some similarity and they all require some level of knowledge, proficiency, and discipline in how they’re practiced to be good at it. You don’t just go out and start doing martial arts without any training and experience to know how to do it. Check out this article I wrote on “Stages of Mastery in Agile”.

    http://managedagile.com/2014/06/13/levels-of-mastery-in-agile/

    It is based on a model of stages of maturity in martial arts called “Shu-ha-ri”:

    http://managedagile.com/2013/07/17/agile-and-lesssons-learned-from-martial-arts/

    The essence of the “Shu-ha-ri” martial arts philosophy is that you should be at a level of proficiency before you start improvising and “improvisation without knowledge and proficiency is just amateurism”. I think that is also very applicable to Agile. It takes a considerable amount of skill to figure out how to modify and extend Scrum and other Agile methodologies to fit a given situation.

The key message is that people shouldn’t underestimate the level of skill it takes to modify and extend an Agile/Scrum approach to fit a given situation. That’s a key advantage of some predefined frameworks like SAFe but, on the other hand, even with some of the predefined frameworks, it takes some skill to adapt an Agile approach to fit a business and there is no “silver bullet”.

Business Process Reengineering and Agile

I recently wrote an article on a “Business-centric Approach to Agile“. Have you ever thought about how similar an enterprise-level Agile transformation is to “Business Process Reengineering (BPR)”? The similarities are amazing but I suspect that many people don’t think of any relationship between BPR and Agile.

Business Process Reengineering (BPR) was very hot in the 1990’s. One of the catalysts that precipitated the need for BPR was the advent of new Enterprise Resource Planning (ERP) systems. ERP systems enabled many companies to much more completely automate their business processes but it was a gut-wrenching change for many companies because implementing an ERP system in many cases required rethinking their business processes to take a much more cross-functional approach to their business. Another important catalyst was “lean manufacturing” which seeks to eliminate the use of any resource that does not create value for the end consumer. Does that sound like an Agile enterprise-level transformation?

Here’s how Bain and Company defines “Business Process Reengineering”:

“Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality. In Business Process Reengineering, companies start with a blank sheet of paper and rethink existing processes to deliver more value to the customer. They typically adopt a new value system that places increased emphasis on customer needs. Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”

Source: Bain & Company: Insights – Management Tools, Business Process Reengineering

Let’s take this definition one step at a time:

  • The first statement is “Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality” – there’s no question in my mind that that statement could apply to an Agile transformation, but do companies really realize that and do it that way?
  • The next statement is “In Business Process Reengineering, companies start with a blank sheet of paper and rethink existing processes to deliver more value to the customer.” There’s also a good fit with that statement. You may not start with a “blank sheet of paper” and throw out all your existing management processes, but it is definitely important to rethink many existing stereotypes and misconceptions that exist about both Agile and traditional management approaches before you launch into an Agile transformation.
  • The statement that “They typically adopt a new value system that places increased emphasis on customer needs” is very relevant to an Agile transformation but is probably not given the attention that it deserves. When a company implements an Agile transformation, it is often done from a limited development perspective focused on how it improves the development process but that needs to be done in a larger context of how it improves the customer value that the company delivers to its customers.
  • The last statement is absolutely very relevant to an Agile transformation: “Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”

I’m not defending BPR, there were definitely some problems in the way it was implemented, but there’s a lot we can learn from it (both good and bad). If more companies realized how similar to Business Process Reengineering is to an Agile transformation and treated it that way, the probability of success would probably be significantly higher. It expands your thinking to see an Agile transformation in an overall business context rather than a very limited development-centric perspective.

I’ve developed a new online training course called “Making Agile Work for Your Business” that is designed to help companies see this perspective and to take a business-centric approach to successfully integrate an Agile development approach into their business.

What’s Next After PMI-ACP®?

I recently participated in a forum on PMI-ACP® when someone asked “What’s next after PMI-ACP®?”. I thought it was an interesting discussion and is worth elaborating on further. I believe that the individual who asked the question was wondering what new certifications PMI is going to come out with for people who have a PMI-ACP certificattion and are interested in continuing to advance their knowledge and career in that direction.

It’s a perfectly understandable question but, unfortunately, the answer may not be what you might want to hear. It raises a much larger question of what’s an “Agile Project Manager”? and what’s the career path for someone who has a project management background and is interested in developing into an Agile Project Management role? Many project managers have been thinking that PMI-ACP® would open up a new career path into Agile and it’s just a matter of getting another certification to move further, but I don’t believe that to be the case for a couple of reasons:

  • The role of an “Agile Project Manager” is not well-defined and is also somewhat controversial at this point in time. it’s very difficult to certify someone to have those skills when they are not well defined and contentious.
  • The PMI-ACP® certification tests general knowledge about Agile and Lean and is not designed around a specific role like the CSM (Certified Scrum Master) certification is.
  • Agile is much more heavily based on “tacit” knowledge versus “explicit” knowledge. It requires a lot more judgment and it’s not something that you can easily codify in a document like PMBOK that you can test and certify people against. For that reason, even if the idea of an “Agile Project Manager” was more well-understood, it still might be very difficult to develop a certification exam to test that someone really has the skills to fill that role.

The PMI-ACP certification is a great step in the right direction by PMI to try to close the gap between traditional plan-driven project management and Agile but it just doesn’t go far enough and it also leaves open some very large questions that any project manager who is interested in Agile would naturally want to have answered about what their career path is. Agile is rapidly changing the whole “ball game” for project managers and it’s very understandable that project managers have questions about what their career direction is.

The truth is that any project manager who has a PMI-ACP® certification who wants to further develop into an Agile Project Management role has to be somewhat of a “pioneer” to lead the way for other project managers at this point in time. It can be a difficult transformation, it’s certainly not a matter of just getting another certification, and the ultimate role you wind up in may be very different from a conventional notion of what “project management” is. You have to be a real self-starter to start out on that journey but I think it’s a survival issue for many people in the project management profession to move in that direction.

I am passionate about helping project managers move in this direction and I’ve developed some training courses to help. Check out this video for a summary of the training courses I’ve developed and how I think they help people make this transformation:

What’s Next Beyond PMI-ACP®?

This is a difficult problem but I believe that this is critical to the future of the project management profession and I’m determined to help project managers make this transformation. You can find more detailed information on any of my training courses here:

Agile Project Management Training Course Details

A “Business Centric” Approach to Agile

Many Agile coaching and consulting companies take what I would call a “developer-centric” approach to Agile. It is heavily focused on team-level capabilities and is primarily oriented around improving the development process. There’s nothing wrong with that, in itself; however, people often make the mistake of assuming that whatever is good for the development process must be good for the business as a whole and that is not necessarily the case.

What I’ve seen frequently is that people have the belief that any kind of traditional management approach is bad, Agile is good, and there is a binary and mutually-exclusive choice between “Agile” and what’s commonly called “Waterfall”. That over-simplifies what I believe is a much more complicated decision and the result of that is that people often try to force-fit a company’s business into an Agile approach. The right solution, in my opinion, is to go in the other direction and fit the approach to the company’s business and sometimes that may require blending an Agile approach with a more traditional management approach in the right proportions to fit the company’s business rather than force-fitting the whole company to an Agile approach.

Becoming agile for the sake of becoming agile may not be an appropriate goal for all companies. You have to ask “what problem will it solve?” and “how will it really benefit the company?” and the answer to those questions may be very different depending on the nature of the company’s business. Check out my article on “Where Does it Hurt?” for more on that. Agile works best in companies that are in the business of developing software products like Intuit who develops Quicken, QuickBooks, and TurboTax and other companies where software development has a very direct relationship to their business objectives like an Amazon.com which is very technology-driven.

In those companies, there is a strong and direct alignment between an Agile development process and the company’s business objectives and it is relatively easy to implement an Agile development approach in that environment. In companies that are not in the primary business of developing software products, the relationship between the development process and the company’s business objectives is typically much more indirect and there is less of a natural alignment between an Agile development approach and the company’s business objectives.

The key to developing a more business-centric approach is that you have to recognize that at an enterprise level, the overall approach must be designed to satisfy the critical success factors of the company’s business. A good model to look at to understand this better is the idea of “value disciplines”. Check out my article on “Agile and Corporate Culture” for more on that. For example, if a company like Walmart is in a business that demands “operational excellence” as the primary value discipline, one of the most important critical success factors in their business is going to be reducing costs to be most competitive. How does an Agile development approach contribute to achieving that objective? The answer isn’t necessarily obvious.

What’s needed in this situation in many cases is more of a “top-down” business analysis to identify potential areas for process improvement so that those initiatives are really well-aligned with the critical success factors that are most important to the company’s business. That should be one of the first steps in an Agile transformation for this kind of company. Before you jump to the conclusion that Agile is a good solution to any problem they might have and start working on making them more agile, you have to figure out how its really going to benefit the company and make the company more competitive in the business that they’re in.

It also doesn’t necessarily require throwing out any existing management processes that they may have and making the whole company more Agile. There may be a legitimate reason for some of those management processes that are already aligned with the critical success factors in their business and it may require some compromise to adapt an Agile development approach to that environment. In the 1990’s and early 2000’s, I did a lot of work with companies on large-scale process improvement and business process reengineering initiatives and even though that effort had nothing to do with Agile at the time, the methodology you would use to do a business-centric Agile transformation would be very similar.

This is a great example of what I call the “Program du Jour”. When a new management approach like Agile comes along, we often “throw the baby out with the bath water” and consider anything that came before it as obsolete and passé. I saw a similar thing when Six Sigma was hot in the early 2000’s. Everyone wanted to jump on the Six Sigma bandwagon, there was a lot of hoopla about it (like green belts and black belts, etc.), any other process improvement methodology that came before it was considered out-of-date, and people got lost in the mechanics of Six Sigma without understanding how it really helped their business.

I published my first book at that time in 2003 and did quite a bit of research before writing my book. What I found was that the companies I considered most successful in implementing Six Sigma had so thoroughly integrated it into the way they did business that it might not have been easily identifiable as Six Sigma and they may not have even called it “Six Sigma”. I think a similar thing is needed with Agile today…companies need to go beyond the mechanics of simply implementing “Agile” and figure out how to really integrate it into the way they do business and there isn’t just one canned way to do that. The approach for doing that may be very different depending on the nature of the company’s business.

To do this, requires a broader approach for implementing an enterprise-level Agile transformation that blends a top-down business-centric approach with a bottom-up developer-centric approach in the right proportions. The basic approach for doing that top-down “business-centric” approach to identify areas of process improvement for the business might not be a lot different from what we did 10 years ago for some of the business process improvement initiatives and business process reengineering initiatives I was involved in at that time that had absolutely nothing to do with Agile.

In fact, an Agile transformation is very similar to what you would do in a major business process reengineering effort. Of course, there are many ways to do this top-down business centric analysis depending on the nature of the company’s business and the company’s appetite for making a significant change but this can be a way to keep an Agile transformation well-aligned with the company’s business objectives rather than simply becoming Agile for the sake of becoming Agile.

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:

What is an Agile PMO?

The topic of an “Agile PMO” seems to be getting a lot of attention and there are lots of organizations that have existing PMO organizations that may be wondering what they need to do to move to a more Agile approach so I thought I would share my thoughts on this subject. It’s a controversial topic and some people might even say that the whole idea of a “PMO” is inconsistent with Agile. I don’t believe that is necessarily the case.

The key to understanding this issue is to first understand that there isn’t a binary and mutually exclusive choice between an “Agile approach and what people sometimes refer to as “Waterfall”. For more on that, check out my recent post on “Learning the Truth About Agile versus Waterfall”. It is better to think of this as a range of alternatives between heavily plan-driven at one extreme and heavily adaptive at the other extreme that looks something like this:

Agility Range

And, the right approach is to fit the methodology to your projects and business environment rather than going in the other direction and attempting to force-fit your projects and business to some kind of canned approach whatever it might be (Agile or not). For more on that, check out my online training course on “Making Agile Work for Your Business”.

If you accept the notion that you need to tailor the approach to fit your business, it should be evident that the design of a PMO should be consistent with that approach and there isn’t a single “canned” solution for what an “Agile PMO” is. However, I think that there are some general guidelines that should be useful. A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:

Traditional PMO

The emphasis in this kind of organization is typically on planning and control of projects and this kind of organization would be consistent with a heavily plan-driven approach. But how does that role change as an organization moves towards more of an adaptive approach? I think a more adaptive version of a PMO organization might look something like this:

Modern PMO

The source of the above material is from my book “Making Sense of Agile Project Management” published in 2011 by Wiley.

Here’s what I think some of the key differences are as an organization moves towards more of an adaptive approach:

  • The role of the PMO becomes more of an advisory role and a consultative role rather than a controlling role. The function of the PMO should be to put in place well-trained people coupled with the right process and tools to make the process most effective and efficient and to keep it well-aligned with the company’s business
  • The primary responsibility for providing direction to projects shifts more to the business side represented by the Product Owner in the projects and there is a much more of a closer coupling with the business side to put more emphasis on providing business value rather than simply managing project costs and schedules
  • The role of the functional organizations also changes to providing more of an advisory function as the resources are more committed to project teams and the project teams become more self-organizing

This model can be a very big change for many businesses because it puts a lot more responsibility on the business side of the organization to provide direction to projects and the business organization may not be well-prepared to take on that responsibility. It also relies much more heavily on self-organizing teams. For those reasons and others, a totally adaptive approach may not be the right approach for all businesses and even if it is, it may take time to migrate an existing organization to that kind of approach. Fortunately, there are many ways to develop a hybrid approach to blend a traditional plan-driven approach with a more adaptive approach to fit a given business and project environment. See my “Agile Project Management Workshop for Project Managers” for more on that.

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.

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.

Making Agile Work for Your Business

I have just finished developing a new online training course called “Making Agile Work for Your Business“. Here’s some background…

Anyone who has read any of my previous blog posts knows that I am passionate about closing the gap between Agile and traditional plan-driven project management. To that end, I have created an online course to help project managers see those two approaches in a new light as complementary to each other rather than competitive and to learn how to blend the two approaches together in the right proportions to fit a given situation.

I realize; however, that project managers might have difficulty implementing an Agile Project Management approach unless it is consistent with the strategy of their organization and there are many organizations that are heavily ingrained in a traditional plan-driven project management strategy and scared to death of implementing an agile approach. They see “Agile” and “Waterfall” as binary, mutually-exclusive choices and think that they may have to completely unravel their existing management approach and potentially risk completely losing control of their business to adopt an agile approach and that isn’t necessarily the case.

Rather than force-fitting a business to one of those extremes, a better solution may be to go in the other direction and fit the approach to the business and it might require blending an Agile development approach with more traditional plan-driven project management in the right proportions to fit their business. That requires some skill and planning to do that successfully and the new online training course is designed to address that need.

This new course is designed to help a senior manager develop a plan for designing enterprise-level management approach that blends an Agile and traditional plan-driven management approaches in the right proportions to be well-aligned and well-integrated with their business. The course would also be useful for project managers who play a leadership role in helping businesses develop an overall enterprise-level Agile Project Management strategy.

The course provides the material and tools for a manager to:

  • Evaluate and fine-tune their current business strategy and use an agile project management approach to maximize their focus on customer value and business results
  • Define and prioritize the specific benefits of an agile project management approach that are most important to their business
  • Develop an agile project management implementation plan that is well-aligned and well-integrated with maximizing the effectiveness of their business

Use this link to to register for the course with a 50% discount.