I've previously mentioned that Diana Larsen and I are teaching two courses in June: The Art of Agile Planning and The Art of Agile Delivery. But I don't think I've mentioned what makes these courses unique. Diana and I share two core beliefs about training: we want to our students to have experiences, not lectures; and whenever possible, we want those to be real-world experiences rather than metaphors or simulations.

Experiences over Lectures

In The Art of Agile Planning, we're helping you understand how to plan Agile projects, both from an iteration/Sprint perspective, and from the larger release/organizational perspective. There are a lot of skills to learn, and one thing we know is that you can't build skills passively. You have to experience the thing being taught--do it--before it really sinks in.

Part of the reason is that "textbook" answers tend to strip out the messy complexity that occurs when you put work into practice. In real-world planning, there's tension and pressure. Different people want different things. There's a fear about what will happen if you don't get everything done by a certain time. Existing interpersonal friction is magnified.

You'll never learn this stuff by hearing a lecture. Most instructors don't even mention it. (Sadly, some teach from books, not experience, and don't know that they don't know it.)

So we do it. We have people practice planning, many times, and we intentionally put real tension and pressure into the mix by making sure the planning outcomes actually matter. Suddenly the stuff that seemed so easy when it was up on the board isn't as easy any more. Mistakes are made. And real learning happens.

Reality over Simulations

Hidden complications explain why we prefer real-world experiences over metaphorical simulations, too. Sure, you can experience aspects of Agile delivery by sketching a mousetrap on a flip chart. You'll learn about cross-functional teamwork, communication challenges, all kinds of good stuff.

But it's nothing compared to the experience of actually delivering working software in a time-boxed iteration. Version control. Flaky computers. Cross-platform compatibility. Strict deadlines. These are all part of reality, and they make the cross-functional teamwork, communication challenges, and so forth even more challenging.

In The Art of Agile Delivery, we do something that I'm exceedingly proud of: we have students define, develop, and deliver a complete software product in several 90-minute iterations. We make it as close to the real world as we possibly can, with things like on-site customers, version control, automated builds, and a third-party deployment environment.

As you can probably guess, it's hard. Everything I see on real software teams is repeated in miniature in that classroom. The last time we taught this course, some teams struggled with getting their computers working. Some tossed out the rigorous practices they had learned and started hacking. And some refused to acknowledge the deadline and scale down their ambitious plans. Nobody delivered software at the end of the first iteration. Nobody.

Sound like chaos? Sound painful? Yes. It was. That's what software development is like. And yet we have to deliver anyway.

And at the end of the second iteration, some teams did. By the fourth iteration, everyone did. Learning happened.

The Firehose

These core beliefs--experiences over lectures and reality over simulations--does mean that we expect a lot from our students. You'll be drinking from the firehose. You have to be willing to make mistakes, and learn from them. It's not for everybody.

We're okay with that. We figure the challenge will attract the kinds of students we want to teach. If that's you, come join us.

Note: This essay refers to courses delivered in 2009. To see our current schedule of courses, please visit my Training page.