Dojo & Emergent Practices

The video below is from a keynote I did at Devopsdays Atlanta 2022. In it, I describe the concept of “novel practices” through two examples uncovered in dojos I’ve been involved with.

The first novel practice, Architectural Mapping, describes a mashup of mob programming, story mapping and journeys, and the C4 Model of Software Architecture.

The second novel practice, Refactoring with Telemetry, describes a method for combining static analysis tools with long binges of refactoring legacy code to drive conversations around code quality, quality metrics, and the impact a team can have over time in reducing entropy in a legacy codebase.

I continue to use these practices in my coaching today. The dojo is the perfect lab for this kind of practice innovation and real-time adaptation of so-called “best practices.”

Beats in the DevOps Dojo Loop: Plan (1 of 4)

This is part one of a series on how iterations work in a dojo challenge. See Part 2: Do, Part 3: Share, and Part 4: Reflect for the whole story.

A dojo team challenge operates on a quick tempo of cadences the community calls "hyper-sprints." These are short iterations, usually lasting 2.5 days / 2 per week, in which we identify work and the learning we want to attach to it, go after it, share our results with stakeholders and the broader dojo community, and take the result of that sharing into the next sprint. Rinse and repeat. If you're familiar with Scrum or XP, it should feel pretty familiar (if not a bit compressed). That said, there are some important differences in the beats within this loop, differences that support the learning mission of a team.

In this series, I'll cover each of these beats: planning, doing, sharing, reflecting. I'll share some basics on timing but go deeper into each beat with some of the tips, tricks, and hacks I've found useful over the years.

Let's start with "plan."

Plan

The hyper-sprint begins with a short planning session. By short I mean anywhere from half-an-hour to a few minutes. At the start of the challenge, expect a bit longer planning session; the team is coming together with a coach and there might be some valuable discussion or even explanation as the team gets used to the pace of their challenge.

Once you get going, you might not find a need to plan. Right-sizing planning and getting to a minimal-yet-useful balance is a pretty regular learning outcome in challenges.

Finding the Work

In planning, the team identifies which items are important to pursue. These items can be typical delivery-oriented user stories that create value for customers or stakeholders, investments in the team's rig (building pipeline, say), or one-off sessions such as knowledge transfers or walkthroughs given by enablers within an organization ("this is how we provision a new environment in the cloud"). It's all on the table. If there's ongoing product discovery, I ask the team to capture all work in their backlog and plan it alongside the delivery work. No invisible work, as we say.

It's good practice to refer to the team's challenge frame, their product and learning goals, and any discovery artifacts they may have created (story maps & journeys, example maps, event storming canvases, etc.). These artifacts help the team make choices about what's next in iterating on the product they're evolving.

Creating an Iterative Feedback Loop

Another source of inspiration for planning work should come from the "Share" and "Reflect" beats in the loop. It's common to get feedback from stakeholders - clarity or new ideas - that we can take into our planning efforts.

Work-in-Progress Limits & Sizing

I'm a fan of starting with a WIP limit of 1 for small teams (5-7 people) and maybe 2 for larger teams (7+), especially in the beginning. This gives every person and role on the team a chance to see how a particular work item gets done. It also creates a single group for coaching to engage with. As the challenge progresses, increasing the WIP limit is normal.

We don't really estimate in the dojo. It's more sizing. Coaches, ask your team, "do we think this item fits within a single 2.5-day iteration? Two?" Over not too much time, you'll find this natural way of breaking things down leads to smaller, less risky stories.

The Importance of Collaborative Volunteerism

We've decided what to do and given stories enough context to move forward. Now the team decides how to divide things up, who will work on what, and how we'll rig collaboration. We always prefer volunteerism over assignment. Some teams work this way naturally, others need a little encouragement.

For example, if there's a story that leans heavily on development, why not encourage your test automation teammate to join the group working on this? They get a chance to see how development goes down and, most importantly, a chance to elevate their skills. Developers in this situation get a chance to practice valuable social skills for good teamwork – patience, teaching, and taking turns coaching one another.

Playbooks in the Dojo

For our purposes a playbook is a collection of techniques, resources, teaching aids, stock questions, or other procedures used to bring consistency to a dojo coaching practice. Dojos often have a playbook covering parts of the team challenge experience.

