Agile Development Is Not All Or Nothing

The transition from chaotic software development to agile has got to be easier than the transition from waterfall to agile. If a team is not following any process — just winging it — adopting a structure, any structure, can only help.

In my experience, people don’t like chaos — complete lack of any process — nor do they like a rigid, tightly-controlled process. Agile software development presents a comfortable middle ground to teams in chaos.

On the other hand, teams that are using the waterfall approach already have some structure. The process may have holes and weak points but at least it offers rules and guidance.

Waterfall teams turn to agile development for one of two reasons:

  1. Too many projects are late, over-budget, and/or buggy. The company needs better results.
  2. The competition is getting products and services to market faster. The software development team needs to pick up the pace.

Often, out of frustration, management decides to try something new and agile is a hot buzzword. The team is likely to feel stressed and likely to be resistant to any new approach.

A better way to go about this might be to introduce agile techniques while still using waterfall. Consider the following approach as an example:

  • Use planning poker to prepare your development estimates. Forget points. When estimating features, modules, tasks, etc., get the team together and compare estimates. Discuss and arrive at consensus. Use the basic concepts of planning poker to get the team used to the idea of generating estimates together.
  • Hold daily 15-minute meetings. Get the team into the habit of making daily commitments and sharing information.
  • Hold retrospectives at the end of each project phase and after major deliverables are achieved. Seek continuous improvement.
  • Have some developers try pair programming and report back to the group on their experiences.

By adopting some agile techniques and getting the team used to the concepts, full-scale agile adoption will be easier and more likely to succeed.

Oh, and please go through with full-scale agile adoption. Things may improve by simply doing what I describe above but you need to commit to following through to get all the benfits agile software development offers.

Updated: December 31, 2010 — 5:09 pm

2 Comments

  1. I have to disagree with your title, one of the main reasons I see where “full-scale agile adoption” in companies fails is that agile is NOT a condiment and by definition can not be a side dish. Agile adoption requires a fundamental shift in thinking and requires a restructuring of your organisation with new management style and empowerment of the “knowledge worker”, otherwise you will be stuck in a cargo cult (or in Jeff Sutherland’s terminology a Scrumbut) that won’t deliver. Even worse, companies who try out some agile methodologies say it didn’t work and fall back to the old habits… without ever been truly agile. Another important reason where agile adoption fails is the sabotage of the traditional project management. I guess what we see is an ongoing battle between Frederick Winslow Taylor’s vs W. Edwards Deming’s… it’s Command and Control thinking of early mass production vs Collaboration and Empowerment thinking of the new agile/lean community. I can understand that you want to take away the initial fear of changing to something new and search for ways to ease the difficult adoption phase. Perhaps an agile pilot project in your organisation would be a good start? There is definitely a long transition phase between traditional waterfall and being truly agile, so in that sense agile adoption is not all or nothing. 🙂

    This raises the question how does a team/organisation knows when they are truly agile? My answer would be by bringing in external knowledge (specialised agile consultants) or by measuring it, e.g. http://www.piratson.se/archive/Agile_Karlskrona_Test.html

    Hope this gave some ideas and many greetings from an agilist in Sweden. 🙂

    1. I see your point. There is a difficult problem here. If you abandon waterfall and wholly embrace agile, you run the risk of not getting it right and failing in your efforts. Conversely, if you try to blend waterfall and agile in an effort to ease the transition, you run the risk of inventing a new approach that is missing key elements of the originals. I agree that coaching, not just training, can help.

      Thanks for your comments!

Comments are closed.