Recently the Enterprise Irregulars have been discussing whether the software development methodology known as Agile is also suited to software implementation. It's a good question. Agile Development is really more a conceptual framework than a methodology. If you are not familiar with it, this explanation from Wikipedia is helpful:
Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project. It chooses to do things in small increments, with minimal planning, rather than plan at length. This helps to minimize the overall risk, and allows the project to adapt to changes more quickly. There is also an emphasis on stakeholder involvement. Meaning at the end of each iteration, the stakeholder is consulted about the product and comments are noted. And ...The catch line for Agile software development is Develop quickly, deliver often
It obviously gets more complex as you get into it. What's the alternative? A long project plan where we try to fit in all possible contingencies, work that is normaly done outside of the sight and minds of the users and other stakeholders and delivered in one fell swoop. Sound familiar? Back to the original question: Can Agile concepts be parlayed for software implementation? My answer is yes they can. I got to this point many years ago after I saw conference room pilot after conference room pilot blow up. It was an Oracle implementation for a large multi-national. We flew people in from all over the country to see firsthanf how they were going to conduct business in Oracle. This was after months of requirements analysis. The response was overwhelmingly negative. Too much was misunderstood or completely forgotten. In the end, users as well as consultants understood that we needed to dig deeper to understand how the business operated. Thus began my quest for a different and better way of doing business. Eventually I got to the point where I started to hold meetings with users and stakeholders and demo some process in the system. Management frowned on this practice because it did not follow from the methodology. Also, my users told other users that they were already active in the system and all hell broke loose. My slogan at the time was Prototype early and often. The biggest problem with this approach was that it required a lot of trust between the users and the consultants, something that is very rare when you are working with employees of large organizations. They rarely trust each other much less an outsider. But working with Small and Medium Enterprises, or SME, now makes agile implementation a more tenable alternative. Normally we evolve a sense of trust during the sales process and this rolls over into the implementation. Why the need for trust? Well, working from the concept of multiple iterations, it necessary to share an incomplete system with the stakeholders. They have to understand that and not run from the room screaming. We are going to take baby steps and get to the end sooner that if we wait, wait, wait and then try a huge leap. On the consultants side they have to trust that the stakeholders are going to remain committed to the project and see it through to successful conclusion. Case in point is rolling out a new website. No matter how much explanation you do when the users see the first draft they will immediately know what's not there, what isn't working. The human mind seems to be set up this way. The result is that consultants shy away from this experience. They tend to show 'mock-ups' which are really 'muck-ups' until they have the thing nearly finished. Then they show the whole thing and start the re-work portion of the project. But the same can be said for implementing a new chart of accounts and set of books. We normally take the business requirements discussion on Monday and give the client a brief demo on Wednesday. We find this accelerates decision making a great deal. But again if you don't keep the client really focused on the prototype they will wander around and get themselves into a knot of confusion. You can find out so much more when you have a live process to look at together. But you must keep the client focused on the process in the system and not the system alone. For further discussion check out Bob Warfield's post here, and read the comments as they are very close to the experiences that I relate above. For myself, I am an optimist by nature and so I give people the benefit of the doubt and hope they meet my expectations; they normally do. Agile implementation works well for us and I think that it gives client stakeholders something that a conference room pilot cannot: A stake in the new system. | 
