Extreme Hour With Actual Programming

Just for drama, excitement, and living on the edge, and because I think a ProcessMiniature is really important, we did a 90-minute variation of ExtremeHour for my non-XP methodology at a new company. You should get, right away, that any methodology I cook up is going to be more complicated than XP, so already the 1-hour limit is at risk. To make it more interesting (you should soon become suspicious about my use of the word 'interesting'), we all decided not to use overhead transparencies and mouse traps, but to build a real, live, 5-layer Gemstone J / CORBA / Java servlet / XML UI / Sax stylesheet, application in front of the entire company in two 30-minute iterations, complete with regression unit tests and httpUnit-like regression servlet and application acceptance tests, with three programmers.

In the first 5 minutes, I outlined to the assembled crowd what was going to happen. Then the "business owner" put in a request to the three programmers to please build a simple up/down counter that would stick at 20 and 0, reset to 0, and which had a radial dial and rotating needle to show the number.

The programmers respectfully declined, saying they would need 2 months for the radial dial (actually we had rehearsed this part. On the first rehearsal, they nearly threw a chair at the business owner; the UI designer sat dumbfounded for several minutes, unable to speak (even though I put the business owner up to the request). On the real performance, the programmers played their parts properly, but the marketing people in the audience shouted to the business owner to "negotiate harder". more on this, later). They negotiated down to a simple number as the display instead of a dial.

They did a ProjectPlanningJamSession to set the tasks, timings and dependencies. The total predicted time was for 30 minutes elapsed time. I carefully arranged for them to bid "up"-only first and separately from all the other functions. This took about another 5 minutes.

They did the coding, saying whenever they were done with a piece ("Gemstone-J done, IDL done, UI design done, etc.") (actually, I had to walk over and watch what they were doing and goad them into saying that they were done with something - beware methodologists embellishing to create better sales for their wares ;-) and we wrote the actuals on the cards. Had a couple of people from the audience help with JUnit and httpUnit as needed to get them done fast enough. We projected all three programmers' output on the wall so everyone could see. After about 5 minutes, few people were watching the programmers' output any more - it was an exercise in excrutiating boredom to sit and watch screenfuls of code get thrown onto the wall. But that was also useful for the business people to see. The owner said, "I never imagined it took that much text to program a counter."

After 20 minutes, we (as rehearsed) de-scoped to only up-counting, and the team delivered the up-only function and screen in exactly 30 minutes, fully tested.

Iteration 2. Marketing people in the audience asked for complete reversal of the screen layout. The UI designer bid 40 minutes to do that, so marketing accepted the original layout :-). The team went really fast, and did all except servlet testing in about 15 minutes. But the servlet testing got stuck, kept coming up with the wrong answer.

I asked if management wanted it now, or wanted it tested, and they yelled "Tested." So programmers kept on it, and in the end they barely got it completed at the end of 30 minutes. So double the original times, but the second iteration was in general much faster than originally bid.

Crowd was immensely bored and I needed to keep them entertained with commentary about the dynamics of the team ("What you just saw was the important act of cutting scope to meet the iteration timeframe...") , and of the room dynamics in general ("Please be quiet, you're distracting the programmers. Yes, delivering a cup of coffee to the Gemstone programmer would be an excellent thing for the project manager to do at this time. ... You people may not leave the room - if the programmers can't leave, you can't leave, this is a full team exercise: their job is to type; your job is to watch."). All but the most bored marketing people did actually appreciate seeing 800 lines of server code, IDL, servlet and XML code needed to put this simple application live.

It was hard work for the programmers, but (a) they did get it done and felt good with the accomplishment, (b) they did develop some better communication and team jell out of the exercise, (c) the entire company got to see what it took to program one of these business web apps, (d) we got to drag everyone in the company through most of the process, in particular delivering small slices tested rather than large slices untested, (e) I got to coach several of the roles in the company on allowed negotiation techniques inside the planning game, and in particular, on de-scoping.

This was, in particular, the first time that any of them had produced unit tests for their code in any real sense, and the first use of the httpUnit-like servlet testing framework. It was the first time they had delivered a ultra-thin slice of functionality on time instead of delaying the delivery. It was the first time the company had met the rules of engagement in the ProjectPlanningJamSession (same basic rules as in the PlanningGame), and the business people learned they had to trust the programmer's estimates even if they really didn't like them!. So there was a learning to be had for all, programmers and business viewers alike.

