Beats in the Dojo Loop: Do (2 of 4)
This is part two of a series on how iterations work in a dojo challenge. See Part 1: Plan, Part 2: Do (this post), Part 3: Share, and Part 4: Reflect for the whole story.
Planning was over and it was mercifully short and maximally productive. Now it's time to get to work. It's time to let your action bias run rampant.
When I think of a dojo challenge, I think of an action bias. Working, in the beginning, very consciously, slow and low. Why are we doing the things we're doing? Coaches that show way more than they tell. May I show you what's worked well for me in the past?
The majority of our time in a dojo challenge is spent doing real work. That is a team working to frame actual problems and solve those problems with some new tactics we're learning. Given a product team that does it all (you conceive it, you build it, you own it), that can mean a wide variety of things:
Product stuff: Framing a new problem for innovation. Doing research on customers or competitors. Envisioning a customer's journey through an experience that involves your apps and services. Prototyping and sketching new user experiences. Mapping a proposed feature in the landscape of the user's workflow and environment.
Software Engineering stuff: approach design in a new way, perhaps test-driven. Refactoring mercilessly, without guilt. Creating more maneuverability in heavily coupled, legacy code.
Cloud stuff: onboarding a team to a new PaaS or set of services on AWS, Azure, Google Cloud, etc. Getting the team familiar with new cloud-friendly architectures: containerization, lambda functions, etc.
DevOps stuff: building or evolving a CI/CD pipeline: adding automate test runs, security scans, pushing artifacts to a repository, and deploying services and apps into varying levels of environment from test all the way to production.
How a team rigs themselves to (A) acquire a few new skills on their journey to total product ownership & autonomy and (B) make progress on their product team impact of choice is a balancing act. On one hand, we want to spread the learning across team members, to enable several people on the team. On the other? We want to feel real progress! We're not learning for learning's sake. We're learning to become a more capable team.
It's Collaborating Time
There are several go-to tactics when it comes to doing collaboratively in the dojo. Each of these is it's own fractal rabbit hole of practice, so I'll lay a few out here – what they are and in which contexts they work best – with a few resources I've found to be helpful.
Mob Programming
Mob programming – everyone sitting around the same computer, focused on the same problem – is the "daily driver" of dojo collaboration. In this, we'll pick a story or technical task we want to accomplish and take turns switching roles. Someone will navigate or direct the work while another person takes a hand at the keyboard as a "smart input device," taking their cues from the navigator. Other folks in the mob can chime in, but it's ultimately the navigator's choice on where to direct the solution.
From a learning perspective, mobbing really helps level the playing field between people new to a topic and more expert practitioners. Aren't totally confident in what you're doing? Take a turn as a driver. Have a lock on it? Navigate your teammate on to an approach (navigator as teacher). Oh, and it's a great way to cultivate role empathy, mechanical sympathy, and general humility.
Mob programming is a big topic with lots of nuances and ways to bend it to your situation. At some point I'll share our defaults of how we get started with it, but, if you want to know more there's no better place to start than with Woody Zuill's excellent talks on the subject and Chris Lucian & Austin Chadwick's YouTube show, the "Mob Mentality Show".
Dual Track Discovery & Delivery
If we're building product teams as fully autonomous teams, that means they'll be accountable for product discovery and delivery simultaneously. Teams may be stacked with product manager and designer roles working alongside their counterparts from engineering. In turn, this means that at any given time you'll have discovery or refinement on the current product impact proceeding simultaneously with delivery we're more certain about. Enter dual track discovery and delivery.
The flow of a cross-functional product team engaged in dual track, as described by Marty Cagan:
The Discovery track is all about quickly generating validated product backlog items, and the Delivery track is all about generating releasable software. [...] the work flow is not characterized by each role delivering artifacts on to the next step; rather it is collaborative – the product manager, designer and lead engineer are working together, side-by-side, to create and validate backlog items.
In the dojo, we may have one team mobbing on a feature we've validated during discovery while a product manager, designer, and engineering lead are concurrently validating the next feature up, perhaps even using data from a previous delivery to make decisions. This would mean, in our dojo challenge, we'd have a WIP Limit of 2: one discovery mission happening in lockstep with one delivery mission.
Set-based Design
This oldie-but-goodie comes from the world of lean manufacturing. In set-based design, when faced with a problem with multiple solutions in which one doesn't stand out as the obvious winner, set-based design emphasizes exploring multiple options until such a time as the best candidate emerges. In short, try multiple designs until you get a winner.
I like to use this when there's disagreement in a team. "Ok. Why don't we try both ways for a day and compare notes?"
When we're doing early discovery in the dojo on a product that has a user experience component (most things), I like to facilitate the group through a design studio workshop. In this session, individuals produce a number of sketches which we then critique and review as a group, followed by converging the ideas within small groups, and so on. It's a wisdom-of-the-crowds approach to generating a lot of ideas and synthesizing a team's best ideas into a plan.
Research Spikes
Some work doesn't lend itself to synchronous collaboration. Research has been one of those things for me. Normally, given some uncertainty around feasibility, I'm going to search the internet, read some books, drain some forums, etc. How we learn novel things, I believe, is an intensely personal process. Then again, there's disciplined and pointed research and then there's wandering around in the weeds.
From a dojo perspective, when a team identifies a research need, I like to frame the research with some pointed questions. What, exactly, do we need to know from this research? Whoever takes this on, I like to work with to present findings back to the group. This becomes a chance for individuals to practice important social skills such as presentation, communication, and responding to feedback & criticism.
Enjoy the Doing
There's really no end to the collaborative forms. Some coaches will have a lot of experience and comfort facilitating some of the well-known, named methods as I mentioned above. That's great, but not entirely necessary. The more important things are that we learn while doing, that we share those learnings across the team, and we give people a chance to try things for themselves either to fortify their own, individual skill set or gain empathy for the contribution a teammate brings to the party.
As a coach, I'm paying close attention to the energy this collaboration brings. Learning, beyond being a competitive requirement in modern work, should be a thrill. Growing your capabilities is improving your team, yes, but it's also making you more valuable, a more powerful contributor. Enjoy the doing!