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:

Politics and Agile Project Management

Have you ever thought about the relationship of what’s going on in politics and Agile Project Management? I think there’s possibly a significant relationship between the two. Look at what is happening in politics throughout the world:

  • In the UK,  regardless of whether the decision to leave the EU is right or wrong, the “Brexit” vote indicates that many people want to have much more direct control of their own government
  • In the US,  Bernie Sanders and Donald Trump probably couldn’t be further apart in their political orientation but they do have one very significant thing in common – they are both attractive to people who are frustrated with the bureaucratic and cumbersome nature of establishment politics.

What Do People Really Want?

Without taking sides in any of these political contests, the pattern seems to be clear – people are fed up with bureaucracy and traditional, establishment politics and want a radical change.  However, many people are beginning to be concerned about the potential impact of such radical change.  What will be the impact of tossing out all of our experienced political leaders and moving to a much more unpredictable environment?  I don’t think anyone really knows the answer to that question.

Politics and Agile Project Management

Does that sound familiar?  I think it does. 

What’s the Relationship to Agile Project Management?

A lot of organizations and people are fed up with force-fitting a traditional, plan-driven project management approach on their organizations that hasn’t changed significantly since the 1950’s and 1960’s.   They want to get rid of bureaucratic and cumbersome management processes.  Many businesses and people want radical change and they see Agile as a potential solution to that need.  However, tossing out all of the established way of doing things is a concern to many people and organizations.

An Agile Project Management approach can provide a nice compromise.   It provides a way to break away from a traditional, plan-driven project management approach; however, it doesn’t really require completely tossing out all of the established ways of doing things and starting completely over from scratch.  It provides a way to customize a management solution to fit the needs of a given business environment and projects.

If you look at what has happened with Agile, the Agile Manifesto that was developed fifteen years ago in 2001 started a revolution and many people in the Agile community have advocated a fairly radical approach to get rid of traditional, plan-driven project management altogether.   On the other side of that fence, there have been some project managers who are resisting this change and are equally polarized on insisting that a traditional, plan-driven approach is the only way to do project management and are force-fitting that approach on all projects.

What Does the Future Look Like?

I think that the polarization between the project management community and the Agile community is starting to fade away as people start to see that it is possible to blend the two approaches together in the right proportions to fit a given situation.   I hope it doesn’t take a long time for the polarization that exists in the current political environment to fade away.  Countries are like businesses in a sense – they are much stronger if the people in the country and business are unified around a common direction for the country/business and countries/businesses are weakened by excessive polarization and fragmentation.

Achieving that kind of unifying vision isn’t easy either in politics or in a business environment.  In both cases, it takes strong leadership to bring people together.  That’s why I’m so passionate about helping to develop that kind of leader in the Agile Project Management community.

 

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.

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