tl;dr – exploration every single day works wonders
Every day, one person explores for 90 minutes, allocating a further 30 minutes to bug logging, diagnosis and follow-up conversations with others involved in the product. The whole team gathers for a 5 minute briefing on the day’s exploration, where the explorer talks about areas covered, concerns and interesting discoveries. Anything is open for exploration; the configured and working product, its data, a group of requirements, known bugs, user manuals, the production trouble logs.
Some days, knowing the area under exploration, the news would be keenly awaited by all. Some days, there would be nothing new to report. Some days, the approach to the exploration would be far more interesting than the results.
The team might include the briefing in a daily standup. They might decide to be briefed first thing in the morning on what had been found in the previous day. They might choose the next area of exploration at the end of the briefing, allow the explorer to be directed by a someone who steers, or give the explorer the initiative. I expect that there would be a big, visible and public compendium of untried ideas.
The time given to exploration is predictable, and should not be seen as a minimum or a maximum, but as a regular activity. The more stable the product, the wider the exploration, the more unstable, the more that the collective exploration will reflect the overall assessment of trouble areas. The group learns as a whole, and individuals learn to take a step beyond the group’s expectations. I expect that individuals would look forward to taking their turn as the explorer, and that the team would rarely keep the same explorer from one day to the next. While competitiveness will lead to diversity and excellence, it stands a chance of causing individuals to hide some of their approaches until they become the explorer. Whoever is managing the team will need to take care to temper competition with shared purpose.
The regular and relentless expenditure of a fixed duration, and the expectation of team scrutiny would encourage each explorer to take a concentrated approach in a fruitful (and so potentially novel) direction. This is an approach to exploration (rather than to testing). It works best if interesting parts of the subject of exploration can be reached swiftly – but as easy parts to reach are exhausted, people will think of new things to explore, or construct mechanisms to get them to a new point of exploration. Collectively, their explorations would be more diverse than might be achieved by a single explorer or dedicated scout. If ever the whole team found they had exhausted their stock of new ideas about what to explore, I would use that as a trigger to ask whether we needed more tools, more skills, a more stable set of artefacts to explore, or whether we knew our application really well.