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