The Dojo with Joel Tosi and Dion Stewart

Alrighty, so key thing Dojo is an immersive learning experience. And the value from it is repetitive practice. So we take them out of their normal environment. We put them into a cool space for six weeks. The coaches are in the room with the people doing the work for the whole period. And then you talked about the idea of technical coaches who know how to do the craft and agile or product coaches who tend to look at the ways of working. 

And then within the six week cycle, you had a typical flow, which was two weeks being really engaged guiding, then two weeks where you help them but observe a lot more and then two weeks of hands off, where you’re only there if there’s a problem. 

And then they learn while doing repetitively. And that came back to this idea of two and a half day iterations or increments. So that allowed us to have 12 of them in six weeks. So that repetition helps us learn, helps us apply, helps us iterate, helps us get value out of it. And two day increments highlight dependencies, it highlights waste, it highlights bureaucracy and lack of communication, hierarchies, all those things that we know are embedded in the system, but by shortening the cycle, they stand out. 

And then you’re often looking for the patterns that team are not adopting and then suggesting they adopt them and then getting them to repetitively practice it and see if they get any value from it. And you’ve already got patterns from across all the other teams so you can actually reuse them for this team. And it also allows you to look holistically across the value stream. So great example of the dev team and the QA team coming in. And now you’re starting to see two steps in that value stream, even though they’re separate teams. 

One of the patterns that’s really important is this concept of chartering. There’s a whole process around expectation. And the key thing there is you’re setting expectation that the benefit of the Dojo is learning, not what you’ve built.

You can bring in numbers of teams concurrently into the Dojo and that tends to drive the size of the Dojo team and you have to bootstrap the Dojo itself. 

Now I’m thinking that remote reduces the cost of starting, but I think it’s also going to bring in so many other constraints to the way it worked. 

And then the thing you talked about a lot was start where the team’s at. So yes, there’s an ideal make up of the teams that come into a Dojo to get the best impact, but if that’s not how the organization works bring them in, there will still be value and impact that comes out of it.

So then we talked about the anti patterns, it’s not making a faster horse. It may do, but it’s not the goal. And one of the anti patterns is treating it as a bootcamp or an onboarding process, that’s not what it is.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Joel: I’m Joel Tosi.

Dion: And I’m Dion Stewart.

Murray: Hi guys. Thanks for coming on.

Dion: Thanks for having us.

Murray: We want to talk to you about Dojo’s today, but before we start, how about you guys tell us a bit about your background and experience.

Joel: Sure. I’ll give you a quick background, Murray. I started off early 2000s, software engineer, went up the ranks, became a manager. Wasn’t the best manager. I went back to tech and was an architect for futures and trading platform. Went in the Agile space , then went back to, an architect for North America for Red Hat for a few years. But I felt like we were building great technology, but not great products. So I called up David Hussman spent a good few years with David. Met Dion there and the history is there.

Murray: Okay, Dion.

Dion: Yeah. Like Joel, I have a development background. I’m one of the annoying people who did Small Talk professionally and always likes to bring up Small Talk and how great Small Talk is. But a little more seriously, I was working on a master’s program in the nineties and I had this professor named David West who was bringing people like Kent Beck and Rebecca Worf Sprock, Ward Cunningham Sutherland and Schwaber, on campus to try and expose us to some different ways of working in different ideas.

This actually even predated the Agile Manifesto. And I learned a lot of these techniques while being a professional Small Talk developer. Test driven development, for example. And so in the aughts I get put on projects as a developer coach. You’re a developer on the team, but we want you to teach other people test driven development and help them adopt continuous integration and a lot of these other technical practices.

For some strange twisted reason, I have an interest in methodology and process. I think it stems mostly from being put on projects where process was so much in the way and so horrible that there’s got to be a better way of working. That gradually led to me becoming a full time coach around 2010. As Joel mentioned, we both subcontracted for a guy named David Hussman in Minneapolis. We started doing Dojo’s while working for David. Unfortunately, he got sick and passed away. And Joel and I said, Hey, let’s go do this Dojo thing on our own together.

Murray: All right, what is a Dojo?

Dion: Okay. At a really simple level a Dojo is an immersive learning experience. Dojo literally translated means the place of the way. It’s a word used in Japan to describe Zen meditation centers and martial art studios. The reason the word came about is because the CEO of Chef gave a talk on developing DevOps Kung Fu. DevOps is something that you have to practice like a martial art. You don’t just go to one weekend martial art workshop and now all of a sudden, Kung Fu. One of the biggest things that makes Dojo’s different from traditional forms of training is this idea of repetitive practice. That you need to go in. You need to work. You need to focus on learning and improving. But it’s not just consuming information. It is actually practicing, applying, getting feedback from other people in the Dojo who are more of an advanced practitioner than you in certain areas.

