Using Agile Practices to Create an Agile Presentation

What’s the best way to make a presentation on Agile practices? Practice Agile practices.

You could write a presentation “big bang” style, delivering version 1.0 in front of your big audience of 200+ people at Kscope 2011 before anybody has seen it. Of course, if you do it that way, you build a lot of risk into your product. But what else can you do?

You can execute the Agile practices of releasing early and often, allowing the reception of your product to guide its design. Whenever you find an aspect of your product that doesn’t get the enthusiastic reception you had hoped for, you fix it for the next release.

That’s one of the reasons that my release schedule for “My Case for Agile Methods” includes a little online webinar hosted by Red Gate Software next week. My release schedule is actually a lot more complicated than just one little pre-ODTUG webinar:

2011-04-15	Show key conceptual graphics to son (age 13)
2011-04-29	Review #1 of paper with employee #1
2011-05-18	Review #2 of paper with customer
2011-05-14	Review #3 of paper with employee #1
2011-05-18	Review #4 of paper with employee #2
2011-05-26	Review #5 of paper with employee #3
2011-06-01	Submit paper to ODTUG web site
2011-06-02	Review #6 of paper with employee #1
2011-06-06	Review #7 of paper with employee #3
2011-06-10	Submit revised paper to ODTUG web site
2011-06-13	Present “My Case for Agile Methods” to twelve people in an on-site customer meeting
2011-06-22	Present “My Case for Agile Methods” in an online webinar hosted by Red Gate Software
2011-06-27	Present “My Case for Agile Methods” at ODTUG Kscope 2011 in Long Beach, California

(By the way, the vast majority of the work here is done in Pages, not Keynote. I think using a word processor, not an operating system for slide projectors.)

Two Agile practices are key to everything I’ve ever done well: incremental design and rapid iteration. Release early, release often, and incorporate what you learn from real world use back into the product. The magic comes from learning how to choose wisely in two dimensions:

1. Which feature do you include next?
2. To whom do you release next?

The key is to show your work to other people. Yes, there’s tremendous value in practicing a presentation, but practicing without an audience merely reinforces, it doesn’t inform. What you need while you design something is information—specifically, you need the kind of information called feedback. Some of the feedback I receive generates some pretty energetic arguing. I need that to fortify my understanding of my own arguments so that I’ll be more likely to survive a good Q&A session on stage.

To lots of people who have seen teams run projects into the ground using what they call “Agile,” the word “Agile” has become a synonym for sloppy, irresponsible work habits. When you hear me talk about Agile, you’ll hear about practices that are highly disciplined and that actually require a lot of focus, dedication, commitment, practice, and plain old hard work to execute.

Agile, to me, is about injecting discipline into a process that is inevitably rife with unpredictable change.