InfoQ Interview: Ron Jeffries on Running, Tested Features

Posted by Deborah Hartmann Preuss on Dec 01, 2006

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Planning ,

Artifacts & Tools ,

Customers & Requirements ,

Delivering Value ,

Value & Metrics ,

Software Craftsmanship ,

TDD ,

Tools ,

Project Management ,

Agile2006 ,

Agile ,

Testing

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]

1. Back to top

   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

   Reply

2. Back to top

   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

   Reply

3. Back to top

   Re: link broken

   by Eirik Mangseth

   Deb,
   
   I would guess that he means "Best regards"
   
   Eirik

   Reply

4. Back to top

   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?

   Reply

5. Back to top

   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...

   Reply

6. Back to top

   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

   Reply

7. Back to top

   Re: Agile overload

   by Graham Wright

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

   Reply

8. Back to top

   the title of this video is not accurate

   by oren oren

   it should be 'the basics of Agile Development'

   Reply

9. Back to top

   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

   Reply

10. Back to top

    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

    Reply

11. Back to top

    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

    Reply

12. Back to top

    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.

    Reply

13. Back to top

    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.

    Reply

14. Back to top

    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).

    Reply