Joel, anything to add. 

Joel: In the early days the Dojo was a physical place where multiple teams were there to learn and they would share ideas. And so it had this energy, like you were going to the Dojo and we would put up nice big whiteboards that would say, here’s all the teams, here’s what they’re working on. Here’s when they’re demoing. And people would naturally come there because they were curious and they wanted to see what was happening. So it literally became a place that people wanted to go to. It took people out of their daily work and it gave them a fresh set of eyes and a fresh way of looking at things. 

Shane: So it’s different to a training course in that you typically went there for a longer period of time and did the work. 

Joel: The standard model was teams would be working for six weeks all day with coaches and they’d be doing their work. Now, early on at Target they were really excited about DevOps. If we automate our infrastructure, then all of our problems would go away. We quickly helped them think a little bit broader across the value stream. 

And so teams would come in and they would have an idea of the product they wanted to work on, and they might have some ideas of the techniques they wanted to practice or get better at. But of course, by doing the work, we would also learn more techniques that they might not be aware of.

Some teams early on, we’d start off with some very common techniques. We’re going to do some story mapping. We’re going to do some, thin slicing of work . We’re going to create it from a test first perspective, but then teams might realize that they don’t know how to mock, or they don’t know how to do patching or how to do versioning. And it never really crossed their mind. And so the coach is there to offer up new ideas for learning that a team might not be aware of, but it was always their work. We were always doing it together and we were there six weeks all day.

Shane: So it wasn’t a case of new people going in on their own. It’s a case of the entire team coming in for an immersive six week period. 

Joel: Yeah . It was the whole team, which includes product owners, which included Scrum Master. It wasn’t just an engineering thing. It was all of us together.

Dion: yeah, I think that’s a key distinction. Some people have confused Dojo’s with bootcamps or onboarding academies. That was not the purpose of the Dojo. It really is about bringing teams that are going to be working together into the Dojo so they can learn how to work more effectively as a team. Helping teams learn how to collaborate, whether it’s ensemble programming or how do we collaborate better around testing and really move the QA function up in the beginning of the development cycle, as opposed to testing quality in at the end.

I want to stress that because there have been some criticisms of the Dojo. And if you dig into them, the people who are saying this were really doing a bootcamp. And then after it was over, everyone dispersed and went to other teams. 

It can be a really effective tool for teams that are newly formed. So we’ve been in organizations where they’re doing reorgs and we’ll get engineering managers reaching out to us to say, Hey, it might be a really good time for this team to go through the Dojo because we’re newly formed or we have a lot of really new team members.

The other thing that sometimes happens is we’ll get in a part of an organization that has multiple teams reaching out to us. We start a discussion around working 3, 4, 5, 6 teams, however many it is, and Joel and I will start to get the sense that the team structure that this group has is not really optimal. And sometimes we’ll actually go through various exercises and we’ll redesign the team structure. And then we’ll bring those teams through the Dojo.

Murray: So Dojo’s emerged from the DevOps movement, but is it just for DevOps? What content or training can you use Dojo’s for?

Joel: So when Target first started, it was all DevOps. I remember sitting with my first team in the Dojo on their first day and they really didn’t have context of why they were doing anything. It was always just, we’re here to build infrastructure. What are you going to put on the infrastructure? We’re going to put some code on it. And so we had to say infrastructure and DevOps is great in context of serving a larger purpose. What are we doing? And then we quickly started expanding the value stream.

We started incorporating product thinking as well as, technical practices. Interestingly enough, I think my second team at Target was actually L and D. So that was non technical but what L& D was trying to think about was we’re trying to redo how we think about roles and how we think about progression of skills and staff inside of our organization. What techniques could we use to help us understand how do we create better career paths? And so we started helping them think about product thinking and personas and really honing in on the problems that their staff was having and how they would address those needs of their people.

Dion and I are not L and D experts but it was really helping them frame it up and think differently. So we had this first team was DevOps. The second team was L and D, and then we started getting more and more across the spectrum product ideation into delivery, into operational. In other organizations we’ve helped with purely technical onboarding of new platforms, API platforms, cloud infrastructure, as well as worked with teams that were doing purely discovery work, rapid prototyping, quick feedback loops. So we’ve been pretty effective with Dojo’s in a variety of domains.

