Category Archives: Agile Transformation

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…

How Do You “Sell” Agile?

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.

Fitting the Approach to the Business

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

Taking a Business Perspective

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.

Benefits of a More Agile Approach

It’s important to focus on the benefits – how will it help the business? Don’t just try to become Agile for the sake of becoming Agile. 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 Satisfaction

Finally, 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

Overall Summary

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

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.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

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.

What Is Business Process Reengineering?

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. However, it was a gut-wrenching change for many companies because, in many cases, implementing an ERP system required rethinking their business processes and 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

Understanding Business Process Reengineering

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

Radical Redesign of Core Business Processes

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 is 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?

Start With a Blank Sheet of Paper and Rethink Everything

The next statement is

“In Business Process Reengineering, companies start with a blank sheet of paper a2nd 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.

Adopt a New Value System

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. However, that needs to be done in a larger context of how it improves the customer value that the company delivers to its customers.

Reduce Organizational Layers and Eliminate Unproductive Activities

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”

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

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.

Frequent Mistakes

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.

How Do You Determine the Right 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.

  • Product-oriented Companies – A pure Agile approach is best suited for a company that is in the business of producing some kind of software product (an example would be Intuit and TurboTax or Quicken) or where the software plays a very direct role in leveraging the company’s primary business (an example would be Amazon.com).
  • Project-oriented Companies – Where that is not the case and the company’s business is only indirectly leveraged by the Agile development process (an example would be an internal IT application development project), it can be a lot more difficult to implement an Agile development process because more adaptation may be required to fit the Agile development process to the company’s business environment.

What’s the Key Difference?

Here’s the key difference –

  • In the product development company, the company typically budgets a fixed amount of development effort to produce and sustain the product and the business decision is primarily about prioritizing how that money is spent on creating new features for the product to get the most business impact.
  • That kind of business decision fits very nicely with an Agile development process approach and it’s relatively easy to implement an Agile development approach in that kind of environment.

How Do You Develop a “Business-centric” Approach?

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 Is Needed?

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.

The “Program du Jour” Approach

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.

Blending a Top-Down Approach with a Bottom-Up Approach

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. Check out this article for more on that:

Business Process Reengineering and Agile Transformation

Overall Summary

The key message is that you have to consider an Agile development process in the context of the business it operates in and many times you need to adapt an Agile development process to fit the business environment.

  • Within the development process itself, the process may be largely the same – the differences may come into play at a higher-level such as the project portfolio management layer that wraps around the project.
  • Those higher-level layers could also be Agile (Dean Leffingwell’s Scaled Agile Framework is an example), but that kind of complete, top-to-bottom Agile transformation just doesn’t work in all business environments.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

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 Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach? When people use the term “Agile Coach” it is often not exactly clear what they mean.

Typical Team-level Agile Coach Role

Most often, what they’re talking about as an “Agile Coach” is what I would call a team-level Agile Coach. That is someone who works at a tactical level with individual members of an Agile team to help them become more proficient in executing a Scrum process.

  • There is very little standardization or certification for what it takes to become an “Agile Coach” at that level and
  • Almost anyone could claim to be an “Agile Coach”.

What Is an Enterprise-level Agile Coach?

What is an Enterprise-level Agile Coach?

Beyond that; however,

  • The role of an Agile Coach at an enterprise-level needs to be better-defined and differentiated from a normal team-level “Agile Coach” role.
  • An enterprise-level Agile Coach works at a more strategic level to integrate an Agile development process with a company’s business. (See diagram above)

Enterprise-level Challenges

An Agile Coach at an enterprise level typically helps plan and organize an enterprise-level agile transformation.

  • However, many Agile Coaches are only trained in Agile from a team-level development process perspective and make the assumption that whatever is good for the development process must be good for the business as a whole
  • They also may assume that it is a binary and mutually-exclusive decision to be either “Agile” or “Waterfall” and attempt to force-fit the entire company into an Agile model when the right solution is to fit the approach to the company’s business

The Impact of the Business Environment

The problem is that there is a big difference between companies whose primary business is focused on product development and other types of businesses.

Product Development Companies

  • Agile works very well in companies that are in the primary business of developing products (particularly software products). Intuit is an example that develops TurboTax, Quicken, and QuickBooks).
  • In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company
  • It is very easy to apply an Agile development process in that environment.

Non-Product Development Companies

It is much more difficult to apply an Agile development process in a company that is not in the primary business of developing products. In that kind of business, the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products,

  • You can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process
  • The company’s overall culture and business strategy needs to be optimized around the critical success factors for that business

Fitting the Approach to the Business

For example,

  • If a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and
  • That doesn’t necessarily align completely with just becoming more “Agile”.
  • In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach.
  • The implementation of that strategy often requires fitting the approach to the company’s business environment rather than simply trying to force-fit the company to some kind of overall Agile approach.

Blending Agile and Plan-Driven Project Management

The approach that you might wind up with in that kind of environment also could be a blend of Agile and traditional plan-driven management principles and practices blended together in the right proportions to fit the situation. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices; as well as
  • Traditional project management principles and practices
  • And a deeper understanding of the principles behind both of them (not just the mechanics) to know how to blend them together as necessary to fit a given situation

Business Perspective

Beyond that; however, it also requires the ability to look at a very complex, broad-based, enterprise-level business from both a more strategic high-level business management perspective as well as a more tactical product development process perspective to develop a strategy for integrating the two.

What often seems to happen is

  • Someone who is trained in “Agile” from a development process perspective attempts to steer the company in the right direction and
  • That person typically doesn’t have the breadth of business management experience and agile development process experience to know how to successfully integrate the two.

Is it any wonder why some of these “Agile transformations” are not successful?

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Enterprise-level Agile Implementation

I was recently asked to help a consulting firm who is working with a client having trouble with a very large enterprise-level Agile implementation. 

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

The Challenge

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

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

Higher Levels of Management

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

Enterprise Level Agiie Business Strategy

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

Enterprise Agile 2

Potential Enterprise-level Agile Frameworks

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

Enterprise Agile 3

The three frameworks shown above are:

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

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.