Introduction

Long-term commitment to new learning and new philosophy is required of any management that seeks transformation. The timid and the fainthearted, and people that expect quick results, are doomed to disappointment.

—W. Edwards Deming, Out of the Crisis

“The coupons still aren’t working. The test cases are failing. Your code is wrong!”

“Your testing script is wrong. The code is written to spec. If you have a problem, go talk to the business!”

Joan, the payments team leader, rose from her desk and went to see what the commotion was about. One of her team’s developers was facing off with one of the test engineers in the hallway. The test engineer rolled his eyes and shook his head at the developer. When Joan asked them what the problem was, the tester said the new coupons still weren’t working correctly, but that the developer kept rejecting defects in the defect tracking system. They were at an impasse.

Joan was questioning her decision to accept the promotion to team leader she’d taken a couple months ago. She had been up late the previous night with her developers and people from operations trying to get their code deployed in the staging environment. Now it appeared the code was wrong and she might have another late night ahead of her doing another deployment. That assumed they could get one of their business partners to clarify how the coupons should work and get the code changes made today. As if that wasn’t enough, she had a meeting in the afternoon with the stakeholders to explain why they were so far behind schedule. At a minimum, they were looking at another day of delay.

She was extremely frustrated. The codebase her team had inherited made it difficult to add new functionality with any kind of code quality. They rarely met delivery deadlines. Even though her company had sent hundreds of people through Agile training that advocated for cross-functional teams, her part of the organization was still siloed, with separate development teams and test teams. She couldn’t put together a team with the skills she knew would address at least a few of their problems.

Even worse, new features weren’t having the impact in the marketplace the business wanted. Her developers wanted time to clean up technical debt in the codebase, but the business just wanted more features faster, hoping they’d somehow achieve product/market fit. On top of all that, the organization mandated that all the services her team owned had to be moved to the cloud by the end of the year.

Something had to change.

Joan believed in her team’s abilities, but she wasn’t sure how they could make improvements with all the pressure they were under to constantly deliver. A few of her developers had attended a test-driven development course but that didn’t seem to go anywhere because they’d had a hard time applying what they learned to their legacy codebase. There were several other two-day training courses her team members could attend, but she was skeptical there would be any real long-term impact.

She’d heard rumblings that her company had recently hired a new director of IT transformation and that he was creating something called a dojo to help teams get better at building digital products. She decided she’d look into it.

Does Joan’s story sound familiar? Read on.

What’s a Dojo, You Ask?

A dojo is an immersive learning environment within an organization where product teams learn new skills and new ways to solve problems. Teams apply those skills immediately to their work in the context of their real-world constraints and challenges. “Dojo” is a Japanese term for meditation halls and martial arts studios. It translates literally as “place of the way.” In the tech industry, dojos are pointing the way to better products and methods, and more effective problem-solving and learning within organizations. Dojos are leading organizational and cultural transformations.

Unlike traditional training where individuals or teams go to a conference or seminar, or external consultants come into the organization to conduct workshops, a dojo is a space unto itself within an organization, run by dedicated employees of the organization. It goes beyond the in-house training centers that teach one-off skills.

A dojo is an investment for the organization—in people, space, and time. For small organizations (with, say, less than four or five product teams)—a physical dojo space may be overkill, but the approach to learning presented in this book still applies.

For large organizations, an investment in a dojo starts with an honest conversation around whether a dojo can meet the needs of the organization. This ultimately comes down to whether there is executive-level support for evolution through learning. If your leadership believes in investing in your people and giving them time to improve their skills, then you are ready to start looking into a dojo. On the other hand, if leadership believes in a guaranteed transformation through large consulting firms with fancy frameworks telling you what to do—well, history tells you how that story ends.

When an organization invests in a dojo, it becomes an attractor for new talent. Perceptions about the company shift within the development community. People recognize the company is doing something new and interesting. More importantly, it becomes clear that the company is investing in developing their people.

If you decide to add a dojo to your organization, you probably have people who can fill the various roles in your organization already. You might have to hire outside consultants in the beginning to get your dojo up and running. But let’s not get ahead of ourselves—you’ll learn the answers to all your questions in the upcoming chapters.

Your Next Question Is, Who Are We?

We’ve been working in the learning and digital product space for the past two decades as both developers and coaches. We’ve been helping organizations set up and launch dojos since 2014. The examples you’ll read about are culled from our experience, although we’ve changed details to protect the identity and privacy of the companies involved.

Our approach involves solving problems holistically and isn’t limited to writing better code and using better technology. It includes focusing on creating better products and fully engaged teams, all while fostering deeper, stickier learning. We believe the challenges to creating great digital products go beyond technology. When we work with teams, we address practices across the entire product development value stream.

A Holistic Approach

Teams are faced with a conundrum: they often want to reduce delivery times, improve technical quality, and create products with a better product/market fit, but they must slow down to learn the practices that will improve their product development capability.

The dojo takes a holistic approach, bringing together cross-functional teams and placing them in an immersive learning environment. Teams learn new practices and how these practices tie together. Unlike traditional training where practices are learned in sandbox environments with canned examples, teams learn within the context of doing their real-world work, where constraints come into play. Learning becomes part of what teams do, as opposed to a special event.

The Six-Week Dojo Experience

Joan sought out the director of IT transformation, who put her in touch with us. In our early conversations with Joan and her leadership, we backed her up in her desire for creating a cross-functional or full-stack team—at least for the time they’d be in the dojo. This new team would have all the necessary people to deliver a digital product. We guided Joan to assemble a team that comprised not only developers and testers, but people from the business side of the organization who understood the product being developed, designers, and people from operations.

Although the team members were all employed by the same organization, they had never actually worked together as a unified team. Coming into the dojo was going to be different—the team would work together all day, every day, for the next six weeks.

We began the first day by starting to work with product discovery practices. This surprised them. They had expected the dojo to be another training where they learned about technical practices or focused on process minutiae. The team member from operations couldn’t understand why he was being asked to participate in product discovery. The whole team was skeptical about our methods. We asked them to indulge us for a few hours, and if they didn’t find the product discovery practices valuable, we’d jump into technical practices.

Within the first hour, the team started a discussion that clarified their understanding of the product needs. For perhaps the first time, the domain experts, engineers, and testers were having a direct conversation...