Last night I was the invited speaker at the first meeting of the British Computer Society’s new Chester & North Wales branch. Being a regional group, rather than a specialist group, the membership is very diverse. So my title was Agile Software Development – An Overview. But agile is a huge subject, so what should I cover and where should I focus for an introductory talk?
Last month as I began preparing, I kept running aground. I was expected to deliver a ‘lecture’, which implies a linear pass through the subject via a set of PowerPoint slides. But each time I came back to my slides for another pass, I came up with a different tack that might be appropriate to the imagined audience! Finally I had a brain-wave: ditch the PowerPoint.
Instead, I ran the evening as a planning game – with myself as the development team, the audience as the OnsiteCustomer and the ‘product’ being knowledge transfer. Phran Ryder in the audience acted as Tracker and tried hard to keep me to 15-minute iterations, and John Kewley (who organised the evening and laid on the facilities and tea) helped with collecting inputs and feedback. The first iteration was a RUP-style architectural skeleton, in which I went through half a dozen prepared story cards to quickly cover the very basics. At the end of 15 minutes we counted the cards I had managed to cover, and started a velocity chart.
Then before the next iteration I asked everyone (25 people) to write on a card the single thing they most wanted to find out about agile. John and I then quickly sorted the cards, reasoning that any duplicates had higher business value (because more than one person wanted to know about that topic). And so the content of the second iteration was defined by the customer – much to their surprise! That second 15 minutes consisted of me ad-libbing to the chosen cards, after which we ran acceptance tests by asking the authors of the chosen cards whether the required knowledge had been delivered. Then we updated the velocity chart and continued.
In the end we had 4 iterations, and the entire direction of the evening had been set by the audience. Judging by the comments John and I received afterwards it seems that most people enjoyed the evening. I certainly did, and I will certainly run future events along similar lines. Each iteration seemed to generate more discussion and participation that its predecessor (I guess because the scattered topics were beginning to cohere in the minds of the Customers). And so the fourth iteration seemed to be guided by a much more focused set of stories than before.
This was a fun experiment, and extremely successful. One thing I would do differently though: After each iteration I took questions and got into 5 or 10 minutes of discussion before moving on to prioritising the cards for the next iteration. Next time I’ll simply write the questions on cards, and they will become the stories of the next iteration.
And I’ll be very interested to hear from anyone who has tried a similar structure for agile talks, or who wants to try it in the future.
Update, 19 may 05
In agile speaking Brian Button reports on his experiences with this same approach.