Saturday, December 17, 2011

Uncommon way of managing ET #01 - Scouting

tl;dr – skilled, supported, concentrated exploration

The team makes one person* the dedicated explorer for a period. This person, who we’ll call The Scout, spends all their time exploring. Their job is to find as much interesting stuff as they can. They’re supported (and watched) by others who set up environments, log bugs, keep notes, analyse data, suggest and configure tools. Pay attention: These supporting people are not part-time or less skilled; they’re just as engaged as the scout, but they’re not on point.

There are no sessions or formal session-end debriefs, but the team will want to stop and sit back from time to time and come to some conclusions about what they’ve found. The person (or people) on point are switched around regularly – scouting is fatiguing, and diversity is important. People with different specialities are used as required, and The Scout need not be a tester.

Exploration often has a sense of a frontier, a boundary between the known and unknown. The frontier is fundamental to exploration, and The Scout pushes it ever onwards. We understand, of course, that testing has really wiggly and sometimes discontiguous boundaries, and that the territory behind the boundary may not be well-known, and is likely to change unexpectedly. The team will understand this boundary better than anyone else, and will need to come to an understanding about how much they need to be able to notate and share information about the frontier.

This approach is all about discovery. It’s not cheap, nor is it exhaustive, but it is valuable. The project gambles time in return for information, so The Scout needs to know what the project is interested in. I expect there would be tussles about what The Scout would be exploring, and what they would be looking for. So much the better.

Note: This an idea. I’ve not worked (quite) like this. Maybe, though, this idea triggers something that you would like to try with your team. Let me know how you get on.

* or one group, but I’ll write in the singular to keep the grammar simple


  1. I have been in test teams that have used a similar method with great results.
    One person had no responsibilities except pursuing anything she/he felt needed investigation. This role rotated every week.

    We called it "free Brolin-role", named from 1994 Soccer World Championship.
    Sweden had three attackers in great shape, so coach Tommy Svensson put Tomas Brolin as a winger and told him:
    "you are free to go anywhere on the pitch, act as forward, fetch balls in defense, squander the midfield, be creative and do those magic things we know you can do."
    Brolin was terrific and got a place in the best 11 of all teams; the whole team played better than ever, and Sweden won a surprising bronze.

    Trust works very well also in software testing.

  2. I think that ET (currently) attracts free agents, so people already doing ET may well innately possess the broader improvisatory skills to take advantage of the full playing-field.

    Thankyou for providing not only a concrete instance but also a fine metaphor.

    I'm with you on trust - it's axle-grease for teams, of whatever stripe.

  3. At a previous employer of mine, we used to do Exploratory Testing (with SBTM) in pairs where one tester was lead and a second tester acted sidekick and took notes and gave creative input to the lead tester. Your idea is taking that quite a few steps further, and I like it!

    Great post!