Thanks again for another timely post — hits in exactly with some stuff we’re working through just now.

From the comments, I can see the similarities with exploratory testing although this seems much far reaching. Exploratory testing is still bounded by some sort of canvas (the application) whilst in inception this is pretty much unbounded.

Somehow, this reminds me of the debono’s thinking hats, a systematic way of revealing information. I could imagine a similar wardrobe for deliberate discovery, perhaps Deliberate Discovery dungarees?

I don’t doubt the “learning is a bottleneck” meme has been around for a long time. (I’ve updated the post to add a clarification.) The part I’m interested in is how to consciously impact the shape of the ignorance curve: how to actively engineer episodes that create the right kinds of learning and insight early and continually throughout delivery, such that we are actively aware of and managing the constraint of ignorance. That’s what I’m trying to do with deliberate discovery. I think :)

Yes, exploratory testing feels very much like deliberate discovery as it applies to defect detection. I certainly find it more a fruitful source of bugs than rerunning the same bunch of automated acceptance tests that didn’t fail for the last 300 times.

You can think of deliberate discovery as that idea extended to the whole software development process, continually “debugging” your process and your knowledge in order to deliver more relevant stuff quicker.

I met James all too briefly at Øredev a couple of years ago. You guys have some really inspiring ideas .

Thoughtful post. What you call “Deliberate Discovery” sounds like what I know as chartered exploratory testing — a way to embrace ignorance by choosing a path into the unknown and following it. Testers have always served to “shine the light into dark spaces”, but exploration is a particularly valuable approach to do that.

“Accidentally On Purpose” is the titled for a talk I once did about skills and tactics of exploratory testing to help testers not feel so helpless or flummoxed when reporting their exploratory work to their managers.

In that talk, I mention finding things deliberately (accidentally is fine, too, but I de-emphasize that) by using Session-Based Test Management to frame and guide exploration.

Recently, my brother James and I have come up with something for situations in testing where the environment may be especially chaotic. It’s called Thread-Based Test Management — a more specific strategy to organize and report progress toward activity on themes of what you’re pursuing (“threads”).

I have long believed not enough of us are writing about knowledge work despite chaos, improvisational investigation, or deliberate discovery, so I appreciate your post.

Jon Bach

My thesis with deliberate discovery is that some kind of ignorance is always one of your primary constraints. I believe that if the team develops an instinct for identifying and addressing any area where learning would help (but learning for the sake of improving throughput, not for its own sake, otherwise you just descend into endless introspection and never get any work done!) then your throughput will improve dramatically. At least that’s what (I think) I’ve observed among the most high-performing teams and people I know.

It certainly sounds like a good start! The challenge is then to keep that attitude and nimbleness throughout development, rather than “doing all the innovating at the start.” I’ll put that book on my Some Day list, but I’ll be honest and say my Some Day list is getting rather long :)

Spiking in this context is definitely useful. The challenge is in recognising the diminishing return: going far enough with a spike to learn, but resisting the urge to go further than you need. It’s also difficult to throw stuff away you’ve spent time working on: even though I “know” I was only in it for the learning there’s still an emotional attachment.