I have a love/hate relationship with playbooks.

At their worst, playbooks become scripts or curricula written by the thinkers on behalf of the people doing the work, reinforcing a social structure at the center of a pathological or bureaucratic culture your transformation might aspire to dismantle. An immersive learning experience is not training. We don’t follow a set curriculum. Instead, we focus on building new and usually complex skills useful in solving your real problems which is an act of dynamic and realtime adaptation. There's no scripting that.

Playbooks can help mature your dojo offering into a repeatable product. The two main benefits I've seen are (1) smoothing the onboarding of new coaches in your dojo and (2) providing a useful tool for iterating on your practice.

Leave Room for Audibles

The first play in your playbook should be the "audible." An audible is a term from American football, wherein the offense will change their play at the last minute based on new information. Coaches should absolutely reserve the right to mix up any given play should the need present itself. Senior coaches become good at reading the room and making slight adjustments or wholesale pivots. No amount of documentation can account for the complex social dynamics of teamwork. Coaches should use plays as a jumping-off point and a set of guidelines, not as scripts. H/T to my pal Ed Tilford for introducing this term and concept in one of our larger dojos.

Keep Plays Light and Flexible

Don't let plays become training curricula or rigorous standard operating procedures for teams or coaches in the dojo. Fully scripting an immersive learning experience is a terrible idea on many levels. Tacit knowledge and learning can't be scripted.  

Create New Plays Iteratively and Experimentally

The word "experiment" gets tossed around pretty casually these days. It makes us feel scientific and better or more righteous about what we're doing. When we frame our experiments as plays, we introduce some rigor in our experimentation. Write down what you're trying to do and keep a light log of iterations and pivots to that experiment. Maybe the experiment yields a repeatable play, and maybe it doesn't. An experiment that doesn't go as planned might shake out that extra bit of clarity for the next one that does.

Write and Edit Collaboratively

Don't segregate the play creators from the play doers. Writing a play together as a group of practitioners is a valuable collaboration. The play document itself is a happy side-effect of a team building a shared mental model and negotiating collective meaning.

Use a Wiki

Wikis are the ideal format for a playbook. Wikis have this democratic nature that encourages different forms of contribution. Your team grammarians can tidy while your big idea people work out their thoughts. Plays often have connections with other plays, which begs for the hypermedia format. For example, you may document a more extensive play as a collection of smaller plays. This is the case in whichever chartering or framing technique you use; chartering may consist of smaller plays such as goal setting, taking inventory of a team's skill, etc. Being able to break those plays into consumable and linked chunks provides a nice UX for your play consumers and collaborators.

Use Playbooks in Onboarding & Mentorship

Playbooks are no substitute for good mentorship, but they can help speed up the onboarding learning curve for new coaches in your team. I like to sketch out a light play with new dojo coaches as we prepare for more semi-structured sessions, going through the purpose and timings. It's a good coach-coaching practice.

After we do run a session, I like to reflect on the session and trade feedback notes. Having the original plan provides a semi-objective basis for comparison:

1. Here's what we thought we were going to do.

2. What actually happened? What audibles were called?

3. What worked well? What should change?

Plays as Constraints, Plays as Options

Curate a small set of core plays over time. A great place to start is by looking at the team experience in your immersive learning environment and asking yourself, "where do we want consistency, and where do we want options & choices?" The places where you want consistency (intake, framing, exit) tend to be evergreen, core plays – plays as constraints. The places where you want freedom (most places) tend to be options a dojo coach might offer up for a team's choice based on learning and context.

Playbooks are Never the Point

Perfecting your playbook won't ensure good team outcomes. The focus, collaboration, and alignment of the people in your dojo – coaches, leaders, sponsors, and teams – is where the real value is created. Playbooks give us a nice protocol for tuning and focusing a dojo's evolution, but people will supply the ideas, intellect, and energy that make learning outcomes possible and lasting. As with most artifacts, the complex social processes we engage in to iterate on our playbook tend to have more value than the playbook itself.

Our Remote Dojo Toolchain

