Scaling a DevOps Dojo at Target

In 2015, Target ran one of the largest and earliest DevOps dojos anywhere: twelve concurrent teams, a dozen product and technical coaches, twenty-four learning events a week, more than 150 whiteboards, and an endless supply of stickers. We joined to help scale it.

The Situation

Target’s dojo was a different animal from the classic coder dojo, where developers gather to practice a technique on a kata like a bowling-score calculator or Conway’s Game of Life. Target’s version was a dojo challenge, the experiential learning model we still run. A real product team, with a product manager, a coach, and engineers, moved into the dojo for six weeks and twelve iterations, with a goal of reaching continuous delivery and carrying the practice forward after leaving.

The iterations ran twice a week, the cadence described in the Dojo Loop. Technical coaches were playing coaches. They paired, asked questions, answered them, pulled in specialists when things got esoteric, and made sure skills transferred. Their job was to become redundant.

When we arrived, nearly every team in the dojo was building a CI/CD pipeline. That’s a worthwhile goal. It was also the wrong frame.

What We Did

We pointed each team’s six weeks at a small product impact, and let the pipeline follow from that. A pipeline built to ship a real change comes out realistic and useful. A pipeline built in the abstract gets over-engineered against problems nobody has yet. And the team learns the harder skill along the way: improving how it works while still shipping to customers. In a large enterprise, the first usually crowds out the second.

To make that stick, we brought in our framing technique. Before a challenge began, we gathered the team and worked through a short set of questions:

• What’s your team name and elevator pitch?
• What delivery and learning goals do you have?
• How will we know we’re meeting them in six weeks?
• Who cares about value, usefulness, and feasibility?
• What skills does this take? Can we pull it off?
• What are our standards for workflow, quality, and availability?
• Are you fully committed to the challenge?

Once challenges started from a frame, the dojo opened up to teams that weren’t writing services at all. Target’s Learning & Development team used a challenge to build training for the company-wide agile transformation. The frame, close collaboration, and twice-weekly feedback gave them a better product in less time.

What Made It Work

The space. The dojo filled an entire floor on Target’s main campus. The whiteboards arrived in one delivery, and half a dozen of us wheeled them across campus between buildings. Those whiteboards walled off team spaces, held each team’s frame in plain view, and carried its process, its designs, and its sketches. Moving into a dedicated room made teams more focused and more open to coaching. They had cleared their calendars to be there.

The signal. A space that size told everyone the company was all in. Leadership bought in, showed up, and backed the effort. That support was the keystone.

The team behind the teams. We worked side by side with Target’s internal coaches and support staff, and experiments moved at startup speed. Big companies rarely give outside coaches that much room to try things and drop what doesn’t work. Target did, and the dojo improved because of it.

The point of DevOps was never to get good at Jenkins and Git. It was to put developers and users in a tight feedback loop. Target’s dojo got there once teams stopped treating the pipeline as the goal.

Resources

• Experiential Learning — the engagement model a dojo challenge runs
• Dojo Loop — the twice-weekly iteration cadence
• Framing — the chartering practice we added to the challenge
• Shifting Left to a T-shaped Team — one team’s experiment inside a dojo challenge