Category Archives: Enterprise-level Agile

How Do You Choose the Right Agile Approach for Your Business?

How do you choose the right Agile approach for your business? Many people will say that you have to convert the entire company and it’s business to an Agile approach in order to make an Agile development process work. That might work for some companies but it isn’t necessarily a good solution for a lot of other companies.

Choose the Right Agile Approach for Your Business

Choose the Right Agile Approach for Your Business

The most important thing to recognize is that the choice of an Agile approach is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.  You have to fit the approach to the nature of the company’s business rather than trying to force-fit the company’s business to one of those extremes.  A major factor in selecting the right approach is the relative importance of two factors in enabling the company’s business success:

Creativity and Innovation versus Predictability, Planning, and Control

It’s not as simple as just becoming “Agile”.

  • A need for emphasizing creativity and innovation would pull you towards an Agile approach
  • A need for predictability, planning, and control would tend to pull you towards a more plan-driven approach (aka what many people loosely call “Waterfall”)

And, I want to emphasize again that those two choices are not mutually-exclusive.  For example, suppose your company is Apple and you need to design the next generation of the iPhone.  Creativity and innovation is obviously important to that effort – otherwise the product would not be very competitive;  however, it also has to be somewhat predictable because you have to hit a certain release date.

Impact of the Company’s Business Model

The nature of an Agile transformation and the relative importance of those two factors will depend a lot on the company’s business model.  Here’s a brief summary – there are two major types of companies that will have a big impact on the nature of an Agile implementation:

  1. Product Development Companies – In a company that is in the primary business of developing products (for example, Apple, Intel, and Microsoft), there is a strong and natural alignment between an Agile development approach and the company’s overall business goals.
    In that kind of environment,  the ability to quickly develop new products and product features is very important for the company to be competitive and successful and, as a result, creativity and innovation play a major role.
  2. Other Companies – In other companies who are not primarily in the business of developing products (For example, Walmart, McDonalds, Hilton Hotels), any development efforts will likely be focused on projects that are not directly related to products they sell to customers.
    Those projects will most likely only indirectly leverage the company’s primary business goals by enhancing operational efficiency, productivity, or some other means.  In that kind of environment, some level of planning and control is important to guide those investments that the company is making in new technology:

    • You want to pick the right combination of project investments that are going to have the greatest impact on the business, and
    • You want to manage those investments to make sure that they do, in fact, provide the return you were expecting

Impact of Financial Planning Model

The way that the company does financial planning is a major factor in determining the right approach:

      1. Product Development Companies – In companies whose primary focus is on product development, a budget is typically established for development and ongoing support of a product or a product line and a lot of discretion is typically given to the Product Manager and the product team in determining how to best utilize that money to maximize the success of that product.  Its relatively easy to apply an Agile development process in this kind of company because there is such a strong and natural alignment between the product decision process and the company’s overall  business management approach.
      2. Other Companies – In other companies that are not primarily in the business of developing and selling products, you’re likely to find a very different environment and the relationship between the project decision process and the company’s overall business management approach is likely to be very different:
        • There are likely to be a lot more projects competing for funding,
        • The relationship of those projects to the company’s business goals is probably more indirect,
        • In many cases, there are dependencies that might require coordinating a change in business processes to implement the project and realize the return, and
        • Many of the projects might be somewhat short-term in nature so there also may be a lot of churning going on constantly.

        That kind of environment obviously calls for more planning and control to maximize the return on investment across a portfolio of potential projects. You just can’t throw money at projects, allow them to go off and figure out the right approach, and expect that somehow it is all going to work out.  The whole process needs to be much more managed.

      What’s the Solution?

      For companies that are not primarily in the business of developing and selling products, it isn’t just a simple matter of making the whole company agile. It typically will require a hybrid approach that mixes some level of traditional plan-driven management with an Agile development process in the right proportions. That takes a lot more skill but it definitely can be done.

    • I think of it like a chess game that may have different levels of management in it.  The challenge is to figure out how many levels are needed; and, for each of these levels, how agile should it be?  Also, how does the whole thing fit together and align with the company’s business objectives?  Naturally, you want to keep it as simple as possible but it’s not as simple as just making the whole company more agile.

    • Related Articles

      I’ve written several previous articles on the relationship of Agile and company culture that are relevant to this:

How Do You Use Agile for Business Processes?

I was recently asked: “How do you use Agile for business processes?” Here’s my response:

Many people confuse Agile with Scrum and when they say “Agile”, they really mean “Scrum”. Scrum is not a solution to every problem but you can apply general Agile principles and Agile thinking to almost anything. It’s mostly just a shift in thinking rather than attempting to follow a well-defined Agile methodology like Scrum.  For example, I have written several books on Agile Project Management and I used a somewhat Agile process to publish the books:

  • I started out with a vision of what I wanted to do with the book and further elaborated it as I went along rather than having a highly detailed outline of exactly what the book would look like to start with
  • I engaged a group of people over the Internet to provide feedback and inputs. These people represented potential customers of the book as well as subject matter experts
  • I took an adaptive approach to adapt the design of the book based on the feedback I received
  • I used an incremental development approach. As I wrote each chapter or section of the book, I put it out for feedback and inputs and made adjustments as necessary based on that feedback and inputs