Dion: Yeah, I think another aspect of Dojo’s that’s different from traditional approaches to training is you get to link practices together. So really getting people to think about the product, be very customer centric, all those things. Getting people to look holistically at the entire value stream and see how doing story mapping could lead into very thin slices of functionality that they could get out to do either A B testing. And the pipeline really becomes valuable when you can test your product ideas quickly. That’s something that is really hard to replicate in a shorter duration training workshop. 

Murray: How do you design this content? How are you going from infrastructure pipelines one Dojo to L& D the next? 

Joel: We really don’t do design of any course or material. We have ideas and we have techniques. And so before we start working with the team, we actually do a consult, get to know them. We’ll talk about expectations, help us understand what the team wants to get better at. From there, we go into chartering where we would sit down with the team , talk about the outcomes they wanted to achieve, how they would know they’re successful. What do you want to learn? And how is it going to help you? And we also mapped that into some of the skills they wanted to improve upon. 

There was a natural funnel that we would do very short in duration that helped frame up the initial learnings as well as the outcomes. But then, of course, we would have to use our coaching senses at times to say, I know you didn’t call out ensemble style programming but I feel like we have some disconnects on context. Let’s try working together to see if this addresses some issues. So again, funnel, frame up the learning, and then discovery of learning as we go.

Dion: Yeah. 

This approach requires skilled coaches who are practitioners in the set of practices you want to be able to help teams adopt and improve in the Dojo. That doesn’t mean every coach can do everything. You have technical coaches and then you have product slash agile coaches. And we may need multiple technical coaches who have different skills. Joel and I are not here to say that we can coach anything and everything. We are older. We’ve been around for a while. So we’ve been exposed to process, product and tech. But for example I worked with a team about a year or so ago front end react JavaScript developers. They wanted to learn how to do back end microservice development using an internal framework to the organization and Kotlin. I didn’t know Kotlin. I didn’t know their internal microservices framework. So we ended up recruiting a couple of people from the organization who had been building Kotlin microservices using their framework for about a year. And we co coached together. I facilitated, guided, pushed them towards TDD and some other things based on my background, but they provided that other expertise.

Shane: So is there minimum viable number of coaches that you need in a Dojo? 

Dion: It really depends on how many teams you want to be able to handle concurrently and then the entire skill set that you want to have teams work on in your Dojo. We’ve been in organizations, who want to focus on migrating to the cloud. They’ve got existing apps. They’d like to do some refactoring. But they’re not really looking at doing new development, so they’re not really interested in working with us on product discovery practices. So when we start working with an organization to help them implement a Dojo, there’s a bootstrapping process for the Dojo where we’re defining the outcomes you’re really looking for? What are you trying to move the needle on? What are you trying to improve on? Target had a space that could handle about 12 teams concurrently. That’s at least a couple dozen coaches, and then they also had a policy that their tech coaches would have some time off between teams to upskill themselves, work on technology improvement. So it was even more than 24 people at one point in time. In the remote world, an organization could really experiment with one team and maybe one or two coaches to work with that team. . 

Murray: Do teams do their own work? Do they pick up an existing project and bring it into the Dojo? Or do they do some imaginary project?

Joel: Always their work. We have a team, that we were working with last year, an organization, 20 year old code base, running on an unsupported version of Java on an unsupported platform. That’s what we got. Let’s figure out, how do we work in it? How do we test it? How do we learn how to add features to it? It is their work.

Murray: Okay, so then, what’s the structure of a Dojo? You’ve got people for six weeks. I read that you do two and a half day sprints, how do you structure it over those six weeks? 

Joel: Yeah. So when a team first starts, there is going to be a backlog creation. Now teams are coming in with their existing code base and their existing backlog, and so that backlog creation might be quick. Or it might be, Hey, we’re going to do a little bit of discovery to make sure we have the right context so we can make decisions around what to build.

If a team is doing a migration, it might not be a backlog creation. It might be more checklist oriented, or it might be here’s the things we’re trying to work through. But the first day, if not the first week is really going to be around techniques around framing up the work we want to do. 

Second week we’re writing code, building, testing, verifying, demoing, all those standard stuff. We will also revisit their learning goals We’ll adjust the backlog. Help them practice the techniques we did the first week. Part of the Dojo is about repetition and spaced repetition. So we’re going to practice again, the backlog creation. Maybe it’s a different piece of functionality, maybe it’s a different feature and rinse, wash, repeat those techniques. What would you add to that, Dion?

