TracerBulletsReloaded

From SPA Wiki

Jump to: navigation, search

OT2004 TracerBulletsReloaded

Contents

Hosts: PaulSimmons & RobWestgeest

Many thanks to you all for the valuable feedback to both the workshop itself and to the way we develop software. Of course we would like to run this workshop again, so feel free to enthuse about this workshop to your colleagues but please try to keep some of the secrets in Q1 (below) to yourselves ;-)

For information on previous TracerBullets workshops or related, try here: http://www.agidem.nl/wiki/static/EnWorkshopTracerBullets.html

Your further feedback is very welcome on this page.


Q1. If you had the opportunity to travel in time back to the beginning of the workshop, what piece of advice would you give your team?

Take time to gel the team, introduce yourselves.

Use simple tools.

No advice, it all worked well this time!

Insist on finding a way to make progress, not to get demoralised.

Pay attention to the host's accent, it might help guess what's in the box! Paul: In a way this as just an extension to the richness of information available in the form of feedback. If you widen the gates, more information flows and your team become more informed (think also of those teams that used sound to hear the effect of hitting the object with different items).

Motivation! Overcome "we can't do this" attitude.

One team ran a long planning session in game 2, and this lead to a void of information from the problem space. Make sure you apply lessons that the group learnt from game 1. Paul: this relates to "thinking about the process", it is important to take time to adjust your practices, in this case to plan use of time. One suggestion was to spend a time-token every five minutes, even if one person simply pokes with a stick.

Don't hypothesize over tool design.


Q2: How do you relate what you discovered in TracerBulletsReloaded back to software development?

About the team:

Have a good mix of people, ensure all buy-in to the approach. [ Paul: This is similar to the Pragmatic Programmer's reference to "broken windows" - just one descenter in the team, or one poor component of the software, can bring down the entire team and it's delivery.]

Take time to formalize the team, discover the strengths of team members and how they like to work.

Agree up-front roles within the team and the objective of each iteration.


About the practices:

Don't be afraid to question the [cognitive] model.

"You cannot save yourself from drowning" - ie: a team often needs an external influence to give new direction, or to highlight issues or resolve a problem.

Ask a second opinion on a problem. [ Rob: This holds in general but it has specific value in a context where you are building a cognitive model of something (e.g. thing in the box; new piece of software; problem in software). The fact that it is very difficult to communicate about something new or something unknown screams for several independent views. ]

If you get stuck, recognise that you are not making progress. [ Paul: this is clearly the first step to "righting the boat before you sail off in to the sunset". I think the lesson here is to be more aware of times when no progress is made, ie: to heighten your senses to problems at the process level ]


About the plan:

Pay attention to the timeline of the plan.

Regular feedback is invaluable.

Start with a "real thing", ie: deliver.

"Live with some uncertainties", deliver an imperfect product.


Your comments:


Back to OtTwoThousandAndFourOutput.