Tag Archives: conference

The Vision Thing: How Do You Charter? #agile2011

We held a "Fringe" session at Agile 2011 to discuss how people charter or kick off projects. 

Elements of "Kickoff"

[These are in no particular order.]

  • Vision
  • Release Criteria
  • Success Criteria
  • From and To State
    • Business capability
    • Solution vision
  • Risks / Fears
  • Rallying One-Liner [may match up to Vision]
  • [Early] Backlog (maybe)
  • Mission
  • Team Agreements / Social Contract
  • Community [incl. users, customers]
  • Project Boundary
  • Domain Language
  • Scope Discussion
    • Tradeoffs
    • What's the minimum?
    • "Big rocks"
    • "Not" List
  • Guiding Principles
  • Resources / Constraints

Factors / Approaches / Techniques

  • Innovation Games
  • Metaphor
  • Mini-design studios (e.g., to explore shared understanding of "commitment")
  • Sliders
  • Ranking
  • "Not" List /  In-Out List
  • Sr. and other management present
  • No iteration 0 [get going instead]
    • -or-
  • Iteration zero that includes a skinny end-to-end "Hello World"
  • Timeboxes
  • Quickstart approach
  • Experimentation
  • Inception Deck

Thanks to all who participated! 

NASAGA ’06 Trip Report

Part 1