Dion: A little bit more about chartering. So there’s a flow to teams coming into the Dojo. We don’t just schedule them to start on day one and boom, they’re all of a sudden in the Dojo. And that’s our first conversation with them. We start off with consults. They’re just conversations like the one we’re having now. Where we explain to the team what the Dojo is, what the concept is what the commitment required from them is. And we get to know the team. We get to understand what’s going on with them. And it’s to see if this is a fit. Are you interested in having your team go through a Dojo? And it’s not just the stakeholders. It’s the people on the teams. So the Dojo is not a whipping post for engineering managers to get their teams in shape. We really do want people to self select and opt in. 

In most organizations they’re saying, look, it’s okay for you to slow down a little bit on your output and your expected delivery and focus on learning and improvement, and you get to define to a large extent what you want to work on in terms of learning and improvement. Yeah, there’s overarching organizational goals, but at the team level, you yourselves know how you can make those improvements.

From that initial conversation, we move into chartering and chartering is about three to four hours. We come out of chartering with very clearly defined learning goals for that team. So every team is potentially different within the same org, one team might be doing new product development. Another team might be moving their applications to the cloud. So the 1st week for both of those 2 teams could look significantly different in terms of the way the coach is working with them. We’re constantly referring back to that chartering document. It does produce an artifact that activity, and we’re constantly checking in on that.

And oftentimesI’ll come in and I’ll ask the team, Hey, let’s look at the charter, what we’ve accomplished in terms of your learning goals. What’s remaining. What do you all think is the most important thing for us to pick up next and let them guide their learning.

Shane: The fact that you’ve got six weeks, is that something that somebody picked and it just worked? Is it something you’ve experimented in doing shorter, longer? 

Dion: The 6 week time period was a complete accident at target. They were doing shorter durations, very focused on helping teams learn how to create pipelines. At one point, one of the stakeholders approached the Dojo staff and said, my team has this deliverable. It’s about a month and a half out. We’d really like to bring them into the Dojo to have you work with them while they’re doing this. And just by accident that was the first six week team. And afterwards, retrospectively, people said that seemed like a really good duration. The first two weeks, the agile and product coaches could be very hands on and guiding. The second two weeks they would back off a little bit and have the team be a little bit more self running and then they would really back off the last two weeks and the expectation would really be that the team could be self sufficient and run on their own.

The other thing is the two and a half day sprints. We don’t do those too much in the remote world. We have asked teams to go down to a one week sprint. The main reason for that was to get people more practice for one. If you’re doing two sprints a week, you get 12 shots at working on sprint planning and retrospectives and all that. The other thing is it made all those activities much shorter sprint planning doesn’t take as long if you’re doing a two and a half day sprint. 

I can’t tell you how commonly we heard at the end of the 1st sprint. When we asked what was done and not done. People would say, you were serious about us finishing stories in 2 and a half days. And we’re like, yes. Which might sound absurd to some listeners, but I’ll point out that people like Ron Jeffries have been talking about breaking stories down into one day for a long time now. So this idea of breaking work down into really small incremental and iterative stories is not something that Dojo invented. What’s funny about this is scrum and agile was probably the least important learning goal for most of the Dojo’s that we do. We really tend to focus more on the technical and the product practices, but it was really common at Target and other places for people to say at the end of the six week Dojo, I thought I knew how to do this agile stuff. I thought our team was good at it, but I feel like we really understand it now. And part of it was doing so many repetitions, getting all those reps in on the practices and being forced to break down work into these small increments.

I just want to say scrum is an agile tool in your tool kit. It’s like a hammer but agile came out of the technical movement. And so what you’re doing is all agile as far as I’m concerned. I agree, Murray. Most of the practices that I learned were doing small talk development, even before Kent Beck wrote his extreme programming book. So I think we even fall into the trap sometimes of talking about Scrum in terms of Agile. We’ve had teams that come into the Dojo because they want to try Kanban. Work with someone who knows Kanban, get feedback, see if they want to stick with it when they leave.

Shane: So we’re changing something markedly different for a period of time which forces us to do some step changes. I can also see a risk that people don’t actually bring their work to be done. Have you seen that where people treat it as off site? Rather than just a different place to be doing the work. 

Joel: I cant think of a team that has not treated it well. Theyre also doing demos and you’re not going to get very far by not working on your work. The step functions really interesting. What I would have you all consider too is the two sprints a week changes the thinking. Sometimes teams are worried about. How big is it? And we want them to think about what could we do that’s interesting in a few days, as opposed to the only thing I can do is create a database. And so we were trying to get them to think of new questions as part of this experience, as well as the fact that they’re going to be demoing it as opposed to just check off a task.

Murray: What are the challenges and anti patterns that you see with people using Dojo’s?

