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.

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.

An Agile Approach to Risk Management

I recently participated in a LinkedIn discussion on risk management that was heavily focused on a conventional approach to risk management built around a plan-driven approach to project management. I wanted to share my thoughts on how I think we need to take a broader view of risk management that would be appropriate for an Agile project environment as well as a traditional plan-driven project management environment.

First, let me preface this post by saying that I’m not an “Agile zealot”. If you’ve read any of my other posts or books or taken my training courses, I’m sure you recognize that I think that there is a widely-held misconception that:

• “Agile” and “Waterfall” are polar opposites of each other, and
• There is a binary and mutually-exclusive choice between the two approaches

I think we need to broaden our view of project management to see “Agile” and what is commonly called “Waterfall” as complementary to each other rather than competitive and recognize that traditional plan-driven project management is not the only approach to project management. I prefer to think of a continuous range of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme that looks something like this:

And, the right thing to do is to fit the approach to the project rather than force-fitting a project to some arbitrary model (whatever it might be – Agile or plan-driven). One of the biggest characteristics that would influence the choice of an approach is the level of uncertainty in the project.

If you think of a broader approach to project management in those terms, it has a big impact on how you might do risk management. Here’s how I see some of the key differences in a risk management approach that might be associated with a more adaptive approach to project management in a very uncertain environment:

Why is Risk Management Different in an Agile or More Adaptive Environment?

1. Definition of “Failure” – Risk is associated with the failure of a project, so how you define “failure” has a big impact on how you do risk management.
   • In a traditional plan-driven project, the requirements of the project are typically well-defined and a “failure” would normally be associated with failing to deliver those requirements within the required cost and schedule budgets allocated for the project. In that kind of environment, it wouldn’t normally be considered a failure if the project met the requirements it was supposed to meet within the cost and schedule goals but failed to deliver the appropriate business value.

   That approach works fine in an environment where it is possible to relatively accurately define the requirements of the project before the project starts and three is a reasonable level of certainty that if you meet the defined requirements, the project will automatically produce the appropriate business value that is required.

   • An Agile or more adaptive approach is best in situations where it is much more difficult to define detailed requirements for the project prior to the start of the project and there is far less certainty of what is required to produce the appropriate business value. In that kind of environment, there is a much larger risk that the project won’t produce the required business value even if it does meet the defined requirements within budgeted cost and schedule goals. That’s a very important difference between an Agile (or adaptive) approach and a more traditional plan-driven approach.
2. Relationship to Upfront Planning – Since an Agile approach normally has a lot less upfront planning, it typically requires a more dynamic approach for identifying and managing some of the risks while the project is in progress rather than a comprehensive approach to identify and anticipate risks before the project starts.

   Note that this is not an all-or-nothing choice between zero upfront planning and highly detailed and rigid upfront planning – the approach to planning could be anywhere between those extremes and the approach to risk management should be consistent with the level of planning.

   The important point is that it just isn’t practical to take a comprehensive approach to identify and anticipate all risks in a project with a very limited amount of upfront planning.

3. The Relationship to Business Value – The risk of not producing the appropriate business value in a very uncertain environment is a very different kind of risk and requires a different kind of risk management approach. That kind of risk isn’t necessarily totally black-and-white – you could produce a relatively mediocre product that met the letter of the requirements but really didn’t provide much business value.

   A conventional approach to risk management is generally based on avoiding and eliminating risks and uncertainty as much as possible so that the project will deliver predictable results, but that approach can work against you if you have a goal of maximizing business value. (See my previous article on Management of Uncertainty in Agile Projects).

   In many cases, risk is associated with opportunities to provide a higher level of business value. With a conventional approach to risk management, you might try to reduce the level of uncertainty and ambiguity associated with user requirements as much as possible prior to the start of the project and you might also tend to favor a low risk approach of using tried-and-true technology rather than “pushing the envelope” a bit to use riskier technology that might provide a higher level of value to the user. From a conventional risk management perspective, that may be the right thing to do but it could easily result in a very mediocre product that doesn’t provide much business value.

How is the Approach to Risk Management Likely to be Different in an Agile environment?

Some people might think that risk management isn’t appropriate in an Agile environment – I don’t believe that to be the case. You can do as much or as little risk management as needed depending on the nature of the project – it just requires a different approach to risk management.

1. It needs to recognize a broader definition of “failure” – a project can fail by failing to deliver business value even if it meets defined requirements and meets its cost and schedule goals
2. The approach to risk management needs to be consistent with the overall level of upfront planning in the project – that might mean a less comprehensive identification and analysis of risks prior to the start of the project and a more dynamic approach to risk management as the project is in progress.
3. Instead of seeing all risks as a bad thing that should be avoided and eliminated, we need to recognize that some risks are related to opportunities. For that reason, a decision to avoid or eliminate risks needs to consider the impact of potential missed opportunities as well as the impact of the risk.

Advantages of an Agile or Adaptive Risk Management Approach

In fact, an Agile or adaptive approach can have a lot of advantages for developing a very effective risk management approach. Steve Gordon commented that Agile or adaptive thinking provides the ability to structure a project to fail early and inexpensively to minimize the impact of a risk on the overall project. Wayne Mack also suggested several more specific risk management advantages that an Agile or adaptive approach can provide:

• “Technical risks are addressed through early prototypes (“spike stories”) and side-by-side comparison of alternatives (‘A/B testing’)”
• “Integration risk is mitigated through early and continuous integration. User acceptance risk is mitigated through early product review”
• “Cost and schedule risk is mitigated through incremental releases – we always have something to show for the money spent; it is no longer an all or nothing trade-off”