TITLE: On Introducing Agile Methods to Programmers AUTHOR: Eugene Wallingford DATE: April 08, 2005 5:45 PM DESC: Reading an article on advice an industry trainer gives new clients got me to thinking again about how to introduce agile methods to novice programmers. ----- BODY: After teaching Agile Software Development to university juniors and seniors last semester for the second time, and introducing test-driven design early in CS II this semester, I am coming to a deeper appreciation for how much agile methods require a change in deeply-rooted habits. It is easy for a person who have already developed a new habit (read: me) to walk into classroom and make assumptions about what will motivate students to change their habits. It doesn't take long before new practices become uncomfortable enough that a learner prefers to drop back to what she knows best. In CS II, students soon bump into objects that are hard for them to test, file processors and GUIs among them. And, as Bill Caputo points out, the benefits of TDD don't just happen, "you have to want to find a way to structure the code so that it can be tested without resorting to resources beyond the test." That can be hard for any programmer learning to do TDD, and it's harder for students who are still learning how to program at all. I've been thinking been thinking about how to introduce these new ideas more effectively in the classroom. We university educators have something to learn from industry trainers who introduce agile methods to their clients. Brian Marick's recent article describes advice he gives to clients who ask him for help. Some of the details don't apply to my usual situation, such as "read Michael Feathers' wonderful Working Effectively with Legacy Code". Not that the book isn't wonderful -- it is! It's just that my students aren't usually ready for this book yet. But the more general advice -- work on developing habits deliberately, focus on test writing before refactoring, encourage collective learning and sharing -- can help me. I need to find ways to implement this advice in my context. I suppose that my experience as an agile methods actor tells me that I have something to learn from this book, too. But my students aren't always fearless, and neither am I. -----