The gang of Enterprise Irregulars are currently wondering whether Agile can work for implementing Enterprise Software. By implementation, I mean installation and integration of a complex package such as an SAP or Oracle ERP system.
It’s an interesting question. I thing it could work, and work well in theory, but I think there are a number of factors that would make it extremely difficult to do in practice.
First, let me say I’m a fervent believer in Agile software development, and helped contribute some of its fundamental underpinnings early in my career. One of the seminal papers behind the early Agile movement was a study done on one of my development groups that found productivity was off the charts.
With that said, Agile is not for everyone or every project. There are some requirements for it to be successful that fly in the face of a lot of the established norms for IT projects and implementations. That’s not to say you couldn’t use Agile for such projects, but unless everyone involved clearly understood the Agile requirements, it would not likely be an unsuccessful attempt.
What are these requirements? In the context of implementations, I would see the following sorts of major conflicts:
First, Agile is the opposite of a boil-the-ocean project. It recognizes that you shouldn’t even try to do everything in one release. It argues for many small evolutionary releases, or if not releases, at least milestones where things are stabilized and accepted as complete before moving on. In some cases overly ambitious goals that can only be met in a single humongous milestone are rejected.
Second, Agile recognizes that it is often folly to completely specify a system before writing any code. As such, it seeks to be iterative, to get something built, to get feedback on that checkpoint, and then to iterate until the feedback is acceptably positive. This requirement is particularly at odds with the normal desire on both sides to manage risk (apparently) by documenting everything in incredible detail before much gets done. In my mind there is a false sense of security in long SOW’s and other documents that is no substitute for signing of small subsystems that you can actually use, test, and demonstrate are working. But, this is what the world grew up on and is used to.
In many ways, Agile has a risk profile more similar to SaaS. Consider a huge up front investment in specification to be the equivalent of paying an On-premises license fee up front. Neither the spec nor the license are worth much until some software is written and working.
Lastly, Agile is not well suited to extremely large groups and it eschews heavy process quite on purpose. It’s important to note that it does this not to enhance creativity as Vinnie fears, but precisely to enhance productivity. It recognizes (as is called out in the Coplien paper I link to above) that the primary productivity bottleneck in software development is communication.
The Mythical Man Month issue is the more people, the harder it is to keep them in sync. If our bench is limited, we perforce select the best possible players to be on the team. This again, is sharply at odds with the typical SI practice of having very few talented players and lots of grunts. The talented players often move around constantly fire fighting. An Agile approach favors using only the most talented players on small teams. Clearly this interferes with the economics of most SI’s who want to bill as many hours as possible using labor that is as cheap as possible.