I am amazed at the amount of “tunnel vision” in Agile. Many people see it only as a development process for single teams and don’t pay much attention to the larger context that the development process operates in. An Agile project always exists inside of some business context and if you look at the project from that business context rather than looking at it only from a development perspective, you might see a very different picture.
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). 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.
Here’s the 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.
In a company that is in some other kind of business where the software development effort plays a more indirect role in leveraging the company’s business, there is typically a very different kind of decision process. An example would be a company whose business is focused on achieving operational excellence (like Walmart) and not heavily focused on product innovation as a primary business goal. In that kind of environment, there is typically some kind of Project Portfolio Management approach to determine how to allocate the company’s IT budget to get the most “bang for the buck”. The company needs to choose the projects that are going to provide the highest amount of leverage to the business and then monitor those efforts to see if they really do produce the desired effect.
At the level of a single team development process, the effort may look the same as a product development company, but the business context is entirely different and requires some adaptation. The primary difference is in the level of planning required. In a product development company, you might be able to use a highly adaptive approach with almost no Product Backlog defined in advance and you might be able to almost completely define the requirements for the project as it progresses looking no more than 2-3 sprints ahead into the future. That’s what a pure Agile approach looks like; however, that doesn’t work in environments where there is more of a need to plan the project in advance and estimate the schedule and costs of the project to support a higher-level project portfolio management decision process.
In those environments, there is a typically a need to at least define the Product Backlog to a sufficient level to define the scope of the project and to provide at least a high-level estimate of the costs and schedule for the project. Some people will say that it is futile to attempt to estimate the costs and schedule for an Agile project because the requirements are only going to change. I don’t totally buy that…this is not an all-or-nothing decision to have a project totally planned in detail (like the Waterfall approach) or not planned at all (totally adaptive). There are plenty of alternatives between those two extremes to pick a level of planning that is appropriate for the project, the level of uncertainty in the requirements, and the business environment that it has to operate in.
Some people will also say that you have to force the entire company to change its culture to become totally Agile in order to implement an Agile development process. A company has to define its culture around what makes the most sense for the business it operates in and that may or may not align very well with an Agile development process. In the product development company, it probably aligns very well and it makes sense for the company to become more Agile in delivering new and innovative product features to market quickly. In a company like Wal Mart whose business is leveraged primarily by operational excellence and lower costs, that is probably not the case and you can’t necessarily force the company to adopt a totally Agile culture.
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.