Thursday, May 24, 2007

Primary vs. Secondary Agile Development Benefits

Agile is generally talked about as a single package: if you adhere to the principles, you get the benefits. I believe there is another way to look at Agile. Agile introduces a whole new set of practices to the development toolkit. These practices include: product backlog, pair programming, on-site customer, continuous integration, refactoring, test-first development and many others.

While all of these practices have been either associated with or created as a result of Agile, their application and resulting benefits are completely independent of your chosen methodology. Use Scrum or "Waterfall" and you still get the benefit.

For instance, refactoring is a standard feature in Eclipse. Eclipse is an IDE and is completely orthogonal to your methodology. The benefits from these practices are secondary benefits when practicing Agile. In my opinion, the primary benefits of faster turnaround, realizing business value sooner, and quality increases above and beyond the quality increases from the individual practices comes from the single practice of short iterations.

You don't have to do pair programming, use 3x5 cards, collocate, only use small teams, or have a customer on site to get to short iterations. These may help, but they are not the only practices that will. For instance, test driven development is very easy to adopt, contributes greatly to enabling short iterations and does not require any experimentation with personal boundaries.

Let's say you give me the benefit of the doubt and are willing to believe that there are benefits to implementing Agile. Why should you personally spend any time thinking about it?

3 comments:

A key concept of RUP (and most software processes) is to use just what you need. This is related to "method weight". Method weight is heaviest when you use more of a process. Agile processes strive for a low method weight meaning don't use anything unless you need it to succeed.

You can have all the refactoring tools in the world present in your IDE but if you are constantly under business pressure or your manager doesn't consistenyl schedule time for the repayment of technical debt, you won't be able to USE them enough to properly avoid software entropy.

Refactoring tools make it POSSIBLE, but only if you work under an Agile methodology / philosophy at a higher level will the possibility turn into probability and indeed a regular thing.