NASAGA – the North American Simulation and Games Association – is a group consisting mostly of trainers and facilitators who use games and simulations in their training. They're having their conference in Vancouver BC this week – and it's lovely here. (The only problem is – the conference has been so busy I've only been outside 2 hours.)

A lot of the fun at a conference is reviving old friendships and making new ones, but it's hard to capture all that. Instead, I'll focus on the sessions I attended.

Pre-conference workshop: Dramaturgy of Games, by Bernie DeKoven.

Childrens' games can contain deeper messages, when looked at through the lens of "theater."

For example, in DUCK DUCK GOOSE, you have to act certain ways if you want to be picked or don't want to be picked. You can use status clues to say "don't pick me." There's a drama in who you pick – the slowest kid? the fastest kid? your best friend? the kid you wish were your best friend?

Another game is HOT BREAD AND BUTTER. The kids all stand together at "Home". One child hides a belt. (And it must be a belt – Bernie described trying unsuccessfully to get the kids to use a rolled up newspaper.) He calls out, "Hot bread and butter, come and get your supper." Everybody runs away from home base, trying to find the belt. When someone finds the belt, he hits the other kids with it until they get home. (It was described as tapping a "coup" hit, not a beating.)

Bernie interpreted this as a play about the need to grow up. The kids who played were about 11 years old, and they were realizing there is such a thing as adulthood. You aren't granted adult-ness, you seize it. Now, if you stay home (as the home base was literally called), you won't have to deal with the consequences of adulthood (here, getting hit). But if you stay home, you can never become an adult.

We spent a fair bit of time playing, WHO STOLE THE COOKIE FROM THE COOKIE JAR? ("Who stole the cookie from the cookie jar? Number 7 stole the cookie from the cookie jar. Who me? Yes you! Couldn't be! Then who? Number 5 stole the cookie from the cookie jar.")

We talked about fun. "Having fun in public is almost a political statement." "We package fun [movies, sports, etc.] but it doesn't touch our core. And we've lost our ability to create our own fun."

Bernie described Csikszentmihalyi's flow model; with challenge and ability on two axes – too challenging, we're anxious; too simple, it's boring; right on the edge – we may get flow. Flow is characterized by a sense of timelessness, focus, stillness, vividness, oneness.

Bernie has another model to go with it: "we" is on one axis, "me" on another. With way too much "we" or too much "me", we have alienation. More "we" than "me" leads to problems like co-dependence and mob rule. More "me" than "we" leads to self-absorption. In the middle channel, we have "co-liberation". When both are together at high levels, this co-liberation is confluence.

We played a few more games, PRUI, I DOUBT IT, BATTLESHIP(tm), and we tried an exercise from Agusto Boal's "Theatre of the Oppressed." We discussed a high-jump bar like this: |\| that lets everybody choose their own level (rather than a constantly raising high bar that makes everybody a loser).

Although we talked some about application, I really liked the general enthusiasm of just enjoying play as fun. And the theater notion yields some insights.

Part 2

Keynote: From Flint to Fireworks, by Dave Chalk

Dave Chalk described his own learning disabilities, and yet he became Air Canada's youngest pilot.

"Passion comes from pain." "Adults today believe they can't learn." "Today, apprenticeship is far too costly" but simulation is a cost-effective substitute. People complain about rote learning, but we're willing to do it in games.

He spent a lot of time talking about mirror neurons, a recently detected type. These neurons imitate, learn, and predict. We have the saying, "Monkey see, monkey do." And in fact, monkeys are the only other species known to have these neurons. They fire when we have empathy.

The key thing is: these neurons don't differentiate between looking at something and doing something! "These neurons are almost as important as the discovery of DNA." Training can be done using them if it corresponds to what people want to learn.

"Consciousness may be as simple as a yes/no switch telling you whether to actually do something." Autistic children appear to have mirror neurons that don't fire properly. Mirror neurons explain contagious laughter and contagious yawns, and why TV and multimedia are so compelling. "Ten years of watching can make you an expert."

"Control the mirror neurons' input, and you absolutely control the learning." Sony just got a patent on the ability to beam images and sounds into the neurons, to avoid the need for "learning".

Keynote: Theater of Games, by Bernie DeKoven.

(Some of this overlapped the workshop discussion, but I'll pull out a few other points.)

  • Games are theater – e.g., sports, childrens' games.
  • We have deeply played games – ones we've played many times. For example, in HIDE AND SEEK we learn what it means to hide too well, and we carry that into adulthood.

Games, especially national games, correspond to the national character. Compare FOOTBALL (confrontation) vs. SOCCER (dance and avoidance), much like CHESS (armies clashing) vs. GO (guerilla warfare).

"THe only difference between a kids' game and a simulation game is how much you have to debrief. We deny the power of the game when we focus on what was in the debriefing."

Session: Extinguish Boring Presentations, by Ken Bellemare.

We did the straw through potato trick, to talk about what you assume you can and can't do. Ken described Thiagi's 6-step debriefing model, mentioned the "What / So What? / Now What?" debriefing model, and pointed us to Roger Greenaway's site for more.

The Attention Time Cycle:

  • 3-10 seconds – fight or flight response
  • 6-8 minutes – attention span level
  • 20 minutes – focus time (if it's interesting)
  • 90 minutes – as long as you can tolerate sitting at one stretch

The natural cycle is for attention to start high, dip in the middle, and come back high at the close. By using "hot spice" every 6-8 minutes, you can help keep attention focused the whole time.

Hot spice can be done through space (movement, voice control, …), props, unusual things (such as flash paper), audience involvement. Ken likes a question Thiagi uses, "What's a question a confused person might ask at this point?"

We discussed stages: unconscious incompetence, conscious incompetence, conscious competence, and unconscious competence, using the approach of trying to sign our name identically, twice with our strong hand and twice with our weak hand.

Ken warned us of an easy habit – "autobiographical listening," where we try to take over somebody else's narrative as a story about ourselves.

At the end, we got to try a piece of flash paper for ourselves, which was very neat.

Session: Interactive Experiential Games to Teach Systems Thinking, by Ron Roberts

The linear/sequential approach has A->B->C, inputs/throughput/output. If there's a problem, the cost rises exponentially.

A feedback approach has Input->Throughput->Output->Compare to Future Desired State -> Feedback -> Input.

To demonstrate systems thinking, we played a peg-based game that had us try to create patterns according to numbers and colors. As you might expect, there was a bit of "kicker" in scoring and in thinking about it. (I won't give any spoilers.)

Session: Edutainment Strategies for Blended Learning, by Curt LaLonde.

There are three elements –

  • Entertainment – motivation strategies
  • Instructional strategies
  • Blended solutions (mix live and electronic)

For entertainment, we can consider the difference between intrinsic and extrinsic motivation. Production values and consequences address the latter; relevance etc. affect the former.

He described Bloom's model of the levels of learning:

  • Evaluation – appraise, evaluate
  • Synthesis – arrange, collect
  • Analysis – categorize, compare
  • Application – demonstrate, dramatize
  • Understaning – classify, explain
  • Knowledge – list, memorize

In one approach ("sequential"), it's easier to address the lower levels with self-paced instruction; live teaching may better address the upper levels.

The "Host/Container" model looks at the host (class, live, online) and the elements (video, quiz, chat). The host may be synchronous or asynchronous; the elements may be synchronous, asynchronous, or both. (For example, you might have asynchronous elements inside a synchronous session: "please try this on your own for 5 minutes.")

As an exercise, we picked a system to discuss in small groups. The discussion was very helpful, and left me with some ideas for things I could do in my own teaching.

Part 3

I know I said "day 3 of 4", but I actually need to add a couple more things about day 2.

In addition to his keynote speech, Bernie DeKoven was recognized for his contributions with the Ifill-Reynolds Award, which NASAGA bestows on someone each year.

In the evening activity of day 2, I joined the group playing STARPOWER, a simulation by Garry Shirts. This game has you split into three groups and engage in a trading game. The rules are designed so that the system makes it hard to change groups (though we in the lower group did manage to get one person into the top group by pooling everything we had).

There's a rule-making round, where the top group gets to create rules. Our top group said, "You can talk before trading," "Players in the top group start with an extra chip," and "You must trade with a top if they ask you to," but also "Someone in the top group will try to accommodate any trade request made by the lower groups."

A couple things struck me: one is that the bottom group had the easiest time making decisions, the middle had the middle, and the top had the toughest. This was true for every decision and discussion. During the debrief, someone said that the lower two groups were discussing trade strategies, but the top group was about power.

We discussed how much the system enforced the lack of mobility. Someone in the top group said they did add a rule that would help the lower groups. That was true, but I think the rule came across as "charity" or a "tip of the hat" toward equality, without the real thing. (Note that two of the new rules further reinforced the position of the tops, even disregarding their other current and past advantages.)

It was an interesting simulation. The game's structure certainly enforced the system it wanted to. It effectively points out how a society, consciously or not, creates rules that reinforce the powerful.

Keynote: SAGE – Simulation And Gaming Environment for Learning, by David Kauffman.

SAGE is an academic initiative, supported by the Canadian government. It focuses on, "How do people learn through SAGEs?" They're using a multi-phase approach, to first review and translate existing literature, to do development research, and to do evaluative research in live settings.

They've focused on healthcare as their initial domain. One of their ideas is to use a patient-focused rather than a biomedical-focused approach. By generating emotion, they hope to generate memorability.

The group uses a couple other distinctions. One is the "foundation" – conceptual foundations, methods and tools, and technology. Another distinction is games vs. simulations vs. simulation games.

Some things they've developed: a repository of articles, prototypes, a generic game shell and a supporting site where people can share content, some multimediat simulations, and a Contagion simulation. They're also exploring ways to wrap a virtual usability lab around the games, to help with evaluation.

David pointed out that there's often a debate about games – are they something kids need to be weaned off of, or do they promote concentration and skills we can use? Their group believes games both have motivational power and the ability to be a powerful learning tool.

They've been using a framegame approach, where there's a structure with rules and challenges ready to go, and content (information and objectives) that you "pour in."

A simulation game is a simulation that has game-like elements such as goals and scoring. They introduced this distinction because they were seeing mixed results when people considered, "Do games work in education?" Their hypothesis is that simulation games are generally effective.

In the future, David sees them going forward with completing prototypes, doing controlled studies, and continuing knowledge dissemination. He invited others (large or small) to partner with them.

Two related web sites: http://www.sageforlearning.ca and http://egc.savie.ca. For further reading, he recommended Simulations and the Future of Learning by Clark Aldritch, and Digital Game-Based Learning by Marc Prensky.

Session: Implementing Games and Simlations in the Virtual Classroom, by Joey Monaco.

Joey demonstrated several games that she uses in virtual classrooms. One was a hidden word match, where you connect matching answers and find a secret word. (In their environment, people can used shared drawing tools to create the connecting lines.)

Another game was "Who wants to be a virtual contestant?" Someone is a contestant, and the audience helps. We did a "fill in the blanks".

To help get people to read material in advance, Joey uses pre-session brainteasers. People get to show off their knowledge a little.

Joey had developed a couple branching-based tools, similar to "Choose your own adventure." This seemed to require a lot of work (both in terms of working out the whole branch structure and applying it). A related technique was the use of multimedia simulations.

An issue in virtual classrooms is how people pay attention. Her group's goal is to make the content so compelling people won't multi-task around it. They use a variety of interactions and techniques to make that happen. For example, they shift modes at least a little every 7-8 minutes, they poll people several times per hour, and they limit sessions to 120 minutes (though they believe 90 minutes might be better).

In the future, Joey sees more sophistication (e.g., 3D), multi-player online capabilities, and the use of simulation for assessment.

For further research, Joey recommends Games magazine, The Imagineering Way, and http://sesameworkshop.org.

Activity: Treasure Hunt, by David Blum.

David Blum has one of the coolest jobs I know: he travels all over and creates team-building treasure hunts. He gave us a taste of his skill. He found 6 interesting landmarks within a several-block radius of the hotel. He gave us 6 clues (e.g., realizing something was morse code and translating it). The clues led us to the landmark, where we had to note a name or word. Our group was the only one to solve the bonus clue, so that made up for me messing up Friday's sudoku:) Vancouver has had such great weather this week; it was nice to get outside even just for a little bit.

Banquet, Talent Show, and Auction

After dinner, we had a brief talent show. It included an improv scene, a story, and a poem. But the highlight was hilarious: a cow in a dress, singing a sort of torch song and playing a musical saw. I'm done crying now. The auction was fun, and raised more than $3500 for scholarships.

Part 4

Keynote: Spontaneous Brilliance, by Kat Koppett

Kat described aspects of improv, and how it can be used to create an environment where brilliance emerges.

The first rule – celebrating failure. "Exercise the courage muscle – our willingness to be creative and take risks. We don't do it by creating a safe environment, we do it by creating an incredibly risky environment." "Celebrate failure and realize it's ok. Think of mistakes as gifts." "Creativity is by definition an act of courage." That allows us to tap into our spontaneity.

We did a rapid word association exercise. "This activity outs the judge in our head. We may need to judge sometimes, but that censor already gets a lot of practice and support." People described a variety of rules they made up for themselves, and that got in the way. "We evaluate things that don't need to be evaluated."

A second rule – "Trust your impulses." One activity is "brain fries," that overload the system so hard you can't judge. Spontaneity is a muscle too. Give offers – make stuff up. "Most of creativity is not making up things inside ourselves – it's responding to input". "Yes, And is the fundamental improviser's mantra." "All we have is the offers our partners make."

In brainstorming, you accept and build, saying "yes, and" as well. But improvisers mean something more profound. "There are offers out in the world – anything that's present." Some offers are more open to interpretation. "How can I use these offers?" vs. brainstorming. For the improv offer, you don't have to like it, the offer just is. Ignore offers at your own peril.

"Yes, And" doesn't imply agreement with a situation. Sometimes you can just name a situation – "I see you're rolling your eyes." "It's harder than you think – and it's easier than you think."

It can be rough to create in a team – we have shared responsibility and shared control. "The clearer I am on my idea, the harder it is to collaborate."

Another secret of improv is "Be obvious – dare to be boring." Kat worked with Performance of a Lifetime, which isn't afraid to back up and untangle blocking or poor listening.

What happens when we're under stress? Some people become drivers, trying to take charge; others are wimps, giving up and failing to continue making offers.

Summary: Be aware of the rules you make in your head. Use offers to engage. Note that there are many ways to say "no" without using the word "no". The "and" is as important as the "yes."

Look at our lives as improv scenes. We can see and accept more offers. We can get better at recognizing the huge range of choices we have. "We can create wonderful plays with each other."

(I loved this talk – and I'd love to hear Kat at the Agile software conference.)

Session: Unleashing Your Brilliance, by Brian Walsh.

This session used a number of physical "tricks" applied in the hope of improving the functioning of your brain. (Do they work? I don't have enough experience to say.)

Example: keep moving your foot clockwise, then write a 6 in the air with your hand.

The pain/pleasure principle – we move away from pain, and toward pleasure. "A decision to move toward something is more powerful than a decision to move away from something."

Enriched learning has multiple related topics: water, multiple intelligences, music, NLP, kinesiology, memory, the brain, total physical response, accelerated learning. (He made a concept map to show this.) Claim: "pictures are three times as good as repetition."

We have control of 70% of the effects of age on the brain – through physical exercise, learning, water, food, sleep, etc. we can help that part.

Brain Gym ™ – kinesiology and whole-brain together. Example: Cross crawl – touch left knee with right hand, then right knee with left hand, repeat a few minutes. This is designed to help integrate the left and right parts of the brain. Example: "Brain buttons", "K27" in acupuncture – two spots located 1" below and to the right of the collarbone: rub these spots to get more oxygen.

The reward center lights up stronger for unexpected rewards.

Neuro-linguistic programming talks about the three modalities: visual, auditory, and kinesthetic.

Exercise – eye dominance. Hold hands at arm's length with a small triangle gap, then close each eye separately. The image will jump for the non-dominant eye. We have dominant ears and dominant feet too. When do these factors count? When we're under stress, and when we're learning new material.

Exercise – earlobe roll. Exercise – jaw massage.

Exercise – hold hands at arm's length with thumb up. Move thumb in an "infinity" (sideways 8) pattern. Make the eyes follow the thumb, but don't move your head. This is to activate different parts of the brain. Ex: NLP believes we habitually access imagination when we look at one quadrant, and memory in another.

Presenter's trick – move to the opposite side of the room from the questioner during question time. This helps that person project their voice further, and helps keep the rest of the room engaged.

Presenter's trick: wear at least a little red.

Multiple intelligences – Howard Gardner. Gardner thinks of schools as traditionally focusing on math/logic and linguistic intelligence. But there are others: interpersonal, intrapersonal, naturalistic, music, spatial, kinesthetic, etc.

Memories are fragmented and stored in multiple places. Memory can't be trusted. Involving lots of senses gives us a better chance of recall.

Basic Rest Activity Cycle – every 90 to 120 minutes, the dominance of left and right brains moves back and forth. The left brain corresponds to activity, the right to rest. During sleep, we get a sine wave at a deeper level. Take advantage of the troughs; try to go to bed and wake up at the same time each day, try to come out of sleep when you're nearer the "top" anyway.

Application: proofread an important email ~40 minutes after writing it, in case it was written while the left brain was inactive.

Key points: Water, breathing, and the comfort zone. Physical activities. Moving away, moving towards. Seeing the big picture creates file folders in your brain. The Basic Rest Activity Cycle.

Session: Captivating Your Audiences through Storytelling, by Carla Rieger.

We worked through an exercise exploring what makes stories work or not work, and our strengths and weaknesses as storytellers.

In using stories, there are several challenges. Keep the story short (possibly 5 minutes, not longer than 10 normally). Make it personal, not the "starfish story." Choose a topic demonstrating challenges, discoveries, or decisions.

Carla adapted the Satir change model as the model of the story: old status quo (setting the old platform), tilting the platform, consequences, transforming idea, getting back to stability, new platform.

As an exercise, we identified a number of possible stories, then told one to each other and identified the various parts according to the model. (It's a lot easier for someone else to identify parts in your story than to do it yourself.) We turned it into 5 sentences, and then made tableaus demonstrating the sentences.

I talked to the instructor at break, as I felt like a lot of my story ideas just reflected a situation that "corrected itself" and to some extent I was floating along in that situation. It seemed like a story with no real point.

For my story in the exercise, I used a personal situation that felt like it resolved itself with a boring non-event. My revelation in this was that what I thought was the transforming event ("the problem went away on its own") was not – what counted was my reaction to a troublesome situation where I decided to let it work itself out as much as possible. Understanding this left me with unexpected tears.

In the followup discussion, several things came out. A key one is that many times, you need to figure out the point of the story to know how to structure it. Having someone reflect the story back can help with this. Another easy-to-fix problem is the tendency to jump into the story and ignore the context. Carla called her story model "story paint by numbers", but pointed out that many movies and stories fit the pattern, and that you can play with the pattern once you understand it.

Finally, Carla suggested some next steps to really make story skill-building happen:

  • Put each sentence (of the 5 keys points) at the top of a page, and flesh it out (written or oral).
  • Practice saying the story aloud, and rewrite it as you go.
  • Try it with colleagues/video/audio. Fix what's missing, and what needs to be cut. Figure out what the story is really about. Do "act outs".
  • Rehearse 20 times.
  • Send Carla the result by next Friday.

I really appreciated this session. Stories are important, and I'm working on being better at telling them. This session will definitely help.

Good-bye 2006, Hello 2007

The next conference is October 10-13, 2007, in Atlanta, Georgia, USA. I'll definitely be there.


[October 13-14, 2006.]




Agile '06 Workshop: Example-Based Specifications

This workshop was designed to explore Example-Based Specifications. Hosted by Brian Marick and Bill Wake.


  • 1 hour – One person plays customer, the rest of the team writes tests
  • 30 minute debrief
  • 1 hour – Small group discussions
  • 30 minutes – sharing and conclusions

Test Writing

Group 1: Domain – a statistical tool that evaluates inputs according to a formula, and plots the results.

Their test:

(A, B, and Y are inputs; b0, b1, b2, and b12 are outputs, produced by a process of matrix algebra.)

A B Y b0 b1 b2 b12
10 75 8 11.0 5.0 8.0 12.0
20 75 12
10 100 10
20 100 15

This is a textual representation of the graph

b0 b1 b2 b12 B-1 B-2 B+1 B+2
0 5 8 12 (1,1,RGB) (10,10,RGB) (10,1,RGB) (1,10,RGB)

Their expected graph (described here, though the team drew a picture):

  • a large X with each line in a different colors
  • labels +1 and -1 in the graph
  • a horizontal axis labeled "A" (also having labels -1 to +1)
  • a vertical axis ("Y")
  • a graph name ("B").

Group 2: Domain – a session scheduler, matching audiences to rooms

Test: Schedule a session –

Preconditions: user has logged in, room size < audience size

  • TU35 has iaudience 100
  • Room NICA has capacity 25
  • TU35 is not scheduled
  • NICA is available Monday 11-12:30


  • User assigns TU35 to NICA at Monday 11-12:30
  • System displays a warning, "Room size mismatch… Continue or cancel?"
  • User selects "Continue"

Expected Results:

  • TU35 shows up scheduled in NICA, Monday 11-12:30

Group 3: Domain – a graphical tool for tracking and identifying criminal conspiracies. (Tool helps build a network of connections between people).

Their test:

Select template criminal
Create node
Create node
Select link template ?
Create link
Check count links 1
Delete node 1
Check count links 0
Create node policeman
Set first name Tom
Set last name Nassau
Create criminal
Set last name Soze
Select link template arrest
Create link Nassau to Soze
Check link exists
Select template policeman
Create node
Add role
Select node 1
Check has role policeman
Check has role drug dealer

Group 4: Domain – an expense approval manager

A GUI mockup:

    Manager approval:

Type Date Description Amount Needs Receipt
    American Airlines SEA to MSP $600.00  



Issues: editing, are you sure?, manager approval, expense group


Type Date Vendor v Description Amount
Air tix 7/16/06 AA ORD to MSP 763.42

    Purpose: Trip to agile conference
    Manager approval:    Pointy-haired boss

An analysis of states:

New – Open, can’t pay, can’t approve, can’t close
Submitted – Open, can’t pay, can approve, can’t close

  Is Open Can Pay Can Approve Can Close


Group 5: A stock trading program

A screen mockup with annotations:

Start Time [   ] v : [   ] v 9:30-16:00 ET (market start to market end)
End time [   ] v : [   ] v
Stock Symbol [    ] 1-4 alpha
# Shares [    ] 1
Order Size [    ] 100->1 million (int) (+- 100)
Price $ [    ] (optional) numeric + 2 decimal optional
  [OK]    [Cancel]  

Test of algorithm:

  • Start time >= now >= 9:30 EST
  • End time > start time <= 16:00 EST
  • Distribution list (file) exists
  • Test invalid symbol entry
  • Test for valid symbol entry
  • Test all shares are traded if no limit price
  • Test trades don’t violate limit price
  • Buys or sells based on selection

Group 6: Insurance tracking program

Test for story "Insurer adds provider":

Test 1 – Sunny day

Add table:

Johnson, David name 15ch, 15ch
1200 Nicolette Dr addr1 40ch
12345 addr2 5d or 5d-4d
123456789 taxid 9 ch num
ALLINA network id must exist in db

Read: (same)

Test 2- Invalid zip code (and more like this…)

Johnson, David name 15ch, 15ch
1200 Nicolette Dr addr1 40ch
1234 addr2 5d or 5d-4d
123456789 taxid 9 ch num
ALLINA network id must exist in db

Expected error: "Invalid zip could should be 5 digits"

Test for story "Analyst approves pending claims < 60 days since claim made"

Test 1 – Sunny day

Populate database – set up claim 1

Date of claim 30 days ago
Member name Doe, Jane
Provider name Johnson, David
Diagnosis 769
Charge $500.00
Network id ALLINA

Step 1. Analyst views pending claims < 60 days (display claim A => OK)

Step 2. Analyst approves pending…

    Signal "ok" = submit
    Claim disappears from list
    Message "approved"

Step 3. Read claim, status "approved"

Group 7: Domain: Shipping company.

Test: 1. Customer ABC call to know where shipment with order #33 is. The system should answer, "Last stop was Tampa, FL."


Note Order # from Customer Request Answer from System
Truck left origin #33 last stop? Tampa, FL
Not in truck #34 last stop? nothing
Truck at destination #35 last stop? Daytona, FL
Truck at destination #35 arrived? yes
Not in truck #34 arrived? no
Not arrived #34 expected date? 26/7
Arrived #35 expected date? 25/7
Truck underway #33 arrived? no

Example context:

# Pick up origin Final drop destination Expected Date
#33 Tampa, FL Toronto, ONT 27/7
time 24/7 8 AM  
#34 Vancouver, BC Toronto, ONT 26/7
#35 Toronto, ONT Daytona, FL 25/7
time 24/7 17:00 time 25/7 10:00

Test 2: I want the system to help me minimize empty truck displacement. For example, I want to be able to ask if there is an empty truck in Ontario on July 27. Arrival within 2 days.

Empty truck in? Shipment order  
Ontario/27/07 #33, #34 truck at city
Ontario/25/07   no truck because wrong date
Montreal/QC   no truck because wrong location


We noticed these things from the experience of writing tests:

  • What to do is vague.
  • Developers tend to embellish.
  • Tests teach developers, but it’s a challenge to pick the right level.
  • It’s hard to turn descriptions into tests.
  • Tests (and collaboration) can help you discover new things.
  • The idea of a GUI became actions on a model (for the test).
  • Customers should come in prepared.
  • We need many questioners per answerer.
  • Someone came in late, and found that the examples helped them understand.


In small groups, we explored these topics:

  • Sufficient coverage: How do you know you’re done – what’s sufficient coverage?
  • Test styles: What is the relationship between example-based specifications and other styles of tests?
  • Product Owner: Techniques for interviewing product owners

Sufficient Coverage

  • When adding tests to a legacy system, how much do you "backfill"?
  • Should we just use "change detector" tests (record what the system currently does, knowing that it may change later, and may not even be correct).
  • Do we need all combinations?
  • Where do we fit example-based tests?

Test Styles

We suspected these things about example-based tests:

  • They may bring about exploratory testing, regression tests, better unit tests, acceptance tests. Load tests?
  • They provide a concise account of an edge case.
  • They serve to train new developers in a domain.
  • They provoke a certain style of conversation.
  • They may overwhelm developers with distracting detail (no "metaphor").
  • Alternatively, developers may ignore examples! It happens…

Product Owner

  • Use Sophie’s Rule – keep asking "why?"
  • Ask the end goal, define the business problem, define acceptance criteria
  • Discuss requirements "as if you were blind" (without reference to UI)
  • Need a customer who is is readily accessible
  • Helps to talk to end users
  • Programmers need to understand the domain
  • Let product owners ramble

General Notes / What Next

  • Mind maps have utility in these conversations.
  • Examples are a style of conversation – the easiest kind to get.
  • "We’re going to practice" – "process miniature" exercises could help.
  • A whiteboard and pointing are powerful ways to focus attention.

Extreme Test Makeover – Agile ’06

Brian Marick and I hosted "Extreme Test Makeover," where people could bring their laptops with code and tests, and have an experienced tester/programmer review them. Observations by participants:

  • Watij tests in Fit are too long/confusing to read for customer.
    • You could write it in JUnit instead of Fit
    • Break them up into small focused tests
  • Neat new delegate syntax (with .Net 2.0)
  • Descriptive variable names are good [even] for short term variables.
  • Keep tests focused on one purpose – If a test needs 3 things to work, create 3 tests
  • Generic isn't always useful.

Thanks to our participants and our experts: Bob Martin, Brian Button, Janet Gregory, JB Rainsberger, Jim Newkirk, Jim Shore, Lisa Crispin, Micah Martin, Randy Coulman, and Ward Cunningham.

NASAGA '05 Trip Report

I was at the NASAGA conference, and posted this quick report (onto the NASAGA list).

It’s always nice to start by running into old friends & making some new ones. Then I get into my fundamental problem I – there’s so much going on, it’s hard to choose what to do.


Wednesday, Les Lauber and I hosted a workshop on "rapid game remodeling." We had a small group, but a good time. We started by playing a number of games, then deconstructing the elements at play. We followed with a blitz of quick demonstrations of a bunch of games, then some theory, and finished by exploring a design of a game to fit someone’s work needs.

The workshops were followed by a reception. Brian Remer (our host) had arranged for some wonderful musicians to help us learn contra dancing, which is sort of like square dancing. It was fun, but exhausting. I had thought I’d be playing games afterwards, turns out I was just going to go fall into bed.


The first keynote was from Ron Roberts, a game designer and professor. He spoke on "The Power of Games in Accelerated Learning." My takeaway from that was to focus more on the "context" of what I’m teaching as well as the "content." The talk got pretty frenetic near the end when we had to toss stuffed animals between tables.

I followed this with a much milder session, "Can P-conferences teach e-conferences?" Chris Saeger created a simulation of an online conference where we used sticky notes to communicate in simulated chat rooms and work areas.

Then Matthew Richter helped us explore "Incorporating Motivation Theory into Games". He uses a model from amotivation (apathy) through extrinisic motivation of various types (doing it because of outside incentives), to intrinsic motivation (doing it because you want to). We had good discussion around the demotivating aspects of extrinsic rewards.

Dr. Clue (David Blum) gave us a taste of using and building treasure hunts. We ended by designing our own clues, and having other teams try them out. They were pretty tough to solve, but very fun to create.

After dinner, Ron Roberts, Clark Quinn, and Charles Phillips had a panel discussion, hosted by Les Lauber, where they discussed game design and marketing.

The evening ended (late) with a group of us playing a number of games. Somehow they tended toward a grisly theme: Give me the Brain, Guillotine, and Middle Management. Guillotine in particular was very fun.



Friday was a bit more relaxed of a day.

We started Friday with a talk by Clark Quinn on "Designing E-Learning Games". He comes from a cognitive design background, and has the goal of "using technology to make people wise." His brief demo showed a couple games, one a simulation of a hospital, the other of project management. Both used a cartoon style; the interaction reminded me of "Monkey Island" (if you’re old enough to remember that), but it’s built around a particular model and rules engine.

He pointed out that, "Learning is difficult; engagement is difficult. Doing both together is doubly hard – but more than doubly valuable."

The programs rely on "one of the robust results of cognitive science": people don’t make mistakes randomly – there’s usually a logical, sensible reason that is both wrong and hard to extinguish. People tend to patch their model rather than adjust it substantially. By focusing on where decisions lead, we can get to the crux of them in the games.

Quinn has a number of tools to help in the design and development of his games (such as storyboards and concept documents), but points out that tuning can be a large and tricky part of the process. He also pointed out that we can build in metrics to assess how well usability, education, and engagement goals are being met.

To close out the morning, I went to Kat Koppet’s session on "Improv Designs for Inspired Teaching." We tried (and debriefed) several games. My favorite was a "word toss" where we tried to keep two sets of words passing around a circle. We also saw an example of "telephone" – where a story gets passed along by people who try to imitate the content, tone, and gestures. We ended by creating a few stories using a "story spine", by going around the table and having each person add a sentence.

The afternoon was "lazy" – a leisurely lunch followed by game time. (Some other folks decided to try the low ropes / high ropes course, which also sounded like fun.)

During the evening, there were some simulations being run, but Raja Thiagarajan and I used that time to do a little programming on a small game project.

We joined back in on the evening games. My two favorites were "Guillotine" and "Tutankhamen"; a couple people said they had enjoyed the "Bux" game even more (whose inventor was at the conference). Gaming wimps like me only made it a bit past midnight. The hard-core ones were at it till 2:30 AM:)


Unfortunately, at least from the perspective of enjoying the conference, I wasn’t able to stay for Saturday’s events.

Agile ’05 Conference Report

Part 1

The Agile '05 conference was July 24-29, 2005, in Denver, Colorado, USA. There were about ten or twelve tracks at all times, so this report is necessarily only a limited bit. Usually I teach, but this time I was an organizer so I got to be more like an attendee in some ways.

Brian Marick and Bob Martin Keynote: Where were we, where are we, where are we going?

Brian Marick: We have different disciplines. We become multi-specialists. "A team of multi-specialists can knock the socks off a team of specialists." But there's no career path for multi-specialists – what conference would you go to?

Brian invited Jim Highsmith up to announce the formation of the Agile Project Leadership Network (APLN). Its focus is on applying agile principles to all projects, not just software. Relative to the Agile Alliance, this organization has consistent principles and intends to collaborate; it just has a different focus.

Bob Martin: "Value the flow of value."

The software industry: was either no process or waterfall. Now we're recognizing the failure of waterfall and the need to measure in-process work. It's time to do "software at home." Where we're going is to resolve this challenge, with short cycles, feedback, testing, craftsmanship.

The agile community: The Scrum paper in '95, XP in '99: resonated with the community. But we were fractured into many agile methods; branding. Now, industry is learning to pull and mix practices; we're at the moment of convergence. Future: head away from brands, strong focus on project management. At the end, we'll have a definition of agile.

Users: Were small teams with a programming focus; limited acceptance tests, project managers "lost." We are a community that has grown. We see 80-people teams often mixing Scrum and XP. 300-person teams exist. A company of thousands doing transitions. Future: we'll grow. Agile project management will happen. Automated acceptance tests will be regarded as the measure of progress.

Brian Marick: There was a group of English cyberneticians. They made discoveries of performance, adaptation, surprise. But oops… no (single) institutional home, no acknowledged base body of techniques, no grooming of successors. Their tradition is gone. To avoid this, "we gotta take over a university department." He announced the "Gordon Pask award", to honor people whose recent contributions demonstrate their potential to be leaders of the field.

Open Space

There were a lot of topics; see the web site. One was "XP Rituals", where we identified a number of fun things:

  • Breath mints
  • Haiku written on card before starting a task
  • Hacky sack at standup
  • Traffic light for builds
  • Darts when a pair finishes a task
  • "Story starting" gong
  • Story completion frog (noise-maker) or bell
  • Daily progress chart – two thermometers, showing days used and points locked in
  • Automatic break program
  • Smiley stickers for story cards

Metaphors, by Dave West

In 2001, metaphor was listed as an official XP practice (part of architecture); in 2005, it was not. Kent has said its redundant as a practice since you can't help using it. (Dave argues it's a learned skill.)

Metaphor has a lifecycle from poetry through use. Lakoff and Johnson say all thought is based on metaphor. Dave argues:

  • If you don't choose consciously, you get one unconsciously.
  • Metaphor selection has a real effect on software design (architecture).
  • Metaphor is a skill you can develop.
  • Therefore, it should be an agile practice.

We have many default metaphors: machine, org chart, entity, dualism, computer science, software engineering, product manufacturing. There are alternatives: e.g., object as person.

To use metaphors well, learn: reflect, experiment, read widely, liberal arts, point of view.

Tim Lister: XP Denver Invited Talk

  • Managers are lonely – they don't have a collegial environment.
  • QA is a bottleneck, and no wonder: it's done late and in serial rather than in parallel.
  • Getting agreement on requirements is not neat. "Gathering requirements" sounds like they're Easter eggs in the yard. But really, most requirements have to be invented.
  • Problem: people believe the customer.
  • It's messy, so model and prototype. Don't prototype solutions – prototype wrong things on purpose (so they can laugh at it).
  • Estimating is overwhelmed by expectations: skew (never early). Separate goals from estimates.
  • Software in general is uninteresting. "One right way" is anti-intellectual.
  • "Never lose the satisfying feeling of making something valuable, together with your colleagues."


Part 2

Delivering APIs in an Agile Context, John Major

John Major described a project that was doing custom programming of lab workflows as part of the Human Genome Project. This was an environment with lots of churn: biology, instruments, J2EE.


  • Stable APIs vs. agile change
  • General features vs. "Do the simplest thing that could possibly work"
  • Frameworks vs. global refactoring
  • Framework design vs. features

The result was a platform API, a mix of data-driven (configuration) specification and custom code. The team had the attitude toward process, "We'll try anything for a month." There was lots of testing. They used Jemmy with Swing.

Unique practices:

  • Internal support: old and new features. Used the idea of "office hours" for support. Provided training. Tried having platform developers work on applications, but it didn't work so well.
  • Lightweight code reviews. Rather than pairing, they required at least a 20-minute weekly code review with an office-mate.
  • Agile database schemas. Problem: RDBMS is rigid, but schemas evolve. Solution: build agile schema features and tools to manage change.

Lessons learned: Good:

  • Agile practices help keep technical debt low.
  • Build tools to support RDBMS and large codebase.
  • Pull in senior people to help design and adoption.


  • Cost of absorbing API changes is paid by the application teams, but benefits accrue to the business.
  • It's hard to get feature design right (to balance flexibility and focus).
  • The business had trouble understanding the costs of release management. (Branches made the whole thing even crazier; he described a "London subway" map they created to show all the paths.)


  • People issues – don't go into denial.
  • Weren't able to tell QA what the test suites did, so there was overlap between the automated tests and manual testing.
  • Be humble – the platform needs the app and vice versa.


  • Build reusable platform technology
  • Use agile practices to cope with change
  • Work with "eyes wide open"

Part 3

Rachel Davies' and Mike Hill Workshop on Informative Workspaces

Informative workspaces:

  • Team memory
  • Visible status (keep it fresh)
  • Automation – light and sound
  • Hawthorne effect
  • Track "puzzles"
  • Root cause analysis
  • Positive focus

Themes: Ownership: Own the space; collective ownership of communication, accountability.

Transparency: Be honest with yourself – show where you really are; peer pressure; reveal hidden/unknown problems.

Keep it Fresh: Drop stale charts. Let anybody update. Automation (e.g., build server status, test status). May use projects or status monitor.

Intra-/Inter-Team Communication: Visual progress => motivation. Whose team sees it.

Hokey-ness: Lack of ownership. Formality. Ownership – lead team to the charts. Time limit for new things. Cool is fun, but must be cool to team.

Kent Beck Open Space on Renewing the Fire

"The edge of knowing and not knowing" – Troy Frever.

What helps keep the fire? A lot of disucssion on being in the zone, in flow – but that's only part of it. Many people crave novelty, mentoring, flow, living on the edge.

There's a "game face" you put on.

Pollyanna Pixton Open Space on Organizational Change

There's a "practice" level, for developers, managers, product owners. But there's also an organizational change level.

"Continuous retrospective" – collect cards all week.

Leadership "versus" self organization.

Kent Beck Open Space on XP for Beginning Teams

He uses an Appreciative Inquiry approach. Take a practice – what does it mean for you? Acts as a "practice inkblot".

An AI formulation:

  1. Remember a good (peak) situation
  2. Explore the circumstances that made it possible
  3. What is the meaning now?

We broke into pairs and did some mind-mapping of a practice.

Research Paper: A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction – Mann and Maurer

Described a team that originally had variable sprints, then shifted its sprint size from 20 to 11 days at the customers' request. Research tried to address, "Does Scrum provide a sustainable pace?" They found there was less overtime (both mean and variance) after Scrum was introduced in this organization. Customers were more satisfied. (Planning closer to delivery led to less misdirected development; playing with the product in the release cycle let them tweak its direction.) Scrum gave them better control and visibility.

Research Paper: An Environment for Collaborative Iteration Planning (Liu, Erdogmus, Maurer)

They used a traditional-looking table with a projected image, and wireless tablet PCs.The thought was that people would create and edit stories on a tablet, then organize and prioritize stories using finger and pens. This would give real-time information, as well as persistence.

The display was nice. One neat trick was that you could "push" a card toward somebody and it would glide at a realistic-looking rate (but never fall onto the floor:)

Existing tools are either cards, which are easy to work with but lack persistence, or planning software, which creates an unbalanced environment (somebody controls the keyboard) but which does have persistence.

The research effort is just beginning; they want to evaluate, "Is it useful? Is it usable? How does it work compared to existing tools?"

Part 4

Jeff Sutherland on Advanced Scrum

"Better, faster, cooler." If this is interesting, see Jeff's paper. I made very quick notes but it's an interesting extension of the Scrum work and I plan to give it more study.

Scrum is out of development and into the whole company. This approach is for experienced ScrumMasters/developers only. See Lawrence Leach: "Eight Secrets to Supercharge Project Performance", Adv. Project, Inc.

Productivity is measured as "features/$100K"

How can we (agile?) win?

One study shows outsourcing cuts costs by only 20% – significant, but not quite the same as cutting 80% or more of costs as some have promised.

The new approach: anticipatory, requires accurate analysis of process and automatic monitoring.

Type A, B, and C Scrum – A: isolated cycles (breaks between sprints), B: overlapping iterations (no handoffs), C: all at once. Consider the sprint level. Need to do pre-staging work for the next iteration inside this one (or else we'll be tempted to fall back to type A).

Advanced scrum has multiple simultaneous concurrent sprints. All sprints release live software.


  • MetaScrum for release planning
  • Variable-length sprints
  • Overlapping sprints for one team
  • Pre-stage product backlog
  • Daily scrum of scrums
  • Integrate product backlog and sprint backlog
  • Paperless project management and realtime reporting
  • Administrative overhead of 60 seconds/day/developer and 10 minutes/day/ScrumMaster.

One of the big challenges is having items in the backlog be ready. In their case, that means "intuitive for a doctor" – usable within one hour. This means stories need enough detail, and must have been prototyped with doctors. It forces the product owners to work with the developers to prototype things.

MetaScrum: weekly meeting of stakeholders. Led by the Product Owner. Use the three questions. All product decisions are made here. Release status. All decisions are communicated that day. Damage control plans are executed in the same day.

Iterations: three-month – major product releases (eliminate bugs from portfolio); 1-month sprint for new customer/upgrades (eliminate high-priority bugs); one-week sprint for critical issues. This gives them 45 production releases a year. "Assumes good practices. They're using one code base, working at the tip.

Pre-staging: Overlap sprints, with no break between them. Work only on product backlog that is ready to go the sprint. Pre-staging can double throughput in sprints.

Prioritizing sprints. Constraint theory tells us we must have slack. This lets you optimize multiple overlapping sprints. The backlog is fully automated, with priority levels for the different length sprints (week, month, quarter). Developers focus on one task at a time in priority order. Completing weekly/monthly tasks let them get to the "fun" quarterly tasks.

Sprint backlog: Set to embrace change. Every sprint releases. Customer satisfaction is the top priority. Can restart – a MetaScrum decision.

Automated backlog: Via a bug tracking tool. For each task, the developer is asked: 1. For tasks touched today, how much time is invested in the task? 2. What percent is done? This provides enough data for management "micro-accounting".

Part 5

Random notes from Open Space

Overheard: "Whenever I've been late, I've been yelled at by management. One time, we actually pulled it together and finished early. The president called me – not to praise me, but to say, 'You sandbagged me.'"

Is XP Sustainable? Some things people do:

  • Daily: variety
  • Medium-term: cleanup projects
  • Gold cards (explicitly scheduled 'free time')
  • Slack

Rick Mugridge, Domain-Driven Design Patterns and Fit. Examples: queries vs. operations, entities vs. value objects, aggregates (key root objects), repository (turns into query or iterator). Can use a different test harness with the same fixture and same code, but control whether to connect to a "real" database via configuration.

A test writing pattern: create a setup, do some action, repeat the setup but show what has changed.

Norm K erth: The Secrets of Leading from a Position of No Power

He showed clips of the film Gandhi, then debriefed to explore how Gandhi led. He points out that we can learn about leadership from studying history. Gandhi: "Without a journal of some kind, you cannot unite a community."

Some principles: transparency, persistence, courage. An unjust law: don't resist, but don't comply either.

How did he do it? "He decided soemthing needed change–something important, and worthy of his effort." He let go of assumed authority.

Inauthentic power = anointed power – ("I'm powerful because I'm a manager.") – a weak form of power since it goes away if the position does. Authentic power – inside yourself.

Gandhi accepted the cost of punishment. "Better to lose your job for doing something, or for doing nothing?" He was respectful, sought commonality. He knew his support system: the law. He started small, finding people of like mind.

Characteristics of change agents:

  1. Ability to articulate a vision of where you are going (though it can change)
  2. Persistence
  3. Confidence – inner energy for the right thing
  4. Optimism – energy that you lend to someone else so they can gain confidence.

You can cultivate these!

"The most effective coach is sitting next to you, involved from the beginning to the end."

Gandhi: it paid to advertise. Peaceful revolutions are the lasting ones – they're really an evolution. Pick your battles – you don't need to do everything yourself. Know your real mission.

Joshua Kerievsky: Commoditizing Agility

According to Josh, we're right at the edge of Moore's chasm, and need to make it easier to make that move.

He had statistics from a project showing productivity increases by a factor of 2.5, achieved in one year with an XP team.

"The agile community is thriving, but transitions are too slow and expensive." Why? We're not agile enough in transitions. Problem: serialized knowledge transfer. The shift is repetitive and exhausting.

A couple models: 16 days coaching for a 15-person community. Or, inhouse workshop with 3-6 month full-time coaching for a 20-30 person community. Then try to stretch to other communities, transferring experts out and future experts in. The Problem: people are trained technically but not so much in coaching.

The basics are taught manually. This gives inconsistent content and it doesn't scale. Books don't go far enough. Basic knowledge is fragmented. Books require dedicated study.

This marginalizes coaching time: the basics take away from the hard stuff. It burns out the coaches. So we need to commoditize the basics. Experts are in short supply. How many coaches have 3+ years experience? Internal experts are "too indispensable" to share.


"Products and services are so standardized that attributes are roughly the same." A commodity market has declining prices and profit margins, more competition, and lower barriers to entry.

Ian Murdoch: "Open source and the commoditization of software": Commoditization happens eventually. It's unstoppable, but it's good for all. There's a cycle: Innovation leads to standardization [accessible] leads to commoditization (maybe) [affordable] leads to innovation. Innovation builds on a custom platform.

Commoditization can go two ways: Decommoditization is an incompatible innovation, or customization. But be careful with decommoditization – it can leave you out of the innovation loop.

What can be commoditized: basics, stories, planning, chartering, retrospectives, … What can't: advanced practices, specialized things, "living agile values", people issues.

Josh showed an example of Husqvarna's sales training – a sort of animated comic book, with a model of the sales process built in. He showed a demo he made, using a screen capture tool.

Bottom line: Tomorrow we can have parallel processing for the basics, leaving more quality time for advanced topics. We can get quality, speedy, consistent knowledge transfer.

Workshop: TDD and Beyond, Astels and Marick

Brian Marick emphasized customer-facing tests, that help with project communication. We don't want to do all the tests at once. "Doing Fit tests in a blob creates a bottleneck at the customer/QA level. We don't need all tests, we just need one to get started." He had the image of "programmers as baby birds" [feed me].

Rick Mugridge: We need to move toward declarative tests. "Procedural tests are a smell."

Questions: "Do you have to have normal (JUnit) TDD in place before STDD?" "Do you need a strong customer to make it work?"

Roadblocks: Fit is a challenge because you need programmers and testers to make it work.

Fit Unification Summit

Friday (after the conference), a number of Fit implementors met for a Fit unification summit. If you're interested in that, look for the fit-devl mailing list.

[Published in 5 parts, Aug. 23-27, 2005]




Kent Beck’s “Programming Intensive” Workshop

Kent Beck’s workshop was a chance to spend a few days programming and thinking about programming.

We used "games" as the vehicle. That worked well enough – you can get the feel of a game without having to develop it all the way out. In the evenings, we were on our own to do some writing and exercises in thinking about software.

The first couple days, we focused on creating a crossword puzzle helper. The idea is that you’d populate some parts of a grid, and then the tool would fill in the remaining words. We got far enough into it to show it worked on moderate-sized examples, and to start optimizing.

The next program we worked on was a partially developed tic-tac-toe program. We completed some screen hookup and looked at improving the code. We spent a good bit of time contemplating a couple approaches to part of the problem, and how you’d choose between them.

Finally, we took a stab at something closer in spirit to an arcade game; a relative of the commercial games Pong or Breakout. We got as far as having a paddle and a ball bouncing around. We gave it a twist – you controlled the velocity of the paddle, not its direct position. As primitive as it was, Kent’s children gave it a thumbs up.

The week was good for me. I got to learn some things about Eclipse, I got to learn some things about design. We had a couple stretches where we had the "flow" feeling of losing time in the zone. One of the puzzles I’ve been working through is how to take a thin slice of a system; I had some time to think about that.

Would I recommend it? Yes: I learned a lot, and found it great to spend some "renewal time" with others who just wanted to program.

Origins '05 Coming Soon

The Origins ’05 "International Game Expo" is June 30-July 3, 2005. It’s described at www.originsgames.com.

I went last year [’04] and had a great time. (Not sure if I’ll make this year or not.) The place is huge (several large gaming rooms that seemed 100 yards long), with just about every type of game you can think of. (There’s not a whole lot of electronic stuff; more board/card games, wargames, role-playing, etc.)

If you’re used to software conferences, you’ll find it a bargain. I’ve never seen a conference with so many simultaneous sessions (>100 at some hours).

Highly recommended:)

OOPSLA ’04 Trip Report

I'm always struck by how everybody goes to a different conference. This was mine…

10-24-04 – Sunday, and 10-25-04 – Monday

"Usage-Centered Design in Agile Development", by Jeff Patton. This tutorial used a series of exercises to simulate how UCD works.

"Dungeons and Patterns", "Test-Driven Development Workout" – Steve Metsker and I offered our tutorials on patterns and TDD. We also did a session on Framegames for the Educator's Symposium.

10-26-04 – Tuesday

"The Future of Programming", by Richard Rashid. He described several interesting bits of research. One system created a "black box for humans", capturing video every few seconds. SPOT is Small Personal Object Technology, e.g., very smart watches. There will be a kit available 1Q05. He also described research in development tools, for better testing and better modeling.

"Mock Roles, not Objects" by Steve Freeman and Tim MacKinnon. This left me once again aware of how different the mock object approach is from how I do TDD. The design seems more conscious. I don't know how much that's good or bad. It does make dependency injection more natural.

"Systems of Names and other tools of the not-quite-tangible", by Ward Cunningham. He reviewed the idea of mining experiences for patterns. He used System of Names as an example of this, with a very simple Problem => Solution form. He also likes the idea of leaving room for new things: the wiki has a prompting statement for new pages. Finally, Ward reminded us of the importance of being receptive to discovery and integration of new ideas.

"Methodology Work is Ontology Work", by Brian Marick. Ontology refers to the kind of things that exist (philosophically). Brian highlighted Lakatos' philosophy, and suggested that the result is that it's rational to produce a program that seems exciting and spins off results (regardless of its "truth"). (To be fair, Brian pointed out that Lakatos would hate this attitude.)


  • Have a hard core 3-6 postulates.
  • Work out the consequences, and merrily ignore counterexamples.
  • Prefer novel confirmations.
  • Keep throwing off new results.

Brian described a second "trick": use perception to provoke action and reinforce ontology. For example, have Big Visible Charts that show a team where it is; have monitors that go red when tests break.

"Agile Customer Panel" (various).

  • "Customer is not an administrative role" (?)
  • "Customer interaction patterns are simple but difficult" (Linda Rising)
  • "How do we know what has value?" Put it in ridiculous order, and let the customer rearrange it. Tie groups of features to business value, favoring early deployment as proof.
  • Customer prioritization is hard but has the best opportunity for creating high value.

"First courses in Computing Should be Child's Play", Alan Kay. Changing the bulk of people requires a contagion model. Flow as a balance of challenge and ability.

10-27-04 – Wednesday

"Code Complete", Steve McConnell. There are plenty of bad ideas, but there have been advances: higher-level design, daily build and smoke test, standard libraries, Visual Basic, Open Source Software, the web for research, incremental development, test-first development, refactoring as a discipline, faster computers. But – software's essential tensions remain: rigid plans vs. improvisation, discipline vs. flexibility, etc.

"JMock Demo".

"Wiki BOF". Seeding can be important: seeded pages with incomplete ideas, invited guests, no passwords, compelling questions, etc.

10-28-04 – Thursday

"Amazon Web Services", by Allan Vermeulen. There will be computer-to-computer "grid computing" superseding the person-to-computer web computing era. He demonstrated a variety of tools that you can use with Amazon to make this work.

"Outsourcing – How will your job change?" (panel). It's clear there's fear of outsourcing, but it can work. Approaches built around the idea that "they" aren't just as smart as "we" are are misguided and doomed.

"Exocumputing", Jaron Lanier. He tried to suggest different approaches to computing. Computers as built today are very brittle. Perhaps we can try new ways inspired by biology.

Overall, I enjoyed the conference. But it was a lot heavier on philosophy than technique. The thing I'm most inspired to do is investigate what's happening in the Amazon "grid service" space.

Scrum Gathering Oct ’04

The Scrum gathering was a workshop gathered for a couple days in Denver, this past October. We worked in three groups: metrics, process, and facilitation. (Scrum is an agile process. I think of it as approximately the project management part of XP, though that's of course not fair to either one:)

I participated in the facilitation group. (The others were metrics and process.) We spent a lot of our time trying out a variety of simulations and other means to help teams understand what it means to do Scrum. I contributed two exercises: Push Line/Pull Line (a demonstration of lean manufacturing), and Second Agenda [now called "Scrum from Hell"] (a role-play of a standup meeting).

Esther Derby shared a debriefing framework she uses: What/Gut/So What/Now What? "What" asks for objective data about what happened. "Gut" asks for your emotional reaction. "So what" asks for your interpretation. And "Now what?" asks what you'll do next. This framework helps us avoid jumping to interpretation too early.

The process group identified challenges around cross-functional teams, the role of testing, and the challenges of leading or lagging behind (e.g., the analysts want to be an iteration ahead). The metrics group identified metrics as a means of making management comfortable, and created and highlighted various means of helping with that.

I enjoyed this workshop a lot. As always, it's good to meet people and put names with faces. It really helped me feel a sense of community.

On my way out of town, I passed a quotation on a building: "Stay firmly in your own path and dare; be wild two hours a day!" – Paul Gauguin.

Origins ’04 Trip Report

William C. Wake, William.Wake@acm.org, July, 2004
Originally appeared in Simages, August, 2004

(Trademarks are capitalized).

The Origins ’04 International Games Expo (http://www.originsgames.com) is a game conference sponsored by the Game Manufacturer’s Association (GAMA). It was held at the Columbus (Ohio) Civic Center, June 23-27, 2004.

This is a huge conference. It used a lot a lot of small conference rooms and ballrooms, and three cavernous rooms (each the size of a football field). Two of these large rooms were full of tables for gamers; the other was host to a sales floor with about 225 vendors.

As you might expect, there were a huge number of simultaneous events (more than 100 in certain hours). Events were divided into several categories: special events, CCGs (Collectible Card Games, e.g., Magic the Gathering), LARPs (Live Action Role Plays), Miniatures (including the "Origins War College"), RPGs (Role-Playing Games, e.g., Dungeons & Dragons), Seminars, and Tabletop (board and card games).

I tried many games, and had fun with each, including: Freight Train (an easy-to-learn train game), National Security Decision Making (a LARP, though the organizers perhaps wouldn’t like that label), Hex Hex (a "hate your neighbor" card game), Bridge (the classic), Aquarius (a domino-style card game), Cargo (a strategy board game), Yu Yu Hakusho (a CCG), and others.

I took advantage of the vendor’s area to pick up a bunch of games (not all new, but mostly new to me). So far, my family has enjoyed all the ones we’ve played: Aquarius (Looney Labs), Bang (Mayfair), A Dog’s Life (Euro Games), Early American Chrononauts (Looney Labs), Hex Hex (Smirk & Dagger), Killer Bunnies and the Quest for the Magic Carrot (my high-schoolers’ favorite) (Playroom), Sherlock (Playroom), and Trans America (Rio Grande).

WizKids had huge lines for their click-base miniatures. (These build formulas into the figure’s base in a very clever way). But their Pirates of the Spanish Main was even more popular: it’s a miniature "wargame," but you first punch your ship out of a plastic sheet and assemble it.

There were a number of party games (ala Cranium or Pictionary), but none appealed to me very much. There were almost no word games, except Palabra (a rummy-style word card game) and Super Scrabble (with a bigger board and quadruple-score tiles). CCGs and RPGs seemed to be the dominant categories.

This was a good conference. Some of the logistics were tricky for a first-timer, and it was too big to have an intimate feel. But I had a lot of fun, and I learned a lot about the breadth of games that are out there. I’d consider attending again next time: June 30-July 3, 2005, in Columbus, Ohio.

OOPSLA ’03 Trip Report

The OOPSLA conference – "Object Oriented Programming, Systems, Languages, and Applications," was held in Anaheim, CA in October '03.

In some ways, the conference feels more comfortable than innovative. It's nice to see old friends and visit with new people. I got some useful small ideas, but I didn't walk away learning "the next big thing." Regrettably, attendance was down by a fair bit.

One theme at the conference was "Domain-Driven Design." This means different things to different people. One branch is the philosophy advocated by Eric Evans and others, where there's a lot of focus on aligning the way a team thinks and talks about its software. Eric offered an interesting tutorial, in the form of a reading group reading patterns from his book.

I never got a good definitions of the other interpretation, and didn't see enough of it to form a good one myself. What I saw made it appear to be a combination of domain-specific architectures and graphical 4GLs.

Some panels, demos, and talks:

  • Test-Driven Development panel: People have been experimenting with shifting the level of tests and learning when to delete tests. Many in the audience said they were already doing TDD; fewer (but a still significant number) were using tools such as Ward Cunningham's fit testing framework.
  • Dungeons and Patterns, and Test-Driven Development Workout – a couple tutorials I taught with Steve Metsker.
  • Innovate! panel: "What are the barriers? Politics and money."
  • Prevayler demo: Prevayler is a persistence layer for Java. Essentially, you do persistence via transactions that are commands. (The system can replay the commands to re-acquire the current state.) Very cute – I have to try it.
  • Eclipse and the Dark Side of the Moon, Erich Gamma: a brief background and introduction of Eclipse, with a focus on the notions of plugins/extension points, and rules for working with it.
  • Self, David Ungar: A look back at "essential contradictions" in language design, and how Self tries to balance them.
  • Retrospectives workshop, hosted by Linda Rising and Mary Lynn Manns. We worked on the seeds of patterns for retrospectives; I hope these will grow into something publishable soon.

All in all, a good conference. Next year it's in Vancouver, which seems to have been a popular OOPSLA venue in the past.

NASAGA ’03 Trip Report

Last week, I was lucky to be able to attend the NASAGA conference; NASAGA is the North American Simulation and Games Association. The attendees are a mix of teachers, game designers, instructional designers, and others. Not everyone teaches, but there’s a lot of interest in creating experiential learning opportunities.

One theme at NASAGA is the use of improv comedy techniques to improve the way we create experiences. One of the tenets of improv is that you say, "Yes, and." In improv, you’re trying to create a new thing out of nothing. The "Yes, and" rule has you validate the situation someone is offering, and then build upon it.

Another theme is the use of framegames that provide a pre-defined learning structure into which you plug your own content. For example, one team used the structure of the child’s game Snakes & Ladders to provide a learning experience about coaching. When you landed on a square, you were given a coaching situation which you would play-act, and the other players would score it, determining whether you moved forward or backward.

I went to a couple sessions on using computers for simulations. People are using world editors like Unreal’s to create an office environment rather than a dungeon. I don’t think this has reached a usable level yet, but it’s something to watch.

I came out with some new game ideas, though nothing particular to Java. The best quick lesson I got was in the importance of getting a game going quickly: don’t spend a lot of time explaining rules in advance if you can avoid it. For example, enough people know how to play Snakes & Ladders that it’s a waste of time to cover those mechanics. Instead, do "just-in-time" explanations of the parts that are unique.

The next NASAGA conference will be in Washington DC, in October, 2004.