We're using Mural for whiteboarding and to simulate the many artifacts we place up on a dojo challenge team's space, Zoom for audio and video, and, depending on the client, either Slack for status updates, integration, and chat to create collaborative environments for immersive learning.

A few things we've learned:

• Mural is incredibly flexible and easy to use. It rivals the in person experience and has many cool features for facilitators. It's easy to do framing/chartering, retrospectives, post up drawings and sketches, run "dotmocracy" moments, model standard work, create a plan for the day, make a team logo, and more. Best of all, it's held up to the punishment of what I imagine is a 10x growth curve. Kudos to the team at Mural; they've done a great job curating a simple set of features that just work.

• Onboarding people to Mural (or any other new tool) is a necessity. That means taking it low and slow and that 15-minute icebreaker might, necessarily, turn into a 50-minute one. I developed a short routine for showing new people the ropes. The main points I hit in a kind of "follow along with me" exercise:

  • Create, colorize, and change cards and other shapes.

  • Navigate/pan to each corner of the canvas and duplicate the card seen there.

  • Zoom out to the whole canvas. Zoom back in.

  • Follow me or another facilitator.

  • Drop a "lucky charm" icon onto a card (heart, star, rainbow, et. al.).

  • Pull up the shortcut drawer (SHIFT+?).

• Zoom breakout rooms are great for splitting into mini-mobs, pairs, and running workshops with breakout rooms. The trick in the remote era is to be prepared. Take time at the start of the day to form voluntary groups. In the case of workshops, pre-assign groups with your co-organizer on the client-side.

• Many things take a lot more preparation to be successful than they do in person. When working remotely, you can't rely as much on your ability to improvise or the group's ability to self-organize. Again: be prepared.

• Editors - 5K or ultra wide screens with 8pt font with line numbers are impossible to see. When you're pairing or mobbing or reviewing, people need to be able to drive at a distance which means they need to see what to navigate to, click on, which app to switch to, etc. If you're don't have line numbers turned on in your editor of choice, it might be time to find and enable that setting. It makes it much easier to talk people on to the line of code you're talking about — in person or remote.

The nature of client work, especially in the enterprise, is such that you usually won't be able to choose your toolchain. This accounts for the crazy assortment of file sharing and conferencing tools I have installed. One day last week I had back-to-back meetings in Skype for Business, MS Teams, Zoom, Zoom (again), and, everyone's favorite, WebEx. That said, most of our clients have been very flexible in either quickly licensing tools or getting licenses to the coaches and challenge teams that need them. If you've ever dealt with enterprise procurement, this anecdote should warm your heart a bit.

DevOps Dojos at Extreme Scale

Learn how we scaled a massive DevOps immersive learning environment at Target in 2015.

DevOps dojos are an emerging trend in companies large and small looking to create full stack teams capable of releasing software continuously. I had the good fortune to join one of the largest, earliest, and most visible efforts in this space, Target’s DevOps Dojo . Did I mention large? 12 concurrent teams, a dozen product and technical coaches, 24 learning events per week, 150+ whiteboards, and infinite stickers. So, yeah, large.

An early definition of the dojo 6-week challenge. This, along with shorter workshop formats called “Flash Builds,” was a marquee offering of the original dojo.

WHAT DO YOU MEAN BY “DOJO?”

Dojos, as a concept, have been around for quite a while now. The word dojo is a Japanese term for any formal training place, most commonly one for martial arts. Classic coder dojos are a proven approach to creating a learning environment based on deliberate practice. Developers find a place to gather, select one or more practices (e.g. test driven development, refactoring, continuous integration), and run through one or more exercises to gain hands on experience.

Exercises are called “katas.” There are many ready-made katas: score a 10-pin bowling game , Conway’s Game of Life , make a program that can’t lose a game of Tic-Tac-Toe , communicate a solution architecture for a given domain , etc. Kata’s present relatively simple problems as a canvas for exploring and leveling up on a technical practice. I continue to use katas in workshops, interviews, and as a way of building and maintaining my programming skills.

Classic dojos and katas are useful, but the Target DevOps Dojo is a different animal. The objective of Target’s style of dojo is to get teams up to speed on continuous delivery in six weeks (12 iterations) and for those teams to carry forward the work after leaving. Target called this a “dojo challenge.” We were hired to help scale this approach, which I’ll cover in a minute. First, let's unpack the anatomy of a dojo challenge at the time of our landing.

