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.
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:
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.
You will find much more detail on this in my Online Agile Project Management Training.