Alt.NET Seattle -- Subversive Agile

February 28, 2009 · 2 min read

What techniques can you use to get agile practices into a waterfall project/legacy code base?

Approaches

Small greenfield project

  1. smaller, greenfield project
  2. started with source control (moved from Source Safe to Subversion)
  3. once SVN was in place, other tools were able to be used
  4. starting to do CI (TeamCity is free for small teams; can target multiple build mechanisms)
  5. then the door for NANT (or other unit testing) is open; not only does the code compile, but nothing is broken
  6. integration tests can also be automated (different build cycle)
  7. important to pick the right battles

Larger legacy system

  1. subverted a larger system
  2. able to show improved testing, better design, code coverage
  3. bad (badly designed) code suggests bad tests (likely written by the same people)
  4. first step was source control
  5. second step CI build
  6. third step was to move to DI in order to decouple code

Breaking sproc dependencies

  1. use of WCF services is a great way to put a facade around sprocs
  2. the requirement for WCF services to implement contracts allow testability

A different approach is to decompose large specs into smaller features so that developers can work in smaller iteration.

At least three vectors for change: developers, business people, technical. There are different techniques with these. It's important to prove the value of the techniques. The names we use aren't really important.

Keys to success

Using the term "lean" development is more politically acceptable than "agile." Manufacturing is moving to lean processes, and it appears to have some government buy-in. This leads to easier PM buy-in.

We need to focus on the fact that "agile" is really about minimizing risk, and increasing productivity.

The definition of "done" is key -- including communicating that definition to management.

Success really depends on having the right people in the driver seat; it's hard to convince decision makers to take a risk on large, flagship products.

Customers must be the ones dictating priorities. However, as developers, we need to be setting realistic goals and expectations. This may require going back to the business people to negotiate.

Communication is key. The solution is not to block discussions, but instead to increase the level of education and communication.

Establish your technical credibility. Once you do this, you'll have support. Sometimes, you'll need to sell management on the benefits. Couch this discussion as a value proposition for the manager to make them look good.

Patience, young grasshopper.

Resources

This article is part of the GWB Archives. Original Author: Jeff Certain

New on Geeks with Blogs

  • We Won The One Award I Actually Care About

    Full Scale made the Inc. 5000 for the fifth year straight, the 12th listing across my three companies. Here is why the one award you cannot buy is worth stopping for.

  • Your Customers Build the Features Now

    I let a tool I liked sit dead for a year rather than build the features I wanted. An MCP server meant I never had to, and your customers can do the same to your product.

  • Get the Size of a Directory in Linux the Easy Way

    du -sh for the quick answer, ncdu for the cleanup, df for the disk itself: every command for checking directory size in Linux, plus why du and df never agree.

  • Vim Search and Replace: The Ultimate Guide

    One :%s command replaces every match in a file before a find dialog would even open. The Vim substitute patterns worth the muscle memory: flags, ranges, capture groups, and multi-file edits.