XpdWiki: TracerBulletsReloadedWriteup

Line 1 was replaced by lines 1-3

- RobWestgeest should writup the writeup here.

+ This is the writeup for the TracerBulletsReloaded session held at [XPDay3|http://www.xpday.org]. It was held at [XPDay Benelux|http://www.xpday.be/scripts/view.pl/English/FrontPage] as well. You can find that write up [here|http://www.xp-nl.org/Wiki/TracerBulletsReloadedBeneluxWriteUp].

+ !Personal note.

+ Just a few nights before the session started I heard that TomAyerst was ill. PaulSimmons couldn't get time off so that was it: Tracer Bullets' parents where missing. Luckily Duncan was able to stand up from the conference chair and helped me out. Thanks to DuncanPierce for helping me out and to RachelDavies for offering the same.

Line 3 was replaced by lines 5-54

- [{Image src='http://www.agidem.nl/album/TBXPDay3London/imgp2863_Sm.jpg'}]

+ --RobWestgeest

+

+ I'm really sorry I missed this one, I've added some comments at the bottom comparing these notes to my observations from running this workshop previously, and with conversations with Rob. Feel free to add your own comments too.

+ --PaulSimmons

+

+ I was gutted when I got sick and couldn't make it (sorry Rob, I was really, really ill in the end - which bizarrely made me feel a little less guilty about missing it) I'm really pleased it went well. --TomAyerst

+

+ !Session summary

+ In game one both teams were making the mistakes that most people make in previous TracerBulletsReloaded workshops: thinking too much, based on too little information and assumptions. It almost seems to be part of people's nature to do things "right" or "properly". This resembles the current practice in many software projects quite well.

+

+ After time was up the confrontation with the results and an overview of their actions see below most of them smiled and some said "we should have just prodded around immediately!" (in their own words and gestures).

+

+ [timeline game one|http://www.agidem.nl/album/TBXPDay3London/imgp2884_Sm.jpg]

+

+ The teams were invited to pick their favourite practice-cards to plan their initial approach and asked to revisit their chosen practices after each bin-visit. I tried to emphasise ''the way they work'' as the core of the workshop, and encouraged them to step away from the tool/thing-in-the-bin issue from time to time.

+ The teams start with a planning session, and this really helped them to refrain from planning the engineering of their tools. From the beginning of game two, both teams where very concious of how they worked, and both tried to improve that during the game. The teams did not seem to have any of the problems other teams had (from other workshops) in stepping back from the tool/thing-in-the-bin issue. We planned a break during the game to help the teams to step back and think about the way they work - but in this workshop it was hardly necessary.

+ The picture below shows time line of game two. Note the difference with the first time line.

+

+ [timeline game two|http://www.agidem.nl/album/TBXPDay3London/imgp2885_Sm.jpg]

+

+ Team 2 came up with an excellent agile time buying strategy: Buying minutes as long as the other team is not queueing for the bin.

+

+ !Conclusions

+ 1 - "Get data as quickly as possible." Both teams agreed on this one. This is where both teams failed in the first game and improved a lot in the second.

+

+ 2 - "Get information from everyone and pool it." Use all eyes and ears and efficiently sharing that information helps to get a proper model quickly.

+

+ 3 - "Short iterations; keep checking your model with your customer."

+

+ One of the difficult things in software development is the fact that all participants (players) have a model of what is being done and that they are often not the same. One way of aligning all those models is to verify the models as often as possible. ''This is one of the best conclusions I've seen from the workshop, what a great idea to apply back to software projects -- PaulSimmons''

+

+ 4 - "Prototyping and exploratory visit." One attendee felt that building a prototype for software and the 'initial exploratory visit' have similar aims: to build an early common mental model. ''I would add that both techniques (propotype/early visit) can help to disprove a common model too - this is just as important as building one IMO -- PaulSimmons''

+

+ 5 - "Keep feedback loop short. You don't have to learn a lot each time, but you need it quickly." '' To some extent this is a falsification built in to the workshop, but it's nice to see this message comes across in a practical workshop. It's interesting to see just how short this loop can be before it becomes disruptive -- PaulSimmons''

+

+ 6 - "We assume we need a clever tool to solve problems. We don't. Do a simple thing and get feedback."

+

+ 7 - "Leaving it late creates pressure. Don't wait. Get started with something incomplete."

+

+ For the write-up see [TracerBulletsReloaded held in benelux Novemmber 2003|http://www.xp-nl.org/Wiki/TracerBulletsReloadedBeneluxWriteUp].

+ ----

+ Other comments (Please mention if you attended)

+

+ I am, perversely, pleased to see that people do behave in the way we expected they would when we thought up the workshop. I start worrying in the lead up to the workshop thinking that the aim will be too obvious and it will waste peoples time. We now have three workshops worth of evidence that even with people who are interested in agile methodologies they exhibit similar behavious. As Paul and Rob note, people seem to generate models (and theories) and then put off testing them for as long as possible, rather than testing them.

+

+ Kudos to Rob for getting the workshops on the road again and to Duncan for stepping into the breech (and Rachel for volunteering). --TomAyerst

+

+ ''One of the attendees said at the end something like "I work in an XP team, I understand Agility, and I can't believe the mistakes we made in the first game. We should have known better!"

+

+ Either people who come into IT naturally think this way, or people who work in IT for a while become innured to thinking this way, or ''all'' people think this way! I see evidence from other fields of endeavour that it is the latter. That seems to me quite a profound conclusion: you can be trained and habituated to considering all the 7 points raised and still lose sight of it all as soon as you stop explicitly thinking about your process, or, in smaller picture terms, the approach you are taking to the problem at hand. --DuncanPierce''