Dion: I think the biggest anti pattern is not fully committing to that time period in the Dojo. Joel and I will do a lot of work with stakeholders, team members prior to the start. Make it really clear that going into that, the goal is for a period of time, learning over delivery. The focus really is on capability improvement. And I think the biggest anti pattern is people starting to get pulled out. I need this person for this project or this product delivery effort. In some extreme cases, we’ve had even people being subversive and pulling team members aside. Saying, Hey, I know you’re in the Dojo and you’re supposed to be focused on learning, but I really need you to work on X for the next two weeks. And that’s probably the biggest anti pattern. 

We’ll also have really clear, honest discussion with stakeholders and teams about what their current delivery commitments are. A lot of organizations are still doing quarterly planning cycles and we’ll say, if you’re up against the wall already for this quarter, in terms of what you’ve committed to deliver let’s talk about starting a Dojo next quarter. And when you do quarterly planning for the next upcoming quarter, you can plan on having, a little bit less output to make room and to make space for the Dojo.

Joel: So in most organizations that we’ve been in management or executives or somebody says there’s probably some stuff we should learn as well. When teams are focusing on two days at a time any bureaucracy in the organization blows up really fast. When we have the best relationship with organizations that’s when the middle management and the executive starts realizing that these teams that are doing two sprints a week are having a lot of problems with X, Y, and Z. How do we as leadership help the teams become better? So the anti pattern I would have is if an organization thinks the Dojo will solve all of the problems.

We have our product development team and they weren’t going fast enough. So now we’re going to outsource support to another company and they’ll do all the bug fixing and that’s not going fast enough. So we’re going to outsource something else. Now, can the Dojo fix what I just created? The Dojo, it does not fix those problems. It will blow them up. 

Dion: Would you say scaling is an anti pattern Joel?

Joel: I don’t know if I would say it’s an anti pattern. Every organization at some point, if they have success, they’re going to say, how can I go faster or do more of it? I think the assumption that the way to scale is by truncating time. So like we’re having success with teams working at six weeks at a time. Can you do it in two weeks? So that way we can get more teams faster. I think that would be an anti pattern. When we’ve talked about organizations trying to scale this we can choose more impactful teams, choose platforms that have multiplier effects. We can choose different vectors to scale the impact. But if by scale, you just mean more teams faster. The only mechanism is more coaches, but that doesn’t necessarily guarantee, quality and consistency. So I don’t think scaling is an anti pattern so much as the reaction to it. 

Murray: So do you guys work with the team’s existing way of working in the Dojo’s? If they’re using Safe or if they’ve got an onshore offshore supplier model, if they’ve got separate dev and test teams in silos, Do you take that into the Dojo and reveal all of the problems or do you say you can’t come in with a separate Dev and Test team?

Joel: Sometimes our clients don’t give us that freedom and we’ll just expose it and do the best we can. In many organizations we’ve been in while dev and test might be the same team, they report to different managers and they have different motivations and ways they’re measured. And so we have to help the team figure out how to actually be a team. The offshore onshore is an interesting thing. It happens quite a bit. And so we try to make the best we can with team overlap in those situations. But we will, of course, play back, are we trying to minimize costs at the expense of greatly increasing costs over the long term?

Murray: What you’re teaching seems to me requires, some structural things to be in place before you begin. That you have Dev and Test in the same team, in the same time zone with good communication. That you’ve got product development people and other SMEs available working with the team and the team controls their own infrastructure or they have a very good infrastructure platform that’s quick. 

Joel: Yeah, I think you’re dead on, but I think the challenge is when time horizons get big organizations lose that view of the impact that having separate teams has on the organization. And so we might start with a team that has separate Dev and Test with the idea of trying to help the team learn something and own it. And so we’ll just start helping them see the actual cost of the decisions they’ve made. And then ideally we can start helping them make it better. 

Dion: One of my favorite stories going back a few years was an organization that had separate dev and test teams. And so instead of insisting, no, these all have to be one team cross functional. We just asked them to bring the people together in the Dojo for the six weeks that they were going to be in the Dojo. I get it that these are from different teams, but can we build a community for the duration of the Dojo and have everyone come in and work together. The first team that came in, around the second week, one of the testers just happened to be sitting next to one of the developers and the developer was working on an API. The tester was automating some tests with postman. We had worked on getting all these tests into a build pipeline. But what happened is the tester spun in the chair, looked at the developer and said, I just ran, 22 test cases on the API that you just committed 15 minutes ago, and two of the tests are failing. Developer wheeled his chair over looked at the two tests. And immediately went, Oh, I know what I did wrong. I know what I need to fix. Rolled back over, made some code changes. 10 minutes later, the tester was testing new code. Luckily the dev manager saw this. And he pulled me aside and he said that interaction right there would have taken days in our old structure outside the Dojo because the defect would have got logged, the tester might not have looked at it until the next day. By the time it got back to the Dev and the new build was available for the tester it might been a couple of days.

