Recent changesContact the site administrator
Home
TracerBulletsReloadedBeneluxWriteUp

Thanks to all those who attended TracerBulletsReloaded, we all learned a lot from the workshop and this is a brief summary of our conclusions. This is the wiki for attendees to add their own comments. Feel free to email us directly if you wish to make private remarks.

Summary

TracerBulletsReloaded is a simulation in which attendees play two games to explore the idea behind the concept of TracerBullets, tracking their progress and relating their findings to the process of software development.

We observed some interesting parallels with software process - we saw one team book a long possession time at the "bin", thereby blocking the other team from playing. This competitive action can be seen in real software companies where teams use competitive edge to their advantage! It was also a sign of "panic" towards the end of the time limit, just like a project deadline when standards drop.

We also saw one team have a "collective depression", when they could not think of new ways to play the game. With a little encouragement, they were able to build a brilliant tool for the game, albeit a little too late. We learnt that a little coaching here and there can get a team back on track, but timing of the coaching is crucial to success.

For game 2 we encouraged the teams to think about how they were work by inviting them to choose their favourite practices from a stack of index cards we supplied and to revisit the list periodically during game 2.

As shown in the pictures below, the teams made much better use of their bin-time in game two:

(Click images to enlarge).

Team one noticed that one member had discovered some information early which the team had not used in their mental model. They could have verified the validity of this information, and used it to improve their model.

Team two felt they over-engineered their tool, and that they didn't gather enough information - there was pressure to save time which had the effect that they used it too sparingly.

Conclusions

"Verify information from the whole team and test any inconsistencies". This came from team one - they learnt they should verify all information, even if it seems wrong. Validating helps to improve their mental model.

"Gather plenty of information - do not take an engineering approach". Team two felt that all information is important, no matter how broad and inaccurate.

"Stepping back from a problem and taking time to reflect on the process is difficult."

"finding out what's in a bin without peeking is difficult ;-)"

Very rapid feedback appears to be very useful for converge to a solution - the "competitive" action from team two.

How easy is it to think that thing will not work before trying them. How tempting is it to think, lets make the tool right first before doing the next move at the box.

"Apply feedback without mental model of the system is impossible."

"Having the wrong mental model to apply feedback to, will not help you."

Finally

Click this photo if you want to know why she smiles.

Find more photos here .

A similar workshop was held at XPday3 in December 2003. You can read about this here: XPDay3TracerBulletsReloadedWriteup

Informatie Brains4all