Agile vs. Waterfall – Avoid the Semantic Debate

Every software development approach has its flaws and its critics. Though at times, it seems like everyone is looking for a panacea — a cure-all or ultimate remedy. Sadly, there is none.

Here are a few criticisms leveled at the major development approaches. All have some validity, especially when the approach is applied improperly (which it usually is).

  • Waterfall – It’s slow. By the time the team delivers the software, the business has already moved on to the next big thing.
  • Scrum – The daily meetings are too stressful. There’s constant pressure and no time to get any real work done.
  • Kanban – It’s too complex. The layout of the Kanban board is impossible to get right.
  • XP – Pair programming is too expensive. Productivity is cut in half and valuable talent is wasted.
  • Lean – This is just another excuse to cut costs. Teams are forced to do more with less.

There is no ultimate approach to building good software systems. There is only incremental and continuous improvement to what you’re already doing. The harder you try to find perfection, the more disappointed you’ll be.

Forget about labels. Agile-this; waterfall-that; who cares? You’ll never win a semantic debate. What matters is how your team and your company go about building software. The approach you’re using probably sucks in more ways than one. Here’s how to change it:

  1. Identify a few key people in the company who care enough to want to improve the current process.
  2. Lay out the current process, as is. Don’t try to fix or improve anything yet. Seek to understand.
  3. Pick two or three problem areas and agree on new ideas and new approaches.
  4. Implement those new approaches and measure the results. Measure, don’t just observe.
  5. Now pull in some other interested parties and do it again — continuously improve.

Lean can help. If the team is performing tasks that add time and effort, but little or no value, eliminate them. Lean is about streamlining work not reducing budgets.

XP can help. A buddy system improves outcomes. Maybe it’s pair programming or maybe it’s peer review. Either way, another pair of eyes on every code module will improve quality.

Kanban can help. Simply lay out the current process on a Kanban-like board — don’t try to create a new process, just lay out what happens now. Adjust the process flow as you learn more about the team dynamics.

Scrum can help. Those daily standups — when done properly — can improve team communications and actually reduce stress. Just remember that standups are not status meetings. They are knowledge-sharing meetings.

Waterfall can help. Some regulated industries and consultant/client situations demand a structured, measured approach. Don’t go overboard. Processes don’t rule. People do.

photo credit: Articulate Matter via photo pin cc

Updated: August 26, 2012 — 10:24 pm