This post is all about IT. There is no doubt that IT can have a tremendous impact on business, but if IT stuff makes your eyes glass over, might be best to select a different post.
“Waterfall” has been and is still the primary methodology for IT development. It consists of a series of phases (eg. Strategy, Requirements, Design, Development, Testing) that are each completed in serial in order to reach a release. The next phase in the series is not started until the previous one has completed and been “accepted”.
Agile (in a nutshell) is an alternative that seeks to mash all the phases together and iterate through smaller blocks of functionality
Agile has been around since the mid-90’s. Even with Google leading the charge with the concept of perpetually improving beta, we have not yet seen Agile take over as the de-facto standard. If you ask the bulk of consultants at large IT shops like IBM or Accenture, they will tell you that they are primarily still using a waterfall methodology. There are a few conclusions that may be drawn:
- Agile is mis-used
- Agile is inferior to waterfall
- It is difficult to transition from waterfall to agile
re: #1. I have come across MANY people who say they are using Agile methodology, when in fact they are involved in chaos with no clear direction. Projects like this give the methodology a bad name. Just because you are not building huge requirements documents does not mean you are “Agile”. It just means you are not “Waterfall”.
re: #2. I have also come across many IT professionals whom I respect greatly that sing the praises of “Agile” and confirm that their teams are far more effective with that methodology. That is just proof by example, but likely you can point to similar examples?
re: #3. I think that adoption difficulties are the crux of the issue. Agile sounds simple at its core, but to really get it right, requires a lot of attention, a lot of focus, and complete buy-in from the entire team that they are going to interact in different ways than they ever have before. They have to be willing to open the kimono and let everyone see their issues at all times. This is a change management challenge. Teams need to be willing to improve upon the process with each new project and not give up along the journey.
What experiences have you had with Agile? Why has it not seen wider/faster adoption?
This post was inspired by a phone call that I had with Shaheen Hossain. He is an Agile/XP coach and a scrum master.
Some resources you might find useful
- A 68 slide deck on “Responsibilities and Challenges of the Agile Product Owner”
- A paper on “Usability investigations for Agile user centered designs”
- A very comprehensive blog post on “Agile Development is more Culture than Process”