Category Archives: Enterprise-level Agile

What is an Agile PMO?

Background

I recently saw a question on a LinkedIn discussion group asking: What is an Agile PMO? There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and that the whole concept of a PMO is inconsistent with Agile. That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid waterfall-style policies for selecting and managing the execution of projects and programs. In that kind of environment, a PMO might require:

  • Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
  • Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI

There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play.

Understanding the Truth About “Agile versus Waterfall”

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:

Increasing Agility and Adaptivity

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).

What’s the General Role of a PMO in Any Organization?

I believe the general role of any PMO is to align the selection and execution of projects and programs with the organization’s business goals which includes Project/Product Portfolio Management, providing oversight of project execution and the overall interface for management and reporting of projects and programs to senior management and the business, and finally to provide coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management.

Those general functions probably don’t change in an Agile/Lean project environment, but how a PMO performs those functions may change significantly depending on the organization’s overall strategy 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 may also may not be the best solution
  • I think it is a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level and there are many ways to adapt an agile development process to a company who’s overall business may not be totally compatible with an agile approach at the enterprise level.

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.

What Does a Traditional PMO Look Like?

A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:

Traditional PMO Roles

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?

What Does a More Adaptive PMO Model Look Like

I think a more adaptive version of a PMO organization might look something like this:

Agile PMO Roles

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.

Overall Summary

The role of the PMO should be aligned with supporting whatever that overall strategy is. For example,

  • The PMO may still be the focal point for Project/Product Portfolio Management, but a more agile approach might be used to perform that function. Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach, a more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less detailed ROI analysis.
  • In the other functions related to managing the execution of projects, the PMO probably would probably delegate more responsibility to project teams and play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.

In summary,

  • Agile certainly forces some rethinking of the role of a PMO but it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant, and
  • There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level and it isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom. You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach.

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.

Additional Resources

Check out my online training courses for more help on this topic:

Agile Project Management Online Training

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. Learn the Truth About “Agile” versus “Waterfall” – 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 emphasizes some level of planning, predictability, and control over agility. Here’s an example – iterative methodologies such as the Rational Unified Process (RUP) became very popular in the 1990’s and early 2000’s and many people would consider that to be “Waterfall” just because they are somewhat plan-driven, but they don’t really fit the full definition of “Waterfall” at all.

An Example 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 is an example I’ve taken from a real world source that is considered fairly credible 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?

How did they define how “success” was measured?

How can anyone possibly say that “The agile process is the universal remedy for software development project failure”?)

Blue Line

Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”. They both have advantages and disadvantages depending on the environment that you’re in. 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:

Increasing Agility and Adaptivity

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). 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 free online training course that provides more information on this topic:

Learn the Truth About Agile versus Waterfall

What is an Enterprise-level Agile Coach?

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:

  • Mastering Agile Project Management for Project Management – 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.
  • Making Agile Work for Your Business 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.

Agile Transformation: Where Does it Hurt?

Agile transformation: where does it hurt? I’ve seen a lot of people jump into Agile just because it’s the latest and coolest thing to do and there’s a lot of momentum behind it.  It’s like the “Program du jour” for some companies – I can remember a similar phenomenon when Six Sigma was initially coming into vogue in the early 2000’s.  At that time I worked with a number of companies on process improvement projects and I interviewed a number of companies for the first book I published, “From Quality to Business Excellence:

  • I saw many companies that got wrapped up in the rituals and hoopla of Six Sigma (green belts, black belts, etc.) and, in many cases, their implementation was superficial and didn’t last.
  • On the other hand, there were a small number of companies that took the time to understand Six Sigma at a deeper level, blend it together with other process improvement methodologies, and really integrate it into the way they did business. In many cases, it was such an integral part of their business that it was difficult to recognize it as Six Sigma. Naturally, those were the companies I thought were really excellent.

I met with a company recently who is considering adopting a more agile approach to help them determine if it made sense for them and a question I like to ask in that kind of situation is “Where does it hurt?”  In other words, what are the aspects of your current process that are causing some amount of “pain” to the organization that you would like to improve on?

Many people skip that step of defining what problem they want to solve and just jump into Agile and I think it’s important to more clearly define what you want to get out of it.  There are at least a couple of reasons why that is important:

  • Agile is not a panacea for every problem, and
  • Many businesses make the mistake of force-fitting their business to some methodology (Agile or whatever)…the right solution, in my opinion, is to fit the methodology (or combination of methodologies) to the business

An Agile transformation may also not get much momentum in a company if the problem it addresses and the goals to be accomplished aren’t defined.  An Agile transformation typically involves some change management and I learned a long time ago that there are three very important elements for any significant change management effort to be successful:

  1. Burning Platform – There needs to be a “burning platform”…there needs to be a sufficient level of pain with the current situation to motivate people to make a change particularly a difficult change that has some risks associated with it.  Specifically, with regard to an Agile transformation, if you don’t clearly identify what is wrong with the current state, the transformation may not gain too much momentum.
  2. Vision for the Future – There needs to be a vision for the future – what does the end state look like after the change?  With regard to an Agile transformation, how will the overall enterprise-level model change as a result of implementing Agile?  Will it be a pure Agile approach from top-to-bottom or is some other kind of framework more appropriate?
  3. Progress in That Direction – In any significant change, there are always naysayers who will stand on the sidelines and wait for it to fail, but it becomes increasingly difficult to do that if you demonstrate progress and benefits to the organization.  With regard to an Agile transformation, a lot of people advocate “just start” without a lot of upfront planning – I’m not an advocate of that extreme, but there certainly is value in starting to make demonstrable progress as quickly as possible.

