A prime directive of agile development is to maintain forward progress. In past articles, I've talked about quality metrics that gauge the quality of code and design. While these metrics help guide refactoring efforts that ensure application maintenance remains easy, they don't necessarily allow us to measure our progress. A good way to measure forward progress is through knowing where the development effort stands in relation to the functional features desired by business stakeholders. Running Tested Features is a way to track progress by measuring how many features pass acceptance tests. In this article, I'll introduce the idea of RTF, and present some tools that can be adopted to implement an RTF strategy.

RTF Explained
http://www.xprogramming.com/xpmag/jatRtsMetric.htm
While RTF can be measured at the end of each iteration, RTF can be measured continuously, as well.

Measuring RTF and Iterative Development
RTF is decoupled from iterative development. <NOTE: This links multi-dimensional agile discussion with RTF>Iterations are not timeboxed, they are featureboxed.

RTF, Iterations, and Agility

RTF Tools and Strategies

But measuring progress is not easy. Let's talk about Running Tested Features.
Agile development is often viewed as an extreme form of iterative development, where certain practices are applied that shorten the iterative lifecycle. The shorter the iteration, the more agile a team.
Code quality is a corporate asset. So what exactly is high quality code? How do we generate high quality code?
An iteration is

Multi-Dimensional Agile

Running Tested Features

Measuring RTF
To measure RTF, you must develop a consistent, repeatable automated testing strategy that is frequently executed.

# can adapt to change
# performs well
# is error free
# is as simple as possible
# does what my customer needs

Agile Transition
AGile Infrastructure
Agile Roles

Iterative development is more successful than waterfall.

Iterative development should be multi-dimensional. I mean that functional teams work within their own iterations.

For instance, team 1 is working on a 2 week iteration schedule. Team 2 is working on a three week iteration schedule. At the end of each iteration, teams are delivering software. But delivering to where? They are actually delivering functional software every minute of every day if they are practicing continuous integration. The difference marking the end of an iteration is that they are delivering something that must be measured, and that is running tested features.



An iteration is nothing more than a planning window.
Agile development is like multi-dimensional iterative development. It separates iteration planning from implementation.
http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project%3F

http://wtr.rubyforge.org/
http://www-128.ibm.com/developerworks/java/library/j-cq02286/
http://www-128.ibm.com/developerworks/library/wa-selenium-ajax/

http://eigenclass.org/hiki.rb?rcov#l2
http://blog.zenspider.com/archives/zentest/