Agile Speaking

I was asked by the local VB.Net User Group to give a talk on Agile Development. The problem with giving a talk like this is that there are so many possible things to cover in the time allotted. And I never know what kind of background the folks showing up will have.

So, if I explain this in another way, I have a specific time in which my talk has to fit, I have a specific amount of resources to deliver the talk (me!), and my requirements are unclear. This sure sounds like most agile software projects! What I’ve done now twice in a situation like this is to let the talk itself become an example of agility. I walk in with an idea about the subjects I want to cover. For example, last night it was

  • What are Agility and Extreme Programming
  • How do they work
  • What is a programmer’s life like
  • How do we adopt it

When I walk in, I give a short intro talking about how I they are my customers, I am their value-giver (developer), and my goal is to give them the most value for their next hour of time. We discuss how I am going to run the talk as if it is a software project, and we proceed to brainstorm for what questions, or features, I can answer for them in the next hour.

They brainstormed way more questions than I could answer in the time given, so we had a quick conversation about prioritizing based on business value. Then I gave them a quick estimate of about 2 minutes per question and told them that I was breaking the talk up into 10 minute releases or iterations. So we chose our top 5 questions from the first line in the list above, and we started off.

At the end of ten minutes, I  had answered 3 of the questions, which led into a quick discussion of planning and feedback. I told them that I could now promise them 3 questions every 10 minutes, since that’s the progress we had measured, and I had them pick out their next 3 questions to get answered. It turned out I answered 4 questions this iteration, with one being really short and quick in the final minute.

We did one more iteration after that, followed by a wrapup discussion of how the talk was planned and executed and related that back to a software project.

I’ve found that this is a good way for me to give a talk when I’m not sure of my audience. It lets me tailor the talk as we go to exactly what they’d like to hear, and prevents me from giving the wrong talk to the wrong group, which I’ve done before

— bab