Extreme Hour

An ExtremeHour is an hour-long presentation in which ExtremeProgramming is demonstrated using a sample project and involving the audience. Basically, the audience gets one hour to completely develop (and test!) a product using ExtremeProgramming principles such as PairProgramming.


We'd been introducing Xp organically. We'd got a few developers pairing, a few stakeholders making UserStories, an automated test framework in use on a project, and a CommitmentSchedule in use on another project. Kent's book has been flying around the place, and so has PeopleWare. A lot of the practices were in place.

But we weren't extreme. The pieces weren't connected. I've had excellent buy-in from upper management, and they wanted to accelerate adoption. The question was, how?

Well of course a series of presentations were planned. Many members of management stood up and gassed on how they saw this working. But the day was long and the seats were hard and it was plain that some of the management misunderstandings were muddying things. What was really missing was a vision of the process in process to tie it all together.

But we saved the day with the final one-hour session, and this was so effective and fun I figure it's worth recording for others to try. These notes slightly bowdlerized from the original power-point at [http://home.san.rr.com/merel/xhour.ppt]:

I think the presentation has moved to [http://www.xpsd.org/xhour.ppt] - SteveDonie

Build A Better Mousetrap

Sixty Minute Project Rules User Stories & Arch. Spike Estimate Priority & Scope Initial Commitment Schedule Iteration 1 Fix Commitment Schedule Iteration 2 Release!


We got through this whole presentation in 80 minutes, including presenter explanations. Of course it skips a lot of details, but it was most compelling to see all the major players going through their paces, and the universal impression was that we were going really fast. Benefits:

-- PeterMerel


Great idea!


Has anyone looked into how this might have to change now that LoadFactor is deprecated and ProjectVelocity preferred?

It seems as if it would be difficult to get enough releases into a presentation to allow delivered stories and committed-to stories per release to converge in any very compelling way. I may be wrong.

Even without that change this is still a superb idea. Kudos to Peter et al.

-- KeithBraithwaite


Peter, this is really something. I attended a day long presentation on XP given by Kent last spring where he did something similar. I'd love to try this. Anyone else in the Bay area interested? -- PhilGoodwin

Upper Management were so pleased with this they've asked me to do it again with some of our product managers next week. We'll pick a different vision for the product, of course. I'm thinking "From The Earth To The Moon" might be fun. -- PeterMerel

Fabulous stuff, Peter! You really must, must write a book or at least a Fortune article. -- KentBeck

I'm awful glad you like my dabbling, Kent, and I'd like to write some of it down as a book, but right now I consider myself lucky to be able to grab enough time to work on the StoneSociety, much less XP. I'll be content if you or any of the other ExtremeProgrammer(s) think enough of this stuff to include it in your practices. -- PM


We did this at an ObjectMentor OffSite and it worked great. The things about software development that we effectively simulated are:


The MarinJava Discussion Group is going to try the ExtremeHour exercise next week. I'm more or less going to be running things. Does anyone have any advice on how to pull one of these things off? -- JohnBrewer

How did that go, John?

I'll report back someday, promise! -- JohnBrewer


I'd really like to try an ExtremeHour in the DC area. Any takers? WashingtonDcExtremeHour


Curiously enough, we didn't do the ExtremeHour exercise at XpImmersionTwo. I seem to recall they did do it at XpImmersionOne. Any idea why the change? -- JohnBrewer


Would the next set of XPers to try this be kind enough to get it on video tape, and sell copies? ;)


We did the Extreme Hour today at our weekly development meeting. We had our marketing director and the QA person on our XP project as Stakeholders and assigned developers and QA to their same roles. We found that the marketing person wrote very fuzzy requirements such as "Build a humane mouse trap". Many of the developers had trouble working with just a single story at a time and wanted to design and develop the trap all at once. The QA people had a hard time sticking to testing the story and would go off and test stuff that wasn't covered in any stories. Many people had trouble working together. Most wanted to do it their way and would often argue about design and implementation details.

People got involved at different levels. Some were really into it and contributing while others just sat and watched. Overall everyone seemed to enjoy it. Now we will see if it translates into more support for XP in our department. -- JohnUrberg & JaimmeYork


I led an ExtremeHour for educators primarily at XpUniverse 2000 in Raleigh, NC in July. My results and some of the documents I used are in my alternate write-up of ExtremeHour at http://csis.pace.edu/~bergin/xp/planninggame.html.

-- JoeBergin

I wonder whether Joe is right in characterizing the ExtremeHour as IckyPoo?. I think it's more an RPG (Role Playing Game) pattern than a kid's game pattern. RPGs have a very different dynamic - effective, but oriented more towards pushing people inside a process than just show-and-tell. -- Pete

The point of an IckyPoo? is that it is very dramatic and unexpected by the students, not that it is derived from a kid's game. -- JoeBergin


We did a "pretty adventuresome" ExtremeHourWithActualProgramming using 90 minutes instead of 60, and with a rehearsal in front of it. The report's a bit long, so I broke it into its own page. -- AlistairCockburn


I don't understand the bit about drawing stuff on the white board. What sort of drawing can be said to "fulfil" a requirement? How does the UnitTest (or should that be FunctionalTest) correspond to that drawing? Is it simply (as in the example of "usable by the blind" above) that the drawing must show a plausible way of satisfying the test? --IainLowe

Yes. --- RobMee introduced me to a refinement - TestDrivenExtremeHour?. Before you start drawing the coffee maker itself, the customers draw the test rig - there will be a coffee cup here, we will push a button there, the coffee will go so high. On a separate sheet laid over the top, the developers draw the coffee maker itself. There is certainly an art to drawing the test rig to constrain only important constraints, like weighing the coffee cup to check for the correct amount of brewed coffee instead of measuring physically.

My emotional reaction when I saw this astonished me. "That's too easy. That's cheating. That's too much work for the customers." In short, exactly the reaction folks have to acceptance testing in advance of implementation. -- KentBeck

A post-Sardinian variant we've been using is for test fixture writing to be done iteratively by developers. Always first, of course - 10 minutes writing tests, 10 minutes drawing solution, etc. But Rob's idea is more in the spirit, and I bless it. -- Pete


See: IronGeek SiliconValleyExtremeHour MarinJavaExtremeHour LondonExtremeHour StockholmExtremeHour TorontoExtremeHour ParisExtremeHour BerlinExtremeHour LouisvilleExtremeHour WashingtonDcExtremeHour ExtremeHourWithPeterMerel EasternWashingtonExtremeHour


EditText of this page (last edited September 7, 2006) or FindPage with title or text search