Dojo Discovery Sprint
Author: Kevin Burns, DevJam Dojo Coach with help from the Thomson Reuters’ Litigation Analytics dojo team.
In the spirit of continuous improvement, we saw an opportunity to improve our dojo experience for teams that want to test their product ideas (and their designs) before committing to building them. The Thomson Reuters Litigation Analytics team wanted to validate that their ideas (and their designs) resonated with customers before implementing them. After discussing options for how to do this with the team leadership, we decided to conduct a Discovery Sprint in the dojo before moving into software development.
Traditionally, one of the biggest goals of the dojo is to help teams become more effective by experimenting, learning, and adjusting their workflow practices while delivering their backlog. This mostly includes decomposing what they already have in their current backlog into work items deliverable within two days. Many teams find it challenging to break-down their work into two-day increments which is why we experiment with the concept in the first place. It also emphasizes increased cross-functional team member collaboration and light-weight workflow management practices. By doing this, team members work more closely together to focus more on the value their software is delivering than on the process overhead associated with delivering it.
In contrast, the week-long Discovery Sprint focuses the team on idea and design discovery more than delivering the next software increment. In many cases, it’s hard to know, with a high degree of certainty, what the next most valuable software work is when the ideas and designs haven’t been tested with real customers.
A Discovery Sprint allows us to test our ideas and designs, with real customers within a week. In the case of the Litigation Analytics team, we wanted to get feedback from customers regarding two big ideas. We allocated a week for each idea, and their respective prototype designs, before we conducted the customer interviews. This allowed us enough time to build realistic prototypes that we then tested with real customers in the third week.
The team’s deliverables during a Discovery Sprint aren’t working software packages for production but rather a prototype used to conduct customer interviews. This allows us to discover and learn whether our ideas resonate with our customers and whether our designs are intuitive to them. Once we have feedback from customers, we can more confidently move forward with feasibility, solutioning, and software implementation expected to have a positive ROI.
Teams move from ideation to prototyping to customer interviews in one week. In the case of Litigation Analytics, it was two weeks because they had two big ideas to test. This rapid feedback loop allows us to focus on building the right thing (and less of the wrong things) and building it right.
The team expressed how valuable it was to have the first two days dedicated to learning from business and operational experts (not just from the Product Owner). We learned about the challenge’s customers have doing this type of research and explored options that might help them find expert witnesses quickly and easily. Having multiple stakeholder experts walk us through real scenarios was eye-opening. It gave us a shared understanding of the current state and the challenge in front of us. This set the foundation for a common understanding of what our customers are trying to accomplish and how our application helps them accomplish it. It also exposed gaps in our data and how our information is displayed. This helped us prioritize our backlog.
The team appreciated how we dissolved roles and silos of knowledge by working in small cross-functional teams to sketch and design solution options in a dedicated, co-located space. It was very valuable and productive to have ideas from business, tech, and UX for diversity in concepts. Decision making with a collaborative approach, combined with a decisive product owner, helped the process move quickly.
Positive impressions from Dojo and Discovery Sprint heard at retro:
“I wish we could work like this all the time”
“Great team work and collaboration with business”
“Having business experts come explain what they do was very valuable and huge learning opportunity…it allowed us to build deep understanding of product quickly”
“I loved how we removed role divisions…ideas come from everyone, not just the business”
“Removing distractions was very valuable”
“While there are maybe 100 things we could have done differently or better, it was undoubtedly one of the most rewarding and exciting experiences I can remember.”
Characteristics of teams that should consider doing a Dojo Discovery Sprint in the Dojo include:
Teams with big ideas but aren’t sure if their ideas resonate with their customers.
Teams that have big ideas but aren’t sure how best to design their implementation.
Teams that are testing new products and/or new markets.
Characteristics of teams that benefit less from Dojo Discovery Sprint but still benefit from Dojo experience include:
Teams that are more than 50% focused on production support and defect resolution.
Teams that have a very high confidence interval (80% or better) that their product ideas’ (and their designs) have a positive ROI.
Bottomline:
The less confident we are, and the more unknowns we have, regarding the value of our ideas and their designs, the more valuable the Discovery Sprint is in helping us deciding what we should move forward with and how we should design it.
References:
The Sprint Book
Thesprintbook.com
Sprint Checklist
Monday Morning Slide Deck Intro
Nordstrom’s Discovery Sprint Video