You can use that kind of thinking process on almost anything without necessarily following all the rituals of Scrum.

A lot of people also want to try to use Agile for business process improvement and that’s not necessary. There are lots of ways to improve business processes that are totally independent of Agile. For example, Agile is based on the ideas of continuous improvement that have their roots in Total Quality Management (TQM), Lean, Six Sigma, and other approaches that go back long before Agile. It isn’t essential to fully adopt Agile if what you really want is business process improvement.

Many people seem to want to jump on the Agile bandwagon because it is the latest and hottest buzzword to adopt but it isn’t necessarily a solution to any problem you might have.

Scaling Agile and Scrum for Large, Complex Projects

There is a lot of confusion and some fairly polarized opinions about scaling Agile and Scrum for large, complex projects involving multiple teams.

  • Some people think that it can be done simply by adding a Scrum-of-Scrums approach to provide a mechanism to coordinate the efforts of multiple teams.
  • A more comprehensive approach for integrating the efforts of multiple development teams is Large-Scale Scrum (LeSS). A Scrum-of-Scrums approach is a loosely-coupled approach that only provides for basic coordination of the work between teams – each team still operates fairly independently. LeSS is a much more tightly-coupled approach that goes beyond the very basic level of coordination of work that the Scrum-of-Scrums approach provides.

The table below shows a comparison of the two approaches:

Scrum-of-Scrums LeSS
Coordination of Work Formal Scrum-of Scrum’s Meeting Informal, “Just Talk”
Product Backlog Management
(Single or Multiple Backlogs)
Not Specified Single Product Backlog
Sprint Planning
(Separate or Joint)
Not Specified Joint
Sprint Review
(Separate or Joint)
Not Specified Joint
Allocation of Work
(Component or Feature)
Not Specified Feature

The right approach will depend on the project and the need for a more loosely-coupled or tightly-coupled approach for integrating the development efforts. However, both of these approaches only address integration of the teams from a technical, development perspective and do not explicitly provide any mechanism for integration of the efforts from a business perspective. It is assumed that the normal Product Owner role provides that level of integration but that may not be very realistic for very large, complex projects. This is really a multi-dimensional problem as shown in the diagram below:

Agile Scaling Dimensions

The Scaled Agile Framework (SAFe) and other enterprise-level Agile frameworks recognize the need to provide this level of business integration with an appropriate level of program management and/or product/project portfolio management to ensure that the development efforts are well-integrated and well-aligned with the company’s business strategy.

Enterprise Agile Scaling Frameworks

There is a lot of confusion and conflict in this area:

  • A number of people who see this from a development perspective tend to think that SAFe and other enterprise-level frameworks that address the problem of business integration are just unnecessary overhead and bureaucracy
  • Many people who see this from a business strategy perspective don’t understand the need for integrating development efforts from a technology perspective

There are three major challenges that need to be considered:

  1. Integrating the efforts of multiple teams from a development perspective
  2. Aligning the efforts of all teams with the organization’s business objectives
  3. Coordination with other related efforts outside of the project team and providing tracking and progress reporting to management

Both the development integration perspective and the business integration perspective have merit and need to be considered when scaling Agile/Scrum to large, complex projects and all of the above challenges may need to be addressed to make a large, complex, multi-team Agile project successful.

 

How Do You Go About Selling Agile?

A student in one of my courses asked if I could help him develop a short and succinct way of “How Do You Go About Selling Agile? I think it’s an excellent topic and I told him I would write up something on that. Here it is…

First, I don’t think that anyone should start with an objective of “selling Agile” to anyone. There are a lot of people out there who try to do that and I think it is fundamentally the wrong approach to try to convince someone to become more Agile rather than focusing on how becoming more Agile will help them and what problem it will solve.

I also very strongly believe that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall”; and, rather than attempting to force-fit a business or project to one of those extremes, you have to go in the other direction and fit the methodology (whatever it might be – Agile or plan-driven or some combination of both) to the situation. It takes a lot more skill to do that but it definitely can be done. It requires:

  • A broader knowledge of different methodologies (both Agile or adaptive and plan-driven) and an ability to see past many of the stereotypes, myths, and misconceptions that exist about what’s commonly referred to as “Agile” and “Waterfall” to see those two approaches in a fresh, new perspective as being complementary to each other rather than competitive and to objectively understand the strengths and weaknesses of both approaches
  • The ability to take a “systems thinking” approach to see those methodologies in a broader context beyond just a development process perspective of how they relate to an overall business and what problems they might solve
  • In addition to all of that, you also need to understand the principles behind the methodologies at a deeper level (rather than just the mechanics of how to perform the methodology) to understand how to blend different, seemingly disparate methodologies together as needed to fit a given situation