This is a tough version of ExtremeHour, and not to be sprung on people by surprise. But the people involved appreciated it much more than seeing cartoon mylar designs being shaken on an overhead project ("bubbles don't break"). Let me know if any of you try it -- AlistairCockburn

It's official Alistair, you're insane. I would have loved to see this. -- JasonYip

Alistair, fantastic story. The biggest surprise for me, reading this, was that this was performed in front of an audience. I had always thought of ExtremeHour as useful for the participants, not an audience. That's a gutsy move -- I don't think I'd risk it. Am I correct in understanding that you did this as a way of getting your recommendations to take root? If you were to do it again, what would you change? --JimLittle

Hmm. Dramatic, sure, but ethical? What would you have done if one of those cantankerous tools had gone stubborn on you? Do your team regard you as reckless for putting them at risk? And did the boredom actually communicate, or did the audience just zone? I worry that you're more likely to build a reaction against process than for it, starting with such a stressful episode. --Pete. (PeterMerel?)

Fair questions. Let's run through them.

1. We did a run-through some days before the live show. In that run-through, the programmers really did get angry at the business owner, we took a full hour for the first iteration and had not yet developed the test cases (did I just hear Ron scream?), and the programmers had not learned to de-scope. So the practice run was essential - it was, in fact the ProcessMiniature the programmers needed in order to understand what was supposed to happen in the live show (that's what ProcessMiniature's are about).

2. If the tool blows up, then it does, and life goes on ... We did, in fact, switch machines between the practice and the live show, from a slow laptop to the guy's workstation from on his desk. But that's a second reason for the practice run.

3. I checked with the team before the practice run, after the practice run and before the live show, and they were all up for it -in fact I could have used several others who were willing to step in. (It didn't hurt that I bought them lunch afterwards, but that was only a thankyou for putting up with the strain - actually they all enjoyed the challenge and showing off their stuff in front of the big bosses).

4. The boredom was worrisome, but again, there were two business people, one a big boss, who sat the whole way through the practice run (the one-hour one-iteration version, which was a lot slower). She said she thought it would do everyone good to see just what is involved in getting an application out, even if it was boring to watch. Add to that that it was probably no more boring than the average business meeting with bullet slides and a droning speaker. Actually, most non-programmers have this real curiosity to see what programmers actually do when they're doing it, so that was part of the value of watching. I let it get boring periodically so they could dwell inside that, and alternated that with commenting on what was going on, so they could see their own development dynamics at work (counter-offering, de-scoping, not saying they're done, handing off interface definitions and code bases between programmers, etc.).

5. I had a main purpose to the show and a serendipidous one showed up. The main purpose was this: I had just crafted a few (33) changes to their methodology. Question: how do you get a new methodology to stick? Failed answer: Write it down in a report. Experimental answer: Perform a ProcessMiniature so that everyone sees the methodology in action live. This was the announced purpose of the show. Therefore, everyone had to sit through it and understand its dynamics. The serendipidous purpose was this: a number of people did not know the script of ways to act in a positive and contributing manner. The dynamics of the session allowed me to rewrite some of the lines in their scripts, on the fly, so they would know how they should speak in future meetings. The punchline is, what were the alternatives that were open: (a) write fat documents :-(, (b) design a mousetrap in front of the company (big deal, say the programmers), (c) stretch the limits. After checking the three options with various stakeholders, big bosses, business owners, programmers, we opted to stretch the limits :-)

Oh, you can guess that this company (of 50 people) actually has a pretty comfy attitude.

I would say "don't try this at home," except that you are all professionals, and you won't be trying it at home. The caveat is that there are some mid-air corrections one has to be prepared to make during the flight, so it may not be for the weak or unwary. --AlistairCockburn

800 lines of code in 5 languages for a web-counter? I think I can hear perl programmers snickering. ;-) -- WetBlanket?

(Indeed, 800 lines... That was for Gemstone DB, server, servlet, XML, etc. Also included all the test code... of course, real Perl programmers could save on the test code, I'm sure)

This does indeed show cojones, but I think the original version of ExtremeHour is always going to work better for a presentation to an audience. If you're just presenting to developers, however, this thing sounds like a lot of fun. --PeterMerel

CategoryStory