#0104 - The Dojo with Joel Tosi and Dion Stewart

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode we talk to Joel Tosi and Dion Stewart about Dojos. Dojos are a six week immersive learning experience where teams learn and practice new ways of working on real work with skilled coaches. We discuss the structure and implementation of dojos, chartering coaching dynamics and frequent feedback loops. We emphasize the challenges and anti patterns that can emerge such as treating dojos as boot camps or lacking stakeholder support to remove barriers. Finally, Joel and Dion offer insights into the future of dojos and the potential for building capability and driving organization change.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

I'm Joel Tosi.

And I'm Dion Stewart.

Hi guys, thanks for coming on.

Thanks for having us.

We want to talk to you about dojos today, but before we start, how about you guys tell us a bit about your background and experience?

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.

Okay, 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 90s and I had this professor named David west who was bringing people like Kent Beck and Rebecca Wurf, Sprock Ward, Cunningham, Sutherland and Schwaber on campus to try and expose us to some different ways of working and 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 arts 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 gotta 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 dojos 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.

All right, so what is a dojo?

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 arts 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 dojos 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?

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.

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

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 that 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.

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.

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.

Yeah, I think that's a key distinction. Some people have confused dojos with boot camps 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 criticism of the dojo and if you dig into them, the people who are saying this, we're 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 an 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 dojos.

So dojos emerge from the DevOps movement, but is it just for DevOps? What content or training can you use dojos for?

So when Target first started, it was all DevOps. I remember sitting with my first team in the dojo on, you know, 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 and 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 traditional, 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 dojos in a variety of domains.

Yeah, I think another aspect of dojos 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.

How do you design this content? How are you going From Infrastructure Pipelines 1 Dojo to L and D the next.

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 a 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's it going to help you? And we'd also map 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 and 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.

Yeah. This approach requires skilled coaches who are practitioners and 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 in front end react, JavaScript developers. They wanted to learn how to do backend 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 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.

So is there minimum viable number of coaches that you need in a dojo?

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 our 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.

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?

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 is their work?

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?

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 different feature, rinse, wash, repeat those techniques. What would you add to that? 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 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 first week for both of those two 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 oftentimes I'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?

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?

The six 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 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 first sprint, when we asked what was done and not done, people would say, you are serious about us finishing stories in two and a half days. And we're like, yes. Which might sound absurd to some listeners, but I'll point out 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 dojos 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 toolkit. 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 us try Kanban, work with someone who knows Kanban, get feedback, see if they want to stick with it when they leave.

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

I can't think of a team that has not treated it well. We're also doing demos. You're not going to get very far by not working on your work. The step function is 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, we're trying to get them to think of new questions and 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.

What are the challenges and anti patterns that you see with people using dojos?

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 of 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.

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, 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.

Would you say scaling is an anti pattern job?

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.

So do you guys work with the team's existing way of working in the dojos? 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?

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?

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. 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.

Yeah, I think you're dead on. 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.

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. Ten 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 bet a couple days they actually reorged 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 in the same way you'd 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. And 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.

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, then they should be able to say, hey, what if we worked more closely together?

Yeah, in the more dysfunctional organizations, we've seen teams deliver more in the six week time period than they would have outside the dojo. Even with all the time they're committing to learning and upskilling. 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 dojos 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 addressed 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 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. So we put that on the backlog. We got some people from security and governance and infrastructure helped the organization implement it. A new process 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. Dojos 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.

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?

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 and 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 finish 1927 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.

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.

Very much so. Concrete example that I'm sure you both can 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, that's 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.

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 because 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.

What are the outcomes you can expect from using a dojo? Have you measure success.

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.

Given the repetitive nature in the dojo, will teams come back in and do another six weeks immersive learning?

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, 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 team having to do another full six week dojo.

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.

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, will say go talk to someone from that team or we'll contact someone from that team and say, hey, this team in here now adds 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 fostered that connection to share, learning and improve.

What is the future of the dojo concept? How do you see it changing?

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 it'd go. What do you think, 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 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 are 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.

All right, let's go to summary. Shane, what do you got?

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 knew 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. 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 of 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 works. And then I think you talked about a lot was start where the team's at. So, yes, there's an ideal makeup of the teams that come into a dojo to get the best impact, but that's not how the organization works. Bring them in, there'll still be value and impact that comes out of it. So then we talked about the anti patterns 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 boot camp or an onboarding process. That's not what it is. Murray, what do you got?

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?

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.

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 dojos 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 Zuhl came in and helped us quite a bit in terms of helping teams adopt that.

All right, so how can people get in touch with you?

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

And the book was Creating your dojo. Yes. Yep. Yeah. All right, great. Hey guys, thanks for coming on. That's fascinating.

Thank you.

Thanks for having us.

That was the no nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.