Do
A dojo team spends most of each iteration doing real work. It works slow and low at first, because the point is to notice how it works, not just to finish.
Overview
Do is where the Dojo Loop spends its time. A product team that conceives, builds, and owns its product does a wide range of work here: framing a problem, researching customers, sketching an experience, test-driving a design, refactoring tangled legacy code, onboarding to a cloud platform, or adding security scans and deployment stages to a CI/CD pipeline.
Each iteration balances two goals. You want the learning spread across the team, so more than one person can do the new thing. You also want real progress on the product. Learning for its own sake isn’t the goal. The goal is a more capable team that ships.
Coaches show more than they tell. “Can I show you what’s worked for me?” earns more than a slide.
Collaboration Forms
There are many ways to work together in the dojo. These four come up in almost every challenge.
Mob programming
Mob programming is the daily driver. The whole team works one problem at one computer and rotates roles. The navigator directs and the driver types. Mobbing levels the field between novices and experts. Unsure? Take a turn driving. Confident? Navigate, and teach while you do it. It also builds empathy for other roles quickly.
Dual-track discovery and delivery
An autonomous product team owns discovery and delivery at the same time. In the dojo that often means the mob builds a validated feature while the product manager, designer, and engineering lead validate the next one. That gives a WIP limit of two: one discovery mission and one delivery mission in lockstep. See Multi-Track Discovery & Delivery.
Set-based design
When the team disagrees, and no option clearly wins, build both. “Try it both ways for a day and compare notes” ends arguments that would otherwise eat a week. That’s set-based design. For early UX work, run a design studio: everyone sketches, the group critiques, and small groups converge.
Research spikes
Some work doesn’t suit synchronous collaboration, and research is the usual example. Frame the spike with pointed questions so it doesn’t turn into wandering. Then have whoever did it present findings to the team. Presenting is a skill too, and the dojo is a safe place to practice it.
Resources
- Dojo Loop — the full cycle
- Mob Programming — the default collaboration form in the dojo
- Pair Programming — the two-person version
- Share — what the team does with its output