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.
This would be an interesting technique to try. How do you decide each day what area to explore? Would it be some part of the app aside from the user stories the team is currently working on?
ReplyDeleteIf* I had (as above) a "big, visible and public compendium of untried ideas", and "anything was open for exploration" – and also felt that that the team itself would most often come to the best decision about what to choose (not explicitly mentioned above), then I would leave it up to the team to choose.
ReplyDeleteIf the team were using user stories, I don't think I would expect them to avoid those stories – yesterday's coverage might well have exposed something that the team would want to explore today. When I've used user stories, those stories have been generally about acceptable behaviour, and testing around them has been typically confirmatory. If the current crop of stories can be used as a rough indication of the elements that have the greatest churn, I might well lobby for a more detailed exploration of those new areas that had been simply confirmed as working. I'd want swift feedback on those changes.
However, to restrict just to areas around user stories leaves us exposed to risks that we've artificially restricted the diversity of our approaches. I want the explorers everywhere - the requirements, the manuals, influential internal tools, relationships. Exposing taboos around what cannot be explored is itself useful. I've seen excellent exploratory work that I wouldn't call testing (although some esteemed colleagues might). This is a way to approach managing an exploration on the project. I guess that it's unstated that the exploration is has greater potential when critiquing the product (and so by necessity the project) – but that potential is a result of balancing to the generally constructive and confirmatory approach that is necessary when building and inventing.
I expect that - as an exploration - this management approach would allow ET to expose the expected useful information, but that its most significant influence would be through secondary degrees of information about the product and how the project is building it: when times are tight, exposing the areas that collectively are of concern; when times are interesting, exposing the novel or swift ways to reveal low-hanging bugs; when times are slow, diving into diversity of what and how to explore.
---- Post scriptum ----
* Sometimes, all these things are true. Sometimes, one can't share test ideas publicly, one is restricted to a subset of testable artefacts, or one does not believe that the team are in a position to make good decisions about its next steps. If I had to make the decision alone and blind about where those precious 90 minutes should be spent (and I've been put an that unpleasant situation from time to time), I would use any knowledge I had already gleaned about the state of the project and about the use of the product, grab hold of my experience of triggering trouble and observing pathologies, and mix all that up with (for instance) Elisabeth Hendrickson's excellent Cheat Sheet, one of my usual frameworks, some of of Rikard Edgren's Test Ideas from his Little Black Book or one of RST's many heuristics, and prioritise – in that unfortunate situation – by gut feel.