They actually reorg the entire division to realign the teams to have those cross functional teams with dedicated QA people on the team. So if you hear a little bit of hesitation in our answer to this, yeah, absolutely. I would like to say, look, there’s things we’ve learned 20 years ago. This is what works and what doesn’t work. As much as we would like to mandate things we think are optimal for working we do have to meet the org where it’s at. And when a team comes in, you meet the team where they’re at. That’s another thing that makes this model powerful. You don’t make a team go through a predefined curriculum where they already know the first half of it, you meet them where they’re at.

And the same way you meet the org where the org is at and say, all right, let’s try this. Are you willing to try some experiments? If we absolutely got into an organization, Murray, where we know they are not in any way organizing for optimal delivery and they’re not in any way flexible about trying experiments. I think Joel and I would say, okay, we’re probably not the best fit in terms of coaching for you. Let’s figure out a way for you to move on and for us to move on.

Murray: What’s really interesting is you’re doing organizational change through experiential learning. So if people are working in silos, you can say, Hey, look, that’s fine. Just bring in all your silos that you need to deliver a product from end to end. Product dev test infrastructure. We’ll put them in teams and as they’re doing it, we’ll show them, a better way of doing things and they can learn how to work better. And so by experiencing the problems of their silos and given that they’re in an empowered environment Environment, then they should be able to say, Hey, what if we worked more closely together.

Dion: Yeah. In the more dysfunctional organizations we’ve seen teams deliver more In the six week time period, then they would have outside the Dojo, even with all the time they’re committing to learning and upscaling. I want to be really careful and follow that up by saying the Dojo is not an accelerator. It is not a place to bring teams in with the expectation that every team is going to deliver more, within the same time period. But it, has happened. 

Probably the most extreme example of this was the business stakeholders in this one company had been requesting some functionality on their website for five years. And one of the senior people in the company said, can we bring these multiple teams in the Dojo that would be required to deliver this, with the idea that they’re going to work on this. And there was a little bit of back and forth compromised a little bit on some of the learning goals, but the punchline is the teams delivered this functionality in six weeks that the business had been asking for five years. It’s because we broke down all those walls and silos and got them collaborating effectively and well together. And really we just shortened the feedback loops between all the different parties. 

The other thing we do in the Dojo’s is create an organization backlog. The coaches, as they’re working with teams, when they observe something happening that if we went out and we address this constraint or friction in the organization, we know it would help all teams in the org, whether or not they come into the Dojo, we put those ideas on a backlog. We prioritize it and we would be working that in parallel with the coaching. An example of this is in one organization, it took two weeks to get a firewall rule change rolled out. And to Joel’s point, if you’re trying to do two and a half day sprints, boy, waiting two weeks on a firewall rule you’re really tying things up and even looking at it from the standpoint of a six week Dojo, you’ve just burned a third of your Dojo time waiting for that firewall rule. So we put that on the backlog. We got some people from security and governance and infrastructure help the organization implement a new process that went from two weeks to a day. Obviously that would impact any team that needs a firewall, whether they’re coming into the Dojo or not. Dojo’s are a way to hold a mirror back up to the organization. Hey, here’s what we’re seeing with these teams. If you fix this, you fix it for all teams, not just the one currently in the Dojo.

Murray: Having those managers and escalation points meeting with you every day during the Dojo, could be very helpful because you could say look, here’s a blocker to the team. Can you go and fix it by tomorrow. How do you work with those more senior managers who are actually controlling the system?

Joel: We do two things pretty consistently on a weekly basis. One is have a weekly 30 minute hour long check in with any senior leadership of the team as well as of the Dojo in the organization. Where we’re talking about blockers to learning. Here’s what the team’s trying to learn. Here’s what’s happening that’s holding them back from learning and being effective. And so we’re sharing that with this leadership group. We also will send out weekly notes that we work with the teams on where we talk about what we plan to learn what we actually learned doing it. New ideas for learning and where we’re going to go next. So it’s not about, we finished one nine, two, seven story, blah. It’s while trying to deploy the code, we found this firewall rule that had to be changed. We weren’t able to do it. We’re going to look into understanding how to do this more effectively as a team. And so we’re trying to create these notes around the learning as it’s happening. As well as capturing it with the team. So they have a record of it. And these notes tend to be a pretty good mechanism for us.

