Since the early 90s organizations have searched for ways to accelerate the development and implementation of new business systems. As it turns out, the ability for organizations to rapidly respond to changes in the marketplace, regulatory environment and demand of the customers is a critical competitive advantage. Over the last few years organizations have been experimenting with a new methodology that is thought to provide time savings when it comes to business systems development and implementation. Perhaps the most common methodology being considered is Agile. Agile refers to an approach for software development rather than just a methodology. It is a member of the same class o methodologies as Lean, RUP and Extreme Programming (XP).
Using an agile methodology is not for everyone. Many professionals claim that the Agile approach can't be used on large projects. That has not been my experience or the experience of others I have questioned. If you are considering Agile, you should find a suitable project to try it. You should start small with a low risk project and gradually grow to larger more complex efforts. Pick the right project team and recruit participants who are open to learning and trying something new. Keep in mind, you need to properly set and manage expectations for your first Agile project. Be very careful the hype surrounding Agile does not get out ahead of you and establish expectations that you cannot meet.
Methodology vs. Mythology
Agile is not an all seeing, all knowing approach to systems development. Nor does using Agile ensure success. It is a tool for you to use when the circumstances are correct. Just as you do not use a hammer to drive a screw, you pick and choose your approach based on risks and resources. The fundamental construct of Agile is that rather than spending a substantial amount of time and effort documenting, designing and planning what you're going to do, you get right down to actually doing it as quickly as possible. Some use the phrase "learn to fail fast" which has some real interesting reactions with upper management. Not everything will work; at which point you need to discard what didn't work in the last
iteration, learn from it and move on. The key success factor is the open and honest communication that supports the learning process. I would recommend the phrase "provide value fast" which plays much better
throughout all levels of the organization.
One example we all can learn from is an Agile project that addressed a core piece of infrastructure for organizations in the financial services sector. I was brought in because the project was extremely late and in danger of being cancelled. What drove the project to this sad state was careless, unthinking behavior justified because it was Agile. Only two people of the project team had been trained on or had experience with the Agile methodology. The project manager was using a tradition approach and force-fit-it on the Agile methods.
Here are a few helpful hints that address the most common issues organizations have when they begin to use Agile in their development efforts.
- Agile is not an excuse to drop or short-cut critical elements of the development process. In several Agile projects that have gotten in trouble, I have asked about documented requirements, test coverage matrixes, and acceptance criteria only to be told that it not part of the Agile methodology. Wrong! These are required and the Agile approach accelerates these efforts and does not eliminate them.
- Mixing Agile development methodologies is asking for trouble. In one organization they did not select on the Agile approach. Rather, they used multiple Agile methodologies that were selected by the contract consulting staff they brought in. This increases risks, causes confusion and increases the development time due to differences between the individual development groups.
- The most important thing is for you to identify a few professionals experienced in the selected Agile methodology to help you learn. If you don't have skilled Agile practitioners on the team, you are going to find it very difficult to be successful. You should also invest some time in training the entire project team on a common Agile methodology. Get everyone on the same page and use the trainers as player-coaches in your development efforts. Think of it