I’ve developed a set of online training courses that are specifically designed to help prepare people for those challenges, you can check that out here:

Agile Project Management Training Courses

However, if you’re trying to “sell” a manager on becoming more agile, he/she probably doesn’t have all of those skills and they’re probably not willing to sit through a series of training courses to develop those skills either; so, how do you develop a relatively simple “elevator speech” to help someone understand why they should even consider becoming more Agile?  Here are some thoughts on that:

  1. First, you have to look at it from an overall business perspective , not from a more limited development process perspective. It’s very easy to get “tunnel vision” with Agile – we get so enthusiastic about the benefits of Agile from a development process perspective that we assume that what’s good for the development process must be good for the company as a whole and that’s not necessarily the case. Rather than attempting to force-fit a company to an Agile approach; you may have to craft an approach that is more well-aligned with the primary success factors that drive the company’s business and becoming more Agile may or may not be the most important factor in the company’s overall business success.
  2. Second, you have to recognize that some companies are scared to death of Agile – they’re afraid of losing control and that fear is not totally unfounded if the Agile approach is not well-designed and managed. So, you may need to start off with more of a hybrid approach as an initial first step to demonstrate success rather than going full-bore into a complete corporate Agile transformation. You also need to recognize that an Agile transformation can take a long time and demands a lot of patience and perseverance.
  3. Finally, nothing sells better than results. Work on developing good results and that will sell itself.

Although the benefits of adopting a more agile approach will vary from one company to another, there are some general benefits that apply, to some extent, to any company. Here are the key general benefits I would focus on in my “elevator speech”…

  • Adaptability – The biggest and most general benefit is adaptability – regardless of whatever other benefits an agile approach might provide, no one is likely to argue that there’s a big advantage in being able to tailor an approach to fit a project and a business rather than force-fitting all projects to a traditional, plan-driven project management approach
  • Time-to-market – Probably the next most important general benefit is time-to-market – a lot of people have the impression that an Agile project is always faster and that’s generally true but not always true. The real emphasis in Agile, in my opinion, is keeping the customer closely-engaged with the project as it progresses to ensure that what you’re developing really meets their needs. Sometimes that may actually take longer because it may involve some trial-and-error. However, very few people could argue that prioritizing requirements and delivering functionality incrementally rather than waiting to deliver the entire project all at once can significantly accelerate progress even if you don’t take a full Agile approach.
  • Reduced Costs – Another big factor is reduced costs associated with reducing unnecessary overhead in projects. This is another one that doesn’t require adopting a full Agile development approach to achieve – all it requires is taking a hard look at some of the documentation and other artifacts and controls used in a project and deciding whether they really produce value or not and who they produce value for.
  • Customer SatisfactionFinally, as I’ve mentioned, the big selling point of Agile is the improved customer satisfaction you get from having a customer directly engaged in the project to ensure that the project really solves their business problem and provides an appropriate level of value to them

The key point to emphasize is that all of these are relatively tangible benefits that can be realized, to some extent, on any project simply by using more of an “Agile Mindset” and it doesn’t necessarily require adopting a full-blown textbook Agile approach like Scrum and/or risk losing control of your business to get some of these benefits. Also, in addition to those more tangible benefits, there are also a lot of intangible benefits such as:

  • Improved employee productivity and morale that results from more empowered teams
  • Improved organizational synergy that results from higher levels of collaboration, trust, and shared responsibility within the organization

I want to add one note to this post that came out of some follow-up discussions we had on LinkedIn on this post…The word “selling” has a variety of different connotations. Some people regard “selling” as a manipulative process to convince someone to buy something they don’t want (like life insurance or used cars).

Years ago when I was a Program Manager in a large computer company, part of the training to become a Program Manager was a course called “Solution Selling” which was basically a consultative approach to “selling”. It created a different approach to “selling” – instead of going in to a client to sell them something like “Agile”, the “solution selling” approach is to go in to the customer and do a lot active listening to understand their problem before attempting to sell any solution. I think that’s the right approach with Agile also. There are people out there who get overly-zealous about “selling” Agile to the extent that “Agile” becomes a solution to any problem you might have. That’s the wrong approach, in my opinion.

Is the Idea of a PMO Obsolete?

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 and 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 modifying and extending Agile and Scrum may be 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 Transformation

I recently wrote an article on a “Business-centric Approach to Agile“. Have you ever thought about how similar Business Process Reengineering and Agile Transformation are? 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.

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. I think that a “business centric” approach to Agile is needed.

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

Making Agile work for your business is a real challenge. 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 Frameworks

    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, check out my online training course on “Making Agile Work for Your Business”.

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