Murray: We had a guest on recently from a company called Vanguard Consulting, and he said that they change thinking through experiences. So performance problems are a result of the system you’re in, usually. The system is a result of senior managers thinking and assumptions about the world.

So in order to change performance, you need to change senior management assumptions. And the only way you can effectively do that is by getting them to experience the problems. So it sounds to me like they would experience it if they came along and watched and were involved in your Dojo.

Joel: Very much so. Concrete example that I’m sure you both could relate to. Engineering teams trying to build software, lots of bad architecture coupled with systems. And so when they go to deploy it everything falls apart. Environment’s unstable. Therefore they can’t test very effectively. Therefore there’s more defects. Therefore we need to plan for more stuff and we need to start more concurrent work. . 

And so by having leadership experience this changed the way of thinking. So it’s not the team’s problem. It’s cranking through more and more, which is causing instability. So bringing them along, showing them the ramifications of their decisions, helping them think of other ways, let’s try something different in the Dojo and see what happens, gives them a new view of the world. That’s been pretty profound for a lot of organizations.

Dion: Yeah, we actually invite and encourage stakeholders to stay in the Dojo when their teams are there. That could be everything from they’re there, but they’re doing their own thing and they’re in and out cause they’re going to meetings, or on the other end of the spectrum, I had one engineering manager learning microservices for the first time. He said, I’m going to pair with other people on the team and learn how to write microservices with them, which I think was really cool. And he got to see firsthand some of the constraints and the friction. 

Murray: What are the outcomes you can expect from using a Dojo? How do you measure success.

Joel: Success for us is always organizational capability improvements. Is the organization able to produce a better product either with, higher quality, better market fit. And for us, the capability improvements have to stick. It can’t be just the team did it during the Dojo, but now when it’s gone, they don’t do it anymore. So we want organizational improvements, capability improvements. We want it to stick.

Shane: Given the repetitive nature in the Dojo will teams come back in and do another six weeks immersive learning 

Dion: Yeah, that does happen especially if the Dojo is somewhat long lived in the organization because technology changes over time. So maybe the org is trying to get to the cloud initially and then maybe a little bit later, the org says, you know what we’re not getting the cost benefits and the scaling and efficiency out of the cloud. We need to do some refactoring. Maybe they get a domain driven design focus or something like that, but there’s a whole new set of approaches and technical skills to go along with that. And the team will come back through.

If we did our jobs perfectly as coaches, I think it would be fair to say a team would never have to come back through because part of the other aspect of a team working in the Dojo is for them to learn how to continuously improve while they’re doing their normal everyday work themselves. Ideally, the team would be able to continue making those improvements on their own.

The other thing is there would often be office hours where you could chat with a coach for a bit about a particular problem or technique you’re interested in learning more about. And it was really common for team members to stop back in after they had been through a Dojo, maybe a month later, a couple months later. We’ve got this one little sticking problem that we haven’t quite figured out yet. Do you have any ideas? In some cases we can solve those things really quickly without the team having to do another full six week Dojo.

Shane: So it’s a way of coming in and getting an immersive learning of all the other things that have happened in the organization since you were last there. 

Dion: Yep, absolutely. One of the other really cool things at Target and some of the other companies is they would make it very clear that the demos were open to anyone, not just teams in the Dojo at that time. So we would get people popping in, they might even be walking by and they see something interesting on the screen. Something, the person who’s presenting says catches their ear, and they sit down and watch for a bit. That cross pollination, if you will, of ideas throughout the organization. The other thing we often do is, as coaches, Shane, is if we get a question from a team and we know a different team has already resolved it, instead of saying, okay, here’s how you do it, We’ll say, go talk to someone from that team, or we’ll contact someone from that team and say, Hey, this team in here now has the same problem you solved when you were here, do you mind coming down and sharing what you did with them?

That can be really powerful because people get sick of the outside consultants telling you what to do. So if you can start making those peer to peer connections, especially if it’s teams that don’t interact much and people who didn’t already know each other, now all of a sudden you’ve got new contacts within the company. So you foster that connection to share learning and improve.

Murray: What is the future of the Dojo concept? How do you see it changing?

Joel: I guess my hope would be that we could extend this learning even more so up the chain. If organizations truly want to do more with less, we need to get that experiential learning to be consistent, study the system, systematic changes. That’s where I would hope to go. What do you think, Deon?

