I was exploring the idea of co-teaching with someone I met several years ago. He now teaches at a local university and no longer works in industry. He wants to teach some kind of agile workshop with me.
He said, “I want to teach a thoughtful kind of agile. The kind where you work in timeboxes, but you still have requirements documents and functional design specs before writing any code.”
I replied, “That’s not agile unless the customer is demanding the specs as output. Are they?”
“No. But it’s impossible to do good software development without specs. I have xx years of experience that says so.”
“Your years of experience in a serial lifecycle don’t translate to agile, or even to an iterative or incremental lifecycle. Can you even imagine a project where you don’t need specs?”
“No.”
I tried again. “Have you worked on an agile project?”
“No, I was planning on talking to people who had worked on agile projects to see what it was like.”
I was angry and frustrated at spending time with this person. I declined the opportunity to co-teach. Here’s someone who’s never been on an agile project, who’s never tried another path, who wants to teach “thoughtful” agile–and pass it off as the real thing.
Maybe this isn’t criminal, but it’s darn close.
If you’re looking for agile training, ask the instructor about his or her experience doing, coaching, managing, whatever agile projects. Don’t blindly look for certification or a syllabus you like (although a good syllabus is helpful). Ask about experience. If you’re learning how to pair, how can you learn from someone who hasn’t and doesn’t know the pitfalls? If you’re learning how to use continuous integration or timeboxes, how can you learn from someone who’s never used CI or timeboxes?
I don’t buy the “I can hear about it and teach it” argument; that’s what leads to “People who can, do; people who can’t, teach” maxim.
Thoughtful agile is when you choose an agile lifecycle or set of practices, and follow them to the letter until you succeed. You inspect and adapt as you go. After you’ve succeeded, then, only then, can you change things to make more sense. (Read Ron Jeffries’ article We Tried Baseball and It Didn’t Work.) But you can’t change agile until you know how to make it work. And, if you can’t do agile, have never tried agile, and have no real idea what agile is, you can’t teach it.
Just had to get that off my chest.
P.S. Added the before writing any code to make it clearer what I objected to.