I think Agile is entering a new stage of maturity where it is no longer perceived as a fad, a lot of the hype religious zealotry about Agile is fading away, and a more pragmatic approach is emerging focused on doing what’s right for the organization.  A good article I recently read called that “Post-Agilisim”:

http://www.jenrickblog.co.uk/2013/11/post-agilism-world-gary-sage/?utm_medium=email&utm_source=Jenrick+Servcies+Ltd&utm_campaign=3285069_The+Digest+-+Nov+(week+1)+-+RE-SEND&utm_content=postagilismgarysage&dm_i=12QQ1YERX,BQ45HU,7120M,1

 

Enterprise-level Product Backlog Organization

A lot of thinking about Agile seems to be based on small, single-team projects rather than large, complex enterprise-level initiatives and there is a limited amount of information on what needs to be done to scale small, single team projects to large, complex enterprise-level initiatives and how to structure an enterprise-level product backlog.

One of those areas that often needs to be done differently on large, complex, enterprise-level projects is Product Backlog organization.  On small single-team Agile projects, the predominant thinking seems to be that you only need to plan the backlog a few sprints in advance, you just prioritize the stories in the backlog, and then pull them off as needed to start a sprint.  That method starts to break down as you scale projects to large, complex enterprise levels.  There are a number of problems I’ve seen with that approach:

  • Without planning the backlog further in advance, it’s difficult to assess the overall scope of the project and determine the resources required for the project.  For example, I’ve seen a project that just started development with a small, single Agile development team and after two years of development still had no end-in-sight of when the project would be completed.  It was a major surprise when we stepped back and re-planned the entire backlog at a high level to find that the project was going to take almost another two years to complete with the current level of resources.
  • When you have a large product backlog with hundreds or perhaps even over 1,000 stories, understanding the inter-relationship of the stories becomes important.  When you make priority changes among stories in the Product Backlog, it often doesn’t make sense to do it the level of individual stories…if you move one story up in the Product Backlog, what about the other stories that are inter-related with it?  Wouldn’t you want to move all of those stories together as a group?  Organizing the Product Backlog into Epics and perhaps even themes provides a way to make priority decisions at a higher level that is more appropriate for enterprise-level projects.  At that level, priority decisions are often more based on a higher-level of epics and themes rather than at the level of individual stories within an epic or theme.
  • Another major problem area is architecture. If you take a piecemeal approach to doing individual stories without planning and considering the entire solution, it can lead to poor architectural decisions and possibly significant rework later on.
  • Finally, when a project grows to the point that multiple teams are involved, it becomes even more essential to organize the work to be done in a way that it can be segmented among multiple teams without requiring excessive amounts of coordination overhead among the teams.

In another article I recently wrote on “Enterprise-level Agile Implementation“, I discussed the other levels of management that are typically found at an enterprise-level in larger companies that need to be integrated such as Program Management and Product/Project Portfolio Management.  In a large company, organizing the Product Backlog into a hierarchical structure can be essential to support effective decision-making at those higher levels of management above the level of a single Agile team and that is often critical to ensure that all of the projects in an organization are well-aligned with the company’s overall business strategy.

Enterprise-level Agile Implementation

I was recently asked to help a consulting firm who is working with a client having trouble with a very large enterprise-level Agile implementation.  It seems that the company had gone head-over-heels into Agile across the whole company and the senior executives were unhappy with the way it was going.  Many projects were going off track and senior management didn’t feel like they had much visibility and predictability to see if all the development efforts were really well-aligned with the company’s business strategy.  I think this is a typical problem that many companies face for large-scale, enterprise-level Agile implementations.

The problem is that large companies typically have some kind of management infrastructure such as a PMO  for managing projects as well as some kind of project portfolio management approach to align projects with the company’s business strategy and that existing management infrastructure probably isn’t totally compatible with an Agile development approach.  The choices are:

  1. Dismantle the existing management infrastructure and simply implement Agile at a development team level with no guiding management infrastructure.  That typically results in problems  such as projects going out of control and not being well-aligned with the company’s business strategy.
  2. Implement a new top-to-bottom Agile management approach such as the Scaled Agile Framework.  This is a good solution but requires a major redefinition of the company’s management infrastructure and some companies are just not ready to make that kind of gut-wrenching change.
  3. Implement a “bridge” between the existing management infrastructure and the Agile development approach using a hybrid management approach overlaid on top of the Agile development process.

The most important point is that you can’t ignore the need for these higher levels of management and implement Agile as a development process without defining some way that it integrates with the company’s overall business strategy. The choices look something like this:

Enterprise Level Agiie Business Strategy

This can be a difficult thing to do because standard Agile methodologies such as Scrum do not provide much guidance above the development team level and there are a number of choices at each of these levels.  At each level, there is a choice of implementing a more Agile or a more traditional, plan-driven management approach.  It is somewhat like a chess game as shown in the diagram below:

Enterprise Agile 2

Here’s how I would position some of the frameworks for filling this need:

Enterprise Agile 3

The three frameworks shown above are:

  1. My own Managed Agile Development model
  2. Scott Ambler’s Disciplined Agile Delivery model
  3. Dean Leffingwell’s Scaled Agile Framework (SAFe)