Extreme Hour

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]:

Build A Better Mousetrap

• Our new product must dominate the corporate sector of the well established mousetrap market.
• Plan, schedule, develop and quality assure our initial release.
• Project timeframe: One Hour!

• 10 Minutes User Stories & Arch. Spike
• 10 Minutes estimate Priority & Scope
• 10 Minutes init Commitment Schedule
• 10 Minutes Iteration 1
• 10 Minutes fix Commitment Schedule
• 10 Minutes Iteration 2
• Release!
  • Note Timeframes Not To Scale

• If It Ain't Drawn On A Whiteboard, It Ain't Delivered.
  • This is to say, the developers draw pictures of deliverables, rather than code them. Think of pictionary, but without the visual puns. Well, unless they're really good visual puns.
• If It Ain't Written On A Napkin, It Ain't UserStory/FunctionalTest(ed).
  • Stakeholders wrote single sentence UserStory(s) on a whiteboard, though napkins would do. QA wrote their functional tests on napkins. For example, we had one UserStory "must be usable by the blind". This led to a good debate on ambiguous requirements - blind mice? For a QA example, we had a corresponding test: "We blindfold Mark. Can he figure out whether the trap is full without getting hurt?"
• Presenter plays Coach
• 9 Project Members from the Audience:
  • 1 Tracker (TrackerRole) with stopwatch and SCM notepad.
    • The SCM notepad notes sketches that the developers erase. For example, "A Cat". If the developers need to bring the cat back, they can just write "A Cat" and SCM verifies that they had already drawn one.
  • 4 Developers
  • 2 QA
  • 2 Stakeholders
• QA can't see what developers draw till end of 10 minutes.
• Developers don't know what QA or Stakeholders write until end of 10 minutes.
  • The two groups literally can't see each others work until an iteration ends.
• Tracker gives 5 minute and last minute warnings.

• 2 Stakeholders write User Stories.
  • Don't forget to quantify relevant qualities!
• 2 Developers draw Architectural Spike.
  • Don't forget to prototype the build environment!
• While this is going on encourage everyone else to walk around and suggest things. Be careful to point out the effect of this on flow.

• Stakeholders sort Stories into 3 piles:
  • Must Have
  • Costly To Lose
  • Nice To Have
• Stakeholders rank relative priorities within each pile.
• Meanwhile 4 Developers assign Ideal Minute costs to Stories based on Spike experience
  • Use max story size 10 ideal minutes, or else make Stakeholders split/clarify.
  • Optimism wins. But Note Risks.

• Schedule stories into 2 Iterations.
• Schedule priority & risk first.
• Use Initial Load Factor 3
  • This means there are 4 x 10 = 40 Real minutes; 40/3 = 13 Ideal Minutes per Iteration using initial load factor.

• QA writes down Functional Tests for each Story
• QA can't see what developers draw until end of Iteration.
• Then QA "runs" tests, notes bugs.
  • Any story with bugs is incomplete and affects subsequent Load Factor.

• Meanwhile Developers define engineering tasks.
  • This is to say, the developers talk about things that have to be drawn to enable them to satisfy the user stories. Generally they seemed to plan for about 10 seconds before drawing.
• Developers draw solutions
• If other developers can't understand a drawing, it fails unit test.
• Developers should refactor where they can
• Tracker notes any deletions

• Stakeholders secretly think up new stories, the evil bastards.

• Tracker or coach measures real load factor and modifies ideal minute size of second iteration
  • Presenter, practice beforehand so you can do this quickly! Use Load Factor = 40 Real Minutes / Ideal Minutes of stories that passed QA in first iteration (9 in our example => Load factor 40/9 = 4.4); Ideal Minutes for the second Iteration then = Real Minutes / Load Factor ( 40 /4.4 => 9 in our example )
    • Hrm. Actually I was silly here. Of course if they got through 9 ideal minutes in the first iteration then that's the size of the second iteration. Unless they decide to include more developers, in which case you need that LoadFactor calculation after all.
  • Note... using simple velocity instead of load factor should make this much simpler/easier
• Turn QA bugs into Stories
• Reveal Stakeholders' new Stories
• Prioritize & Scope all Stories
• Fit Stories into Schedule, possibly replacing previous ones
• Can we use more Developers? Or will that make LoadFactor rise?
• Do ergonomics affect Load Factor?

• QA writes down Functional Tests for each Story
• QA can't see what developers draw until end of Iteration.
• Then QA "runs" tests, notes bugs.

• Meanwhile Developers define engineering tasks
• Developers draw solutions.
• If other developers can't understand a drawing, it fails unit test
• Developers should refactor where they can
• Tracker notes any deletions (SCM)

• Stakeholders secretly think up new stories, the evil bastards.

• Stakeholders determine if this is an external release - is it marketable?
• If you're not exhausted, reschedule stories that didn't make it in this 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:

• the whole organization has a mental SpikeSolution of the way things coordinate
• there's real excitement and forethought about working this way.
• LoadFactor flew up to 4 for the second iteration. Everyone instantly understood it.
• it was easy to see how quality improved over multiple iterations
• it was easy to see how responsive this is to change
• it was easy for people to see where they fit in the process
• it was easy for people to see this is fun. Actually it was a lot like watching an episode of IronChef

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

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 customer wrote fuzzy stories and had to make them concrete before they could be estimated
• The customer was frustrated at just how little functionality got done, but it was still enough
• The functional test found defects (a roach going in the little one way mouse door bumped the mouse counter)
• The customer came up with new requirements during iterations
• The programmers refactored their mousetrap to also accommodate roaches

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

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

-- 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

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

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006