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

• Agile Product Design blog
• David Anderson's "Agile 08" speech
• The Toyota Product Development System