Dion: Short answer is I don’t know but we’re exploring and constantly looking for ways that we can continue to share with people, continue to show why it’s valuable and hopefully continue having success stories that make more people want to join the community and try it. Joel and I are part of a very informal working group called the Dojo consortium. It started almost 10 years ago now. Target, Capital One and Verizon were the first three companies to implement this model and someone at Verizon said, it might be useful for us to get together a couple of times a month for an hour over zoom. Just chat about what’s working, what you’re experimenting with what’s going on. And Joel and I organized a conference in Minneapolis, Minnesota in 2019 before COVID. I think there were people from about 50 companies that were trying this model at the time.

There’s a constant question in that group, how do we prove the Dojo’s value? And in some cases, it’s really simple and explicit, but that’s another area we struggle with. So I guess Joel and I are still learning ourselves. And our experience with the Dojo has been, this is way more effective than the typical embedded coaching we did previous to this in terms of having a long lasting impact.

Murray: All right, let’s go to summaries. Shane, what do you got? 

Shane: Alrighty, so key thing Dojo is an immersive learning experience. And the value from it is repetitive practice. So we take them out of their normal environment. We put them into a cool space for six weeks. The coaches are in the room with the people doing the work for the whole period. And then you talked about the idea of technical coaches who know how to do the craft and agile or product coaches who tend to look at the ways of working. 

And then within the six week cycle, you had a typical flow, which was two weeks being really engaged guiding, then two weeks where you help them but observe a lot more and then two weeks of hands off, where you’re only there if there’s a problem. 

And then they learn while doing repetitively. And that came back to this idea of two and a half day iterations or increments. So that allowed us to have 12 of them in six weeks. So that repetition helps us learn, helps us apply, helps us iterate, helps us get value out of it. And two day increments highlight dependencies, it highlights waste, it highlights bureaucracy and lack of communication, hierarchies, all those things that we know are embedded in the system, but by shortening the cycle, they stand out. 

And then you’re often looking for the patterns that team are not adopting and then suggesting they adopt them and then getting them to repetitively practice it and see if they get any value from it. And you’ve already got patterns from across all the other teams so you can actually reuse them for this team. And it also allows you to look holistically across the value stream. So great example of the dev team and the QA team coming in. And now you’re starting to see two steps in that value stream, even though they’re separate teams. 

One of the patterns that’s really important is this concept of chartering. There’s a whole process around expectation. And the key thing there is you’re setting expectation that the benefit of the Dojo is learning, not what you’ve built.

You can bring in numbers of teams concurrently into the Dojo and that tends to drive the size of the Dojo team and you have to bootstrap the Dojo itself. 

Now I’m thinking that remote reduces the cost of starting, but I think it’s also going to bring in so many other constraints to the way it worked. 

And then the thing you talked about a lot was start where the team’s at. So yes, there’s an ideal make up of the teams that come into a Dojo to get the best impact, but if that’s not how the organization works bring them in, there will still be value and impact that comes out of it.

So then we talked about the anti patterns, it’s not making a faster horse. It may do, but it’s not the goal. And one of the anti patterns is treating it as a bootcamp or an onboarding process, that’s not what it is. 

Murray, what do you got?

Murray: Yeah, look, I agree with everything you said. I just want to know, how do you get started with a Dojo? What do I do if I want to implement this in my next client.

Joel: The intent of the book was that you could pick it up, you could read it and you could say, I’m good. I can start. An organization has to have an idea of what they want to improve upon and from there you start thinking about the techniques and the capabilities that you want to improve. And, from there, you start thinking about how to help teams.

Dion: I would add of course you could reach out to us and we could engage with you and we can get you connected with the Dojo consortium working group. A lot of the Dojo’s that did spin up people from that group from different companies were helping people.

For example how do I get my stakeholders to buy into this? And other people in the group would share what they did and how they got their stakeholders to buy into it, or at least fund an experiment. And to your point, Shane, one of the ongoing discussions is how can we make this effective in this remote world now? Short, quick answer for that, a lot of remote mobbing or remote ensemble work. We found that helps quite a bit. Woody Zuil came in and helped us quite a bit in terms of helping teams adopt that. 

Murray: All right. So how can people get in touch with you

Joel: Dojo and co. com easiest way. You can reach out to us. There’s various ways to contact us on LinkedIn. We do have a YouTube channel of some previous presentations at conferences we’ve done, if you check that out. But we do poke around in the conference scene as well.

Murray: And the book was Creating Your Dojo 

Dion: yes. 

Murray: All right. Great. Hey guys, thanks for coming on. 

That’s fascinating. 

Dion: Thank you.

Joel: Thanks for having us.