Agile versus waterfall. Well, how about agifall?
Deployment methodology is one of the most debated topics in the system integrator community. We passionately argue about why our way is the best way. I had my own awakening moment a few years ago when a CIO of a long-term client called me. He was about to kick off a large project. He asked me not to take him through the same torture I had taken him through before. He challenged me that there must be a better way. He had a point. A lot has changed since we worked together - new cloud technology, more advanced functionality, etc. - but no change in our methodology.
That call triggered some soul searching with my colleagues. By that time, we had already deployed large-scale systems over 100 times. We had a well-established waterfall-based methodology. We knew what we were doing. You would think that if you do something a hundred times, it would get easier. Well, it was not. We were taking clients live, but they were not delighted. Project teams were often caught by surprise towards the end and put in enormous amounts of work to make things happen at the last minute. It was not a good experience overall.
After some soul searching, we realized that the system deployments were complex projects that deeply affected the organization itself. People were resistant to change due to many reasons such as loss of control, excess uncertainty, loss of face, etc. Yet, the success of the project depended on the organization to fully endorse the change triggered by the new system deployment. Without it, we would not realize the value we promised. Thus, we had no choice but to make the business feel more in control, develop competence, handle uncertainty and manage the work. It must be done in a disciplined and streamlined way. We concluded that the business processes should be chunked up into digestible pieces (sprints). Each piece would trigger a small amount of change. Businesses must be exposed to it as early and as frequently as possible. This gradual change management process coupled with the system deployment was the premise of our new methodology.
It is neither waterfall nor agile. It is something in between. Maybe agi-fal? Or do you like water-ile better? The waterfall is a very gated process. You do one thing at a time, get sign-off, and move to the next. Yet, you can easily miss the big picture. It is very hard for the business to understand what they are getting into until it is too late. Neither you nor the customer is that smart to envision a solution on power points that works. On the other hand, agile can be too unstructured and flexible. It can go on forever without any end in sight. It is too open-ended. It requires you to live in an iterative world which creates an overall nervousness as things morph along. That can be too loose for a business application deployment. In the end, we are not developing something from scratch, but rather implementing something that already exists. I think the answer lies somewhere between.
If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
