Louisville Extreme Hour

At Mission Data, we advertised an ExtremeHour presentation during January, 2002 in the Louisville area, and ended up with an audience of 54. The audience consisted of developers, testers, and managers, which is the mix we were hoping for. We tried hard to stress during the sales process that this seminar was not just for developers.

For those in the audience that were not familiar with XP, we started the seminar with a 45 minute Introduction to XP. After that we provided an overview of what we were going to do in the ExtremeHour. We then drafted 7 volunteers from the audience. We decided not to select the 2 QA people at the start, because during our rehearsals it was not clear what to do with them during the first 30 minutes, so we did not recruit them just yet.

Also, we stuck with the mousetrap product because our rehearsals went so poorly. Because of this uncertainty, we decided to do the mousetrap again because at least we had experience of what worked, and what seemed to take us offtrack.

Props, tools, and co-workers

We used two of our employees as presenters/coaches, one as a secretary, one as a secret story-copier, another to help the story-writers, and a couple of others to try to keep the audience engaged in what we were doing.

We used a large auditorium at the University of Louisville for the presentation, which had a stage in the front-center of the audience. We placed one easel pad to the left of the stage, and one to the right of the stage. We also had 5x8 index cards, color-coded markers, and colored dots to place on each 5x8 card. Explanation for their use is discussed below.

First 10 Minutes - User Stories & Spike

The first ten minutes went as planned. The 2 Stakeholders created their stories, and the Developers worked on the ArchitecturalSpike. Based on our rehearsal, we decided to plant an extra easel pad in the vicinity of the developers, to see if they would pick up on the clue that additional drawing pads could be used. They did not notice the extra pad, so we let it go at this time. We thought we might use it later if we wanted to break the Developers into two groups of two, instead of one group of four.

During this process we also had coaches from our company assist the Stakeholder and Developer teams. We generally did not try to direct any ideas the audience members had, but just tried to make sure that they understood the concepts of Stories and Spikes.

As the stories were created, we also had one member of our company write a copy of each story on a 5x8 index card, and another member of our company type the stories into a document projected on a large screen for the audience. The audience could not see the person writing the stories on the 5x8 index cards, because we did not want to scare the audience into thinking that XP had something to do with a lot of documentation copying.

At this point you have to remember that we still had 47 people in the audience. To try to help them stay in the action, we encouraged them to walk around, come down to the stage and offer ideas, and I also served as a part-time narrator for the audience. We also had two of our people walk through the audience and try to explain what was happening on the stage. We wanted to create an environment like IronChef or JunkyardWars. As a part-time narrator I did not succeed very well, and this goes as a lesson learned.

Second Ten Minutes - Estimate Priority & Scope

Before this round, we took 1-2 minutes to update the audience on what happened, and tell them what was about to happen.

The Stakeholders sorted their stories using the easel pad. We used red, green, and blue markers to indicate Must Have, Costly to Lose, and Nice to Have. In the meantime the Developers used copies of the stories that were on 5x8 index cards to create their estimates.

Everything went well, and we again tried to keep the audience involved.

Third Ten Minutes - Initial Commitment Schedule

At the start of the round we color-coded with 5x8 index cards with red, green, and blue press-on dots. LoadFactor was explained again, and this round actually went very smoothly, and we finished a few minutes ahead of schedule.

We also had one of our people type and sort the stories using a PC on-stage. The PC screen was projected onto a large screen the audience could see, so they had a good idea of what the stories were, how they were sorted into three piles, and how they were sorted again within each pile.

Fourth Ten Minutes - Iteration 1

Before this round began we gave the usual explanation of what just happened and what was about to happen. We also drafted our 2 QA people, because there was now work for them to do.

The QA people took over the Stakeholder easel pad, while the Developers went to work drawing. I also took the Stakeholders aside and explained to them that their role was to come up with new stories. We quietly explained this to some of the audience members, and asked them to contribute new stories.

After the ten minutes was up in this round, we brought QA and the Developers together. We explained that we were adding another 5 minutes to the audience for testing. This brought interesting dynamics together, where we now had six people together who did not know each other.

The Developers actually ended up right-on with a LoadFactor of 3 ... until QA failed one of their tests. This shot the LoadFactor up to 6, because it was a big failure.

At this time we were also rushed because we were running out of time. We planned the seminar for 2.5 hours, but we started late, and the Intro to XP went a little long, and the explanations between each ten minutes was eating up the time.

Fifth Ten Minutes - Fix Commitment Schedule

We hurried through this segment in about seven minutes, explained to the audience how the LoadFactor affected the new estimates and the work that could be accomplished. We also explained that we were running out of time, and that we would not finish the last ten minutes, i.e., Iteration 2.

We finished by thanking our volunteers and gave them gift certificates to a local bookstore. We then asked the audience what they felt like they had learned from this exercise. We talked about things like estimating, the feedback loop, bad stories, difficult tests, and how the evil stakeholders came up with new stories and changed their minds on old stories, and what impact this had on the overall effort.

Lessons Learned

If we ever do this with an audience of this size again, we've learned that we definitely want to have a dedicated narrator (or two) to continuously explain to the audience what was happening. The idea of part-time narrator and part-time coach did not work very well.

Rehearsal was a key. There was no way we could have done this seminar without going through the process several times before.

We're still uncomfortable with what to do with the QA people during the first 30 minutes, and why QA and the Developers should be kept away from each other during the Iterations. The next time we do this we think we are going to let QA and the Developers work together during Iteration 1 and see how this works.

Following this seminar we have been invited to do a repeat of the seminar for four different customers who would like to share the event with their co-workers. So while I am not happy with my own performance during our ExtremeHour, it seems to have gone well enough that we can now share the XP experience with more customers, which of course we hope is a very good thing for XP in our area.

Finally, many thanks to PeterMerel for this great idea!