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:
One viewer, who found the video quite useful, commented:
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]
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?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." **
The answer is: Wrong
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]
Community comments
link broken
by anjan bacchu,
Re: link broken
by Deborah (Hartmann) Preuss,
Re: link broken
by Eirik Mangseth,
Agile overload
by deepak shetty,
Re: Agile overload
by David Skelly,
Re: Agile overload
by Graham Wright,
Re: Agile overload
by Graham Wright,
Re: Agile overload
by deepak shetty,
Re: Agile overload
by Jeremy Lemaire,
Re: Agile overload
by Ron Jeffries,
Re: Agile overload
by alistair cockburn,
Re: Agile overload
by Deborah (Hartmann) Preuss,
Re: Agile overload
by Ron Jeffries,
the title of this video is not accurate
by oren oren,
link broken
by anjan bacchu,
Your message is awaiting moderation. Thank you for participating in the discussion.
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) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
Deb,
I would guess that he means "Best regards"
Eirik
Agile overload
by deepak shetty,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
it should be 'the basics of Agile Development'
Re: Agile overload
by Jeremy Lemaire,
Your message is awaiting moderation. Thank you for participating in the discussion.
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) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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).