A dojo challenge centers on a product team — product manager, coach, and engineers — working together toward a goal of continuous improvement. The challenge bit comes in when we compress iterations to twice weekly, which turns up the intensity of work. During this time the team is supported by one or more expert coaches who bring skill and experience with the tools and practices required to satisfy the challenge. Technical coaches are playing coaches. They are there to pair, ask meaningful questions, provide answers, pull in other specialists when things get esoteric, and ensure skills transfer. Their job is to become redundant.

I think of the Target Dojo’s challenges as more accelerators, but I try not to get too hung up on terminology. The point of DevOps isn’t to get good at Jenkins and Git. The point of DevOps is to create tight feedback loops connecting developer to user. Continuous deployment is valuable because it speeds up learning.

PIPELINE + PRODUCT = FASTER FEEDBACk

When I landed with Joel Tosi, my partner for the gig, we noticed that most teams in the Dojo were creating CI/CD pipelines. Not that creating a pipeline isn’t a valuable goal in itself, but we suggested framing a team’s time in the dojo around the delivery of a small product impact. That is, we introduced product thinking to their already-in-progress dojo model, a subtle but important twist.

When teams base their CI/CD pipeline development on a real effort, their pipeline gets much more realistic and useful. This tactic prevents over-engineering and waste due to speculation. There’s a great side-benefit: teams start learning how to balance continuous improvement while shipping value to their customers. In our experience, the former comes at the expense of the latter, especially in large enterprises.

Moving into practice we introduced DevJam’s collaborative framing technique. During framing, we gather a prospective dojo team and ask a series of questions:

1. What’s your team name and elevator pitch?

2. What delivery and learning goals do you have?

3. How do we know we’re meeting our goals in a six-week challenge?

4. Who cares about value/usefulness/feasibility?

5. What skills are required? Can we pull this off?

6. What are our standards for workflow, quality, and availability?

7. Are you fully committed to your 6-week challenge?

Once down this path, we saw the dojo open up to different kinds of product teams. For example, we ended up working with Target’s Learning & Development team to build training and other educational resources to support their company-wide agile transformation. It was a rewarding experience: focused by a frame, the close quarters collaboration and quick feedback loops of the dojo’s twice a week iterations yielded a much better product in a shorter amount of time.

150+ WHITEBOARDS & THE POWER OF PLACE

The Target Dojo itself occupies an entire floor in one of the buildings on their main campus. The space is dedicated, intentionally designed, and cavernous.

I remember the day the whiteboards arrived. All hands on deck! A half dozen of us wheeled the assembled whiteboards across campus, from one building to the next. From a bird’s eye view, we must have appeared as ants hot on the trail to the nearest picnic.

The whiteboards served a few purposes. They created walls between many concurrent teams. We’d use a whiteboard to place the frame from the beginning of the challenge in plain view. We’d use a whiteboard to self-organize a minimal process appropriate for the work that particular team was doing. We’d use a whiteboard to sketch and refine designs. All the while remodeling and wallpapering the team room for focus and purpose. In terms of team success, moving into a new space engenders focus and opens folks to coaching. They are making time in their busy schedules, coming into the dojo with commitment, intentionally. Teams are ready to do work.

There are a few powerful effects of having a dedicated space that should not be underestimated. The sheer scale of the space sends a clear message: we are all in on the dojo approach. Their leadership bought in, engaged, and supported the effort. From my vantage point, this support wasn’t just the key, it was the keystone.

BACKED BY A SOLID TEAM

My favorite thing about this dojo approach is the close collaboration with the internal coaches and support staff at Target. Close and energizing. Energizing and effective. Experiments went into practice at a startup-like speed.

This fast pace of experimentation is unusual for large corporations like Target. We were given a lot of latitude to ideate and test rapidly, everyone throwing their hypotheses and hard work into the mix. Like all good products, success comes down to the people involved: their skills, their involvement, their collaboration, and their follow-through and commitment.

No matter where you start your scaling journey, make sure you're doing it with the backing of a solid team.