TITLE: Helping Developers Feel the Win of Agile Practices AUTHOR: Eugene Wallingford DATE: August 16, 2007 3:51 PM DESC: ----- BODY: Sometimes the best way to help someone learn a new habit is to let him or her feel the action happening, or not happening, in a new way. Sometimes, the action seems more natural when this feeling strikes a new chord. I proposed an example of this approach many posts ago, in an entry called I Feel Good. I Feel Great. I Feel Wonderful. It reported an agile development fantasy I had after watching the Bill Murray flick What About Bob?. In my fantasy, I might use Dr. Leo Marvin's "Death Therapy" in an agile development scenario: Walk in one morning unannounced, and pull the plug on the project. An agile team should have something pretty reasonable to deliver. But would my students stone me before I could exit the room? I managed to catch the beginning of a thread on the XP mailing list for once, a thread titled Your favorite teaching tricks?, launched by William Pietri. Unfortunately, this thread lasted only two messages, but both were valuable. Pietri tells a story that displays one of his tricks for getting developers to write tests:
Friday night, I hung out with a pal who has been learning TDD. He is naturally full of questions, and one exchange went like this: "If I have tested all the low-level methods, I don't need to test the components together, do I?" "Did you run it to see if it worked?" "Sure! I tried a few different options, and carefully looked at the output to be sure it was ok." "If you had to check it, then you weren't sure it worked. Ergo, you should have written a test." "Doh!"
Most developers already test in this way, writing simple little main programs that exercise their code. (Heaven help those who don't do at least this much -- and the people who use their code!) Why not automate that test? It's a small step from a handcrafted main to an xUnit test. And in my experience, that little main grows into an unmanageable mess. The xUnit test can grow gracefully into a suite of tests. (That doesn't mean you can't create an unmanageable mess, but at least we have a good book to help us get things right.) And from writing our post facto tests in xUnit, it's a somewhat larger but still small step to writing the test first. J. B. Rainsberger followed up with a trick of his own, for working with customers:
I have one to help customers describe customer tests. If they seem not to want to do it, or have trouble, then when they ask me to build the feature, I immediately say "Done!" They look puzzled. "You are not." "Sure I am. Done!" "You haven't done anything!" "How do you know?" The next thing out of their mouth is usually something we can easily turn into a customer test.
Very nice. I can't wait for one of my students to pull this on me for one of my underspecified assignments! Rainsberger does warn that this trick works best "only if you have a good personal relationship with the person acting as customer". So perhaps only those students who have developed a relationship of trust with me will want to venture this. Of all the runaway threads on the XP list, this is one that I would like to have seen run longer. I'd love to hear others share some of their tricks at helping developers become more agile, whether in testing, pairing, refactoring, or any other practice. -----