InfoQ Interview: Ron Jeffries on Running, Tested Features

by Deborah Hartmann Preuss on Dec 01, 2006 |

Ron Jeffries, well-known independent consultant in XP and Agile methods, has been developing software longer than most people have been alive. Ron was the on-site coach for the original XP project, authored Extreme Programming Adventures in C#, and co-authored Extreme Programming Installed, and collaborated on and taught Object Mentor's popular XP Immersion course. He's had more time than most to observe the patterns underlying Agility... and he thinks that "Running, Tested Features" may just be the key to software agility. In fact, he suggests that tracking "RTF" is the essential element of Agility, from which all other practices and activities necessarily follow. Not content to sit and chat, in this InfoQ interview recorded at Agile2006, Jeffries took to the whiteboard to illustrate the value that a team's customers gain from this simple metric.

It's not a new idea, in fact, Alistair Cockburn riffed on Ron's theme in "Are iterations hazardous to your project?" Surprisingly, that article starts out with:

Iterations, user stories, and velocity are the very heart of agile development, are they not? If you have those three items in place, then you are by definition doing agile, and on your way to project success. Right?

The answer is: Wrong

Cockburn went on to talk about "Agile Machismo" (hint: it's not a good thing :-) and then came around to his point of agreement with Jeffries: "The center of agile development is to deliver running, tested features to users and collect feedback." **

One viewer, who found the video quite useful, commented:

...he explains that the fundamental value of agile is that you it produces information that managers can use to make better decisions, rather than resorting to hitting the programmers with sticks and holding their feet to the fire.

(this latter, Jeffries noted, has not been observed to work very well.)

Like many Agile practices: "Running, Tested Features" may be simple, "but it ain't easy" - in this case Jeffries noted that while TDD is an obvious essential for RTF, a less visible but equally essential practice for realising the benefits offered by RTF is what XP calls "Simple Design." Without this, design debt accrues and the pace of work degrades. View the interview for an animated introduction to Jeffries' vision for serious Agility.

Related news: Presentation: Ken Schwaber on Code Quality as a Corporate Asset.

** Correction 2007-02-14: We mistakenly suggested that Ron's idea might be derived from Alistair's post. In fact, going full circle, Alistair had in turn referenced Ron's original 2004 "Running Tested Features" article, called A Metric Leading to Agility. This has now been corrected, above. Apologies for the confusion! [Deb]

Related Editorial

Infographic: Just How Big is the Nerd Economy

Five Key Practices to Agile ALM

Application Performance Management Buyer's Guide

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

link broken by anjan bacchu Posted

Re: link broken by Deborah Hartmann Posted

Re: link broken by Eirik Mangseth Posted

Agile overload by deepak shetty Posted

Re: Agile overload by David Skelly Posted

Re: Agile overload by Graham Wright Posted

Re: Agile overload by deepak shetty Posted

Re: Agile overload by Jeremy Lemaire Posted

Re: Agile overload by Ron Jeffries Posted

Re: Agile overload by alistair cockburn Posted

Re: Agile overload by Deborah Hartmann Posted

Re: Agile overload by Ron Jeffries Posted

the title of this video is not accurate by oren oren Posted

link broken by anjan bacchu

hi there,

the link "http://www.xprogramming.com/Blog/Page.aspx?display=RunningTestedFeatures" is broken. In fact, if you click on a link that you got on the above URL, you get a stack dump -- which is not good for the site's security!

BR,
~A

Re: link broken by Deborah Hartmann

Hi Anjan - thanks for your note. Yes, as it turns out, Ron's site was down part of yesterday, a rare occurrence and unfortunate timing. It's back up now.

Question: what does BR stand for at the end of your note? :-)
deb

Re: link broken by Eirik Mangseth

Deb,

I would guess that he means "Best regards"

Eirik

Agile overload by deepak shetty

do all the agile consultants keep coming up with new ways to say the same thing , introducing new terms and abbreviations for the same matter?

Re: Agile overload by David Skelly

do all the agile consultants keep coming up with new ways to say the same thing , introducing new terms and abbreviations for the same matter?

It's not just agile consultants that do this. That is how consultants keep themselves in business and how the whole consultancy wagon keeps on rolling. If you explain things too well, people will start to understand what you are telling them. And once they understand what you're saying, why would they need a consultant any more? So the key is to watch your audience carefully, and as soon as it looks like they're beginning to catch on, hey presto, you change the words you're using. Iterative development is key... no, wait, agile development is key... no, wait, test-driven development is key... no, wait, running tested features are key...

Re: Agile overload by Graham Wright

Having watched Ron's video I think its a major restatement of what's really important in Agile rather then just some renaming exercise. For me it really made me focus on the essence of the problem of delivering software that are user's actually want and on time.
I am looking forward to the book.
Good practice always evolves and sometimes that means refining the terminology and emphais

Re: Agile overload by Graham Wright

that should be "delivering software that our user's actually want and on time."
:-)

the title of this video is not accurate by oren oren

it should be 'the basics of Agile Development'

Re: Agile overload by Jeremy Lemaire

It seems more and more like selling mineral water. All you have is just water, but the only way to increase your sales is with marketing.
Everybody seems to have forgotten DSDM which has been invented a long time ago. The name was simply not as sexy as XP

Re: Agile overload by Deborah Hartmann

I must claim responsibility for the RTF acronym... I figured if I was tired of typing it, you'd probably be tired of reading it. This is the same thing I do with TDD, SOA, etc. Ron never uses that acronym, afaik.
deb

Re: Agile overload by deepak shetty

delivering software that our user's actually want and on time. -Very Important and just as obvious right ? (you missed out works fast but i think someone's said u can only have 2 out of three :-) )
I guess these guys themselves forget the first rule Individuals and interactions over processes and tools preferring to argue over the length of iterations or whether its better to call it a planning window, or the ways to manage agile projects, or tdd or junit or whatever.
deepak

Re: Agile overload by Ron Jeffries

Yes, I spend much of my time coming up with new ways to express the same old ideas. I do that because not everyone understands the ideas yet, and a new way of expressing them will perhaps be helpful to someone who's still wondering what this is all about.

In the case of this particular expression, it focuses on some things that I think have to a degree been missed in Agile: that it is the responsibility of the business-side people to guide the project, that it is quite possible to make deadlines using Agile, and that there are some behind-the-scenes activities, like design improvement and testing, that are essential to the project.

Do I do it because I might get more business? No, not really, because I'm busy enough as it is. I do it because I care to express myself well, and because I would like for people to understand Agile well enough to make good decisions about whether, and how, to do it.

Re: Agile overload by Ron Jeffries

Jeremy, while DSDM has been around a long time, and may be a very valuable process, it is nothing at all like XP. As a side comment, as nearly as I can tell, Kent Beck wishes he had not used that name anyway.

Re: Agile overload by alistair cockburn

Watching the video, my observation is that Ron manages to say in a very clear and simple way what many people have been trying to say (and not succeeding in being clear and simple) for a long time. If you think it is easy to do that, try explaining to a resisting mind why incremental development is useful. The idea isn't new (it has been documented as a best practice since the mid-1980s), finding ever-simpler ways to express it is.

Personally, I found the idea of bugs as negative features to be an interesting mapping, and will play with that idea to see if it communicates anything useful to resisting ears (it doesn't reduce bugs in the software, but it may get people to pay attention to them differently).