TITLE: The Tipping Point for Agile Software Development AUTHOR: Eugene Wallingford DATE: July 14, 2005 6:48 PM DESC: A flash of inspiration for teaching agile software development found a confluence of ideas I've encountered recently. Sometimes, I think the universe tries to help us as best it can. ----- BODY: While out running today, I had one of those flashes of inspiration -- a crystal-clear, wholly-formed thought -- for how I might introduce agile software development in an undergraduate course. In this image, we begin the first day of a course with a software project to implement. The first thing we do is work as a group to decompose the into chunks that the students believe they can implement in one day. No Planning Game jargon; just a bunch of students working with me to design the course project and the programming assignments they will have to do. On another day, we could work on one of the day-long projects, breaking it down further and writing a test for each small piece before we write any code. No TDD or JUnit jargon; just a bunch of folks writing short test programs for code they think they understand how to write. I'm not sure why this flash happened today. I'm not slated to teach agile software development per se for a while. The last time I taught the offers some reason that my mind would seek a new way to open the course. Then, I *talked about* agile development first, and we began to work on agile practices with test-first development first. At the end of the course, I felt as if too few of the students had grokked the idea, at least in part before they never felt motivated to give it a reasonable shot. I don't mean that the students necessarily started with a desire not to get it; rather, they never felt a strong internal desire to endure the pain of changing their habits for building software. And old habits die hard, if at all. This feeling brings to mind something I read a couple of weeks ago:
People don't choose rationally to listen to your message and then have a feeling about it. They choose to listen to your message because they have a feeling about it.
University instructors and industrial trainers should keep this thought close to their minds. The folks at Creating Passionate Users know that it is hard to spark passion in readers or product users when they have no particular feeling for the work. The same is true for many students in a course. I may be able to draw in a few students slowly over time, as things click in their minds, but for most I need to help them want to learn and know and do. This is especially true of helping people to change deeply ingrained habits,such as how they develop software. Then what should I read today but this quote from Malcolm Gladwell's The Tipping Point, over at Agile Advice, presented in just the context of my inspirational moment:
...the content of the message matters, too. And the specific quality that a message needs to be successful is the quality of "stickiness." Is the message - or the food, or the movie, or the product - memorable? Is it so memorable, in fact, that it can create change, that it can spur someone to action?
I need to find and communicate better the stickiness of agile development. My running thought seems closer to agile development's stickiness than what I've done before. If my thoughts were controlled more by my rational side, I would be having flashes of inspiration for teaching my programming languages course this fall. What is the stickiness of functional programming, of Scheme? How can I shape a mindset in my students whereby they feel passion to learn these new ideas and change how they think about programs? Maybe I need to go for another run and cross my fingers. -----