The Search for the Agile Grail

 PDF Print E-mail
Written by Kevin Coleman   
Monday, 09 June 2008 11:19
june08grailbigSince 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.
  1. 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.
  2. 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.
  3. 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 as an Agile "Bootcamp."
  4. Choose your Agile team carefully.  If the people you choose to be involved aren't interested in or prepared for the intense collaboration that Agile demands, the likelihood of success is very limited and it is going to be a big struggle.  You need to construct project teams with motivated individuals.  Address the nay sayers by demonstrating early successes.
  5. The primary objective of any project is to satisfy the business and customer needs through early and continuous delivery of systems functionality.  This remains the case in Agile efforts.  To do this, business people and technologists must work close, collaborative effort throughout the project.  This is not a collaborative workshop and then you break out and get back together a week or more later.
Conclusion
Is Agile for you?  You never know for sure unless you try it. Celebrate your successes and learn from your failures.  It is a process moving from a traditional methodology to an Agile method not an event.  Invest in training, coaching, hand-holding and knowledge transfer.  You need to beware of the "pocket veto," recognize it and deal with it as early on in the project as possible.  Many people resist change and while on the surface they may appear to support Agile, behind closed doors that can be influential saboteurs.  Some people love to learn and try new things, while other finds it nerve racking.  Keep in mind those who know and understand Agile are the benefactors and those who don't feel their value to the organization has been diminished.  Agile is difficult and risky but so is just about everything else.  There is no checklist anyone can give you that will guarantee success.

About the Author
Kevin Coleman is a Certified Management Consultant that specializes in driving strategic value through the creative application of technology. He is a fifteen year industry veteran hailing from consulting institutions such as Deloitte & Touche, Computer Sciences Corporation and Netscape.  He is a strategic advisor to multiple organizations consulting on
accelerating the value of technology as well as managing strategic initiatives for senior management.  He has contributed two chapters to the Encyclopedia of Computer Science and Technology and published over a dozen articles.

Comments (0)Add Comment


Write comment

feedShow/hide comment form
smaller | bigger

security code
Write the displayed characters


busy
< Prev   Next >
 

Agile Marketplace - Announcements and Special Offers

Complimentary Webinar w Forrester Analysts on Agile and Lean ALM
Complimentary webinar with Forrester Analysts Jeffrey Hammond and Dave West. Learn about Lean ALM Development, optimizing processes, cutting costs and compliance by design.
Read More

Agile CMMI – The Best of Both Worlds
Shares how a leading financial institution gains CMMI level 3 compliance and supports Agile practices.
Register for CollabNet webinar May 21

Requirements-based testing (RBT) can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage. Download the Requirements-Based Testing whitepaper