This post has been superseded by a new version. The new version can be found here:
I recently saw a question on a LinkedIn discussion group asking:
What is role of a PMO in an Agile/Lean organization?
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. A related stereotype is that many people also see the choice between Waterfall and Agile methodologies for projects as a binary decision – that stereotype is that an organization is either:
- Totally “Waterfall” with extensive upfront project planning as well as rigid policies and controls over how projects are executed, or
- Totally “Agile” with zero upfront planning and no policies and controls over project execution
Neither of those extremes is realistic in actual practice and you have to use good common sense to fit the right level of upfront planning and control to the project and business environment that the company operates in.
Many people make the mistake of seeing this as a binary decision and force-fit projects to one of those two extremes when the right solution is to fit the methodology (or combination of methodologies) to the project and business environment. It takes more skill to do that – it requires knowledge of a broader range of methodologies as well as a deeper understanding of the principles behind them to know how to blend traditional project management and Agile principles and practices together in the right proportions and customize them as necessary to fit a given situation.
I believe the 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. It 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.
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:
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.
- 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.
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.
- 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. 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:
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:
- 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.
- 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?
- 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”: