Coding Dojo

Host  All right. So, without any further wait for you, we’re gonna I’m going to introduce Arushi Bhardwaj. And she is a product coach at Fannie Mae. And she’s got 15 years of experience in IT, and government, and financial sector. And she’s got a background in product development, and she is serving as an Agile Coach at Fannie Mae. And I actually had the opportunity to work with her at Fannie Mae, and I think she’s amazing. So I’m really excited to have her speak. And I’ll post her LinkedIn profile in the chat in just a minute. So that way, y’all can connect with her on LinkedIn. And I’m going to hand this over to you Arushi – I know you’ve got a much better introduction of yourself. So I’ll let you do that. And let me know if you need anything. Everyone as they come in is on mute. But feel free to unmute, feel free to turn on your video, and we can collaborate. Thanks.

Arushi Bhardwaj  Thank you, Cherie. I had the biggest opportunity to work with you frankly. I mean, you have turned me around for so much better. I’ve become a better person just because I’ve worked with you. I stayed with you. I chatted with you. So, kudos to you, my guru. I love that. I love, you know, my chat sessions with you. Thank you. Appreciate it.

All right. So with that, I’m going to go ahead and share the excitement that I bring to work every day. Hmm. Yeah, you know, I’m, like always all about Dojo. And you know, I think I’ve bored everybody , you know, talking about this topic, whoever comes in contact, even in the coaching classes. I’m crazy about it. All right.

So, let’s start with me right out. I think Sheree just kind of talked a little bit about me. There’s, you know, there’s not much to tell I am an open book I love you know, I love my job. I’m always very excited about my job about what what I do. And I think, from the years have gained this experience in the Agile community, one thing I’ve learned is you can’t transform anybody, the team has to be ready for transformation in order for an agile coach to actually submit, you know, their learnings to the team for them to grow. So any team that I’ve worked with their readiness has made a huge impact and how I have been able to make any impacts on their progress. That’s my core belief. And with that, I am going to start about dojo.

Okay, so agile transformation journey at my company. It was, it started, say, about five years ago, right? Before then we were waterfall, you know, very laid back. You know, we got to plan everything upfront, then go for, you know, deployment and deployment. So you Once in a once in a year maybe you know if you’re lucky twice a year thing that used to happen about five years ago. Then agile came in, you know the process, the excitement that it brought, I myself was transformed into becoming a scrum master during this transformation time, which was great.

What we learned in these five past five years is we weren’t doing agile. We weren’t really being agile. So what’s the difference, right? For example, we’re talking about I want to do sprinting, I want to I want to do a two week sprint, great, but what does that, you know, if you’re going to take requirements down, if you’re going to do coding on it, if you’re going to deploy it, you know, in sequential fashion, you’re doing agile, you’ve got the process, they’re great. But really, you’re not being agile, you’re not really, you know, learning to work with each other more effectively, really bringing in that vertical slicing into how are you how you are trying to get the feedback from the user and things of that nature. So there’s a lot of handoffs. And as a result of which it we’ve got, we’ve got automation. Again, we’re doing agile, we have automation to make things work. But it’s very clunky. So sometimes it takes, you know, hours, sometimes it takes days for an automation test to run, which is super heavy. And also the code base, which was, again, very clunky, you know, less unit test centric, and therefore, like I said, we were doing agile, we were not being agile.

And so our leadership went to Target and not to shop them, but actually to learn how they have transformed their life. And so what they have done is they about a tip ups. Ha, I can’t I can’t recall the number was I think it was like four odd years ago or something, a target went to their own transformation through dojo. And what they did was they basically hired a bunch of consultants, you know, started this dojo model and Target and really, you know, started to transform their product company into being being a bit more agile being a bit more customer centric, getting that feedback out there getting themselves out there, right. And so this is this is their websites page that I took the screenshot off. One thing that stood out for me was a few of these things here in their mission statement.

What dojo does for them is that deliver on the current work that develop long lasting skills. Now, if you think about that for a minute, right, you’re you’re delivering on the current work while you’re in dojo, that’s one big item, which basically says, “Okay, I’m going to a class, I’m going to learn on amazon shopping cart, how to apply test driven development, but then when I come back to my real world, it’s not amazon shopping cart like simple, right? It’s a little it’s more complicated. It’s difficult. It’s real life. How do I play it?” The neat thing about dojo is you work on your current backlog, right? You bring your backlog into the into the dojo and you really work together and learn together. Another cool thing is developing the long lasting skills. So the way that the dojo model is baseline set up, is it is intended to develop your long lasting skills. Yeah. So repetition, going back and forth, enhancing you know, how you are adapting the new processes and new tools that you’re learning to, to best fit your needs. Those are the those are the very important things that you’ll see when you start to apply dojo or you start to work in this model dojo. Right. Oh, and by the way, I totally missed out. I am going to pause midway through this presentation so I can take questions. That way we can split our presentation into two parts, and also it gives me a breather from not talking too much.

All right. Alright, so I’ve talked a lot about dojo, what the hell does it mean right? In dictionary terms, it means place of the weight, right? And Napoleon diamond, that picture here kind of gives you a little bit of a view of Do you know he’s there, he’s showing some most of the players that are sitting there, right? When my son he is now going to be 13 this is when when we started, he was 11. I told him about dojo he goes, “Oh, so you’re gonna have fun at work, right? You’re gonna do dojos This is fun. This is exciting.” We got so when I explained to him what we do and how it is a little bit different than what you as an 11 year old don’t do in dojo. The thing you said stick with me. He said. “Oh, so it’s a nerd stuff.” That’s like, okay, but not quite. It’s not that nerdy. It is some sort of nerdy so let’s kind of try to unpack what, what that nerdiness is right let’s let’s go with with that. And then let me let me land you to where you know, it is sort of in the in the middle ground.

Okay, so let’s take to take you through the definition of what it means in the world of software development, i.e. the nerdy stuff, too, according to my son. It’s a six week deep dive in which teams set some goals in terms of technical, business, and product goals They identify some success metrics, iterate rapidly, sharing their progress and learnings while all being supported by a dedicated expert. Now, six weeks right, so let’s talk about six weeks. Dojo, a recommendation of a typical dojo can be anywhere between two and 10 weeks, right? The reason I kept six weeks here is that isn’t the most commonly used sort of cadence for a team in dojo.

The reason is, it’s again going back to the repetition, right learning and building your muscle memory. Each week in a dojo is two weeks sprint, I mean two days Sprint’s are so two sprints in a week, right? Therefore, if you if you look at a six week window, you’re getting about 10 to 11 iterations, give or take to do your rinse and repeat and learn and go back and fix what you’re learning and how you’re learning. So you can develop a long lasting skill, right? And you are repeating those, those small iterations as you go, it gets a little uncomfortable, but remember being uncomfortable is a good thing. That means you’re learning something.

So that it basically that six weeks is what we have been using in my firm for the most part. In some cases, we do use a four week dojo, some are two weeks dojo, and it can go anywhere up to 10 weeks. Anything beyond 10 weeks is sort of considered, “Okay, well, you know, let’s, let’s tone it down a little bit because you want to learn something you want to stay a little bit focused.” Okay, so, another thing I call out here is the dedicated experts, so people like me, I’m a Product coach, right. And I was trained by the builder coaches to work in this environment to teach the skills and techniques to the, to the, to the teams. And so each team in dojo is paired with a technical and a product coach. I am a product coach, I come with a technical coach into the dojo so that we can merge the learning of the team from not only taking a chunk of work to start to do a software development on but also to apply the technical skills to make this a reality and help the team to kind of move the work from inception to completion. All right, so with that, I’m going to show you in the real, you know, setting of where, where we work together and how it really looks like. That’s what it looks like. It’s really exactly that. It’s a table you know, people are sitting across each other. This is a thing a picture from Target retook.

The team is kind of covered by boards, there is a big one monitor screen at the very center of the team. They’re all looking at it in this picture. I think there were mobbing in this situation. But um, the idea is to have a dinner table style setting right? Face to face from each other. Let’s let’s go ahead and have that conversation right here learn from each other, and grow together. Right? So it’s the entire team entire scrum team that basically sits and sits in this dojo for six weeks, like I said, as one of the very common examples.

Now you might ask, it’s COVID girl, is it going to happen? Is it going to happen in, you know, the virtual world where it’s crazy? It does happen. We have made it happen. We are very proud of it. And we moved to a tool called mural in our case. This page right here is a snapshot. There’s a lot going on here, and this is after a six weeks work with a team in dojo. There’s a lot going on, right? There’s, there’s, you know, setting the goals to the teams to like, how are they managing their daily work? How are the decomposing the work? What is the technical architecture looking like? What are what are retrospectives? Right. So how are we doing things.

In fact, in this example, it reminds me if you look at that pie chart right in the middle, that’s basically me teaching them how to size the body of work. So anything and everything that we would do in a normal physical world? Well, when we were separated just by a small table, we bring that into this virtual world by a tool like mural. There are other tools out there like Miro, Microsoft whiteboard and things of that nature. But this has worked fabulously for us, allows us to bring all the colors the cards, the the fonts, the the nature of you know, how we want to express things out there available for us now.

Well, now I want to I want to kind of get us into. Okay, great. There’s dojo. We do it for six weeks. You know, we have some coaches here that are actually supporting us through the process. What great, what is the basic fundamental of this model? Is it a methodology? Is it a model? Is it some sort of science? What is it right? So how I would describe dojo is it’s a model, it’s pulled from the best practices from lean, XP, agile, you know, it’s basically taken the best of the worlds and brought into reality of, of how we work together as a team. Therefore, it’s dense on some core principles. And there they are. I’ll read them out and we’ll unpack each principle as you go.

The first one is learning over delivery. Second one, get real. So get through product mindset, high collaboration, team driven metrics, and visual context. And we’ll unpack each of these as we go.

So let’s talk about the very first one learning over delivery. The picture here, I love this picture here it says Turn it up and turn it down, right dial it down. It’s the basic fundamental that we bring the team with when they come into dojo is this exact, this exact line, dial up on learning and dial down on delivery. Right. So let’s unpack this, right, it means it’s easier said than done to begin with, right? We all have release cycles. The team is always doing things. They’re busy. You know, life is crazy. You’ve got meetings, and especially if you come from an organization like mine, we live on Outlook, right? We’ve got tons of meetings and you know, we get pulled in so much in different directions. Well, we put a pause on this, we say all right. You’re here for six weeks, all you’re going to do is focus on learning. Take all those meetings off your calendar, and let’s create an immersive learning environment for you. Where you can actually sit down and say, Alright, what is it as a team that I want to learn? And how am I going to do it? As opposed to I need to go to X meeting and I need to go to Y meeting. It’s you know, highly focused on saying, “This is my six weeks time, I’m going to focus on learning. Yes, I will be continuing to work on my backlog. Yes, it will be a lot of learning and therefore, the delivery is going to have to slow down a little bit.” Right. So a release that you were expecting to, you know, submit or deliver. I don’t know 10 stories that may not be the case your velocity will dip it probably. Sometimes it takes a dip of 50%. Right. And that’s okay. And that’s where you know us as coaches we work with the leadership to clarify and explain the reality there.

The other idea here is, when you’re focused more on learning you’re trying to develop we as coaches are trying to develop your muscle memory. So we’re working with you, you know, every day for the six weeks, consistently focusing on rinsing and repeating the skills that work best in your environment that are catered just for your team.

Okay, let’s get to the next one, the get real one. I love this one, the full backlog. And it’s a quote, “Tell me and I will forget, teach me I will remember, involve me and I will learn.” Right? So soak that up, right. So if I’m doing something with my six, year old, yeah, she’s six years old, my daughter. I keep forgetting how old she is now. Anyway. So if I’m working with her, if I’m teaching her how to do math, she’ll get it. She’ll probably get it. But if I’m doing it with her together, kind of you know involving her and using the hands and using, lately we’ve been using playdough believe me it dries pretty crazily. But if I’m involving her into the into this conversation and I’m doing the numbers with her, you know, and we’re learning from each other, there’s a better chance that you will not forget what eight plus two, although she won’t know what is two plus eight, that’s a different story. But you get the gist, right?

So if I’m working with you hand in hand, if there’s a better chance for me to, to assume that you’ll you’ll read more from me. You’ll learn more from me. And that’s what this is the real backlog. All right. So let’s bring the real stuff into the table. Let’s talk about what what was it that was planned in your backlog? The day before, you know, you come into dojo, let’s talk about that backlog. Let’s go ahead and unpack that. And let’s, you know, let’s make it a little bit real, right.

So it’s not it’s not a amazon shopping cart example. It is your example. It is your backlog, it is your real life problem that we are going to transform and solve together while transforming your team. In these two pictures, I want to show the contrast, right? So in the first one, you see there’s an instructor sitting in front of the screen showing, you know, some things and teaching some things. While it’s great, it’s important. And this is not to discount the fact that a training program does not work. It works. Right. And this is also to say, there are some instances in some cases where you want to, you know, sort of, if you look at the next picture, you’re really working together and making that learning happen for your entire program, entire team. I’m sorry. So that’s real backlog.

Let’s look at the next pillar. Oh, yeah, this is another joke right. So this one is about team velocity. Well, like I said, it does dip it does slow you down, right? That does not mean if you look at the last picture, that does not mean let’s go ahead and get bigger estimates, let’s, let’s use, you know, higher story points. 21 story points. Yeah, no, no, our our goal in dojo is to work with you to create smaller chunks and we’ll we’ll unpack that as well as we go along as the next slides come through. But really, the point I’m trying to highlight here is when you bring in your real backlog, when you are focused more on learning and less on delivery, the velocity does does take a hit. And that’s where you want to include your involve your leadership into conversations with the dojo coaches to explain as to why and what would be the outcome, if they invest in disrupt.

Let’s go to the next core principle product mindset. Another big one. Well, so so I want to take a step back, right. So when we talked about we were doing agile versus being agile, right? Okay, I’ve got a story, I’m putting certain points to it. Awesome. And, um, you know, let me start working on let me start coding this right. What’s important in today’s world and as a as it’s shifting as it’s increasingly, it’s increasing in technology and the creativity that needs to be brought in and, and so much so much changes around us just like that. The other day, I was sitting at work with my coworkers, we were hanging out the very next day we were told to go home, don’t come here. This is crazy time. Let’s go remote. Right?

Things changed for us. Technology came to us, to us to our Savior, right. Similarly, when we talk about our backlogs, and we talk about, you know, what it is that we want to work on, the importance that we miss out is how do we connect that work with who really needs to do who needs this work from us? Who’s going to be the user for my work that I’m producing? Right, what’s the product that I’m building? Versus I have a scope of work? I have a start date and an end date. I’m going to finish it in this time, no matter what. Do you remember project, project timeline, this, the the Gantt charts, the fixed scope, start date, end date, you’ve got to stick to the flow, anything changes, everything has a you know, as a ripple effect, and, you know, it feels to me as a house of cards actually fallen, right? The project plans, the dependencies, right? If you can’t do certain step in a certain timeframe, there’s so many more people that are going to get affected. Yeah. Versus the thing that we teach in dojo is let’s shift that thought process from having a fixed scope to something that is more adaptive, something which is a bit more outcome focused, and is actually helping your user, your end customer who’s actually going to use the solution that you’re building today. Yeah. So this bit this becomes a very basic conversation that we work with the teams day to day, from the very first time we meet with them through the six weeks, is to slowly shifting their mindset towards, you know, developing a product mindset as opposed to saying, Okay, I’ve got a story I need to start working developing on it. I’m going to do testing on it, I’m going to deploy it. Let’s try to understand who am i doing it for? Why am I doing it? Right? So so there are series of conversations, series of questions that we ask to make this mindset shift happen.

Let’s go to the next core principle, high collaboration. Even though we are in remote or when we were in person, we can’t stop talking, You’ve heard me talk. We cannot stop talking. We talk, we converse with each other. It’s funny, we talked about, you know, put yourself on mute for a minute now, in our case, it’s everything’s off mute. Let’s go ahead and have fun. We can hear the kids. People hear my kids all the time, though. They’re quiet right now. Wait, wait, they’ll show up because they know, when we’re working together in dojo all day long, you know, it’s off mute. Let’s talk about things. Let’s try to solve the problem together as a team. Yeah.

Techniques we use for collaborative conversations and development is mobbing, diverge/converge, pair programming, and things of that nature.

All right. Next one, team driven metrics. So team driven metrics is really saying all right, bottoms up, you know, let’s let’s talk to the team as to what is it that they want to learn how they want to grow? Right, what is their goal as such to become a better team? Some examples here in my picture from Mural board, one of the team said, I want to do you know, we want to to develop quality code. Well, then we start to unpack what that really means, right? Do you need to take some actions to make that quality code goal really happen? And then if you are taking those actions, what are some of the measures that you’re going to take to come back and say, “Okay, you know what we use this action. Here’s the metric to show that this, we have made this action happen, that we’ve internalized this, we’ve learned this skill, we’ve actually grown together as a team.” So it’s really a bottoms up approach where the team really sits down and says, “Well, these are some of the things that I need to work on. And there are these are some of the metrics that I’m going to, you know, use to share my progress. And understand that, you know, we’re working in the right direction that you’re using those actions and things of that nature.”

All right. Last one, visual context, I think you’ve seen a lot of visuals that regardless of being remote or In person, there’s quite a bit of that. Here’s another snap from the mural board. This is a story map. And you know, we work with the end user in this case to develop the story map from what they do and how they do things in real life. And we map that into a I love to write story map there, the variances are at the bottom or the vertical steps.

And in this example, blue is the system interaction and gray is the user interaction and things like that. We are very visual about our approach. As you can see, the blue is sort of talking about the system interaction, the grays talking about the manual interaction, and then there are lines that are going through those are basically journeys, MVPs if you have heard them. So, very regardless of like I said, in person, or virtual, it’s all common collaborative, visual representation of how we understand things together.

One of the key things I’d like to highlight is we strongly believe that, you know, one thing is if I said something to you, you may have understood it differently. But if we understood whatever it is that we understood, if you’re able to put that out on the board in front of everybody in front of the team, now that understanding becomes a shared understanding. And that’s the step one to our growth. And therefore, you know, anything and everything that we do, we talk about, we start to write them to the board on the board. And that’s very, I think it’s a very important technique that we utilize in dojo to enhance that six weeks window into the most value delivered set of time that we spend with each other.

All right, and I have talked a lot I’ve talked about all the core goals. I’m going to pause for questions. For now.

Host  Awesome, everyone, you were muted upon entry, but you can unmute yourself if you have any questions.

I actually have some questions. Who would go to a dojo? Is it like for only new teams? Or is it for existing teams? Or does it matter?

Arushi Bhardwaj  That’s a great question. And actually, it doesn’t matter. It could be a new team. Again, remember, so anything that we do with the teams. Anything that we do with the teams?

Right. So it’ll come back to me but um, anything that we do with the teams is teams driven. So they bring their goals if they were a newly formed team that goes could be completely, you know, can you help me understand your story estimate? So how do you really create user stories versus if it was a performing team that has been in this world has come together and been with each other for a while verticals would be something different.

Host  So would you recommend dojo as a, I guess, a method for helping a company to start in Agile transition, transitioning to agile teams?

Arushi Bhardwaj  Yes, I think I think and I took a long pause because I think, I think to transform a enterprise or a bigger body of work, there needs to be a lot more that you need to do, as opposed to just working with the teams. And so what we have, what we have is basically the product development and the technical Implementation of how you use your solution bundled into one. So you can use a product dojo specifically to work with your product teams, or the product managers to transform their journey versus, you know, a technical team, bringing the product and the technical together to transform their journey and so forth.

Host  So, one more question. I’m sorry, I know others probably have questions too. But so you say a product dojo, are there different types of dojos?

Arushi Bhardwaj  Yes, and it’s a great question. Yes. And there are so many out there now and this is exactly why I was inclined towards titling This one is coding dojo. Because majority of the work that we do in this specific dojo is on coding practices development, of course, there’s there’s a bigger piece of product development and, and that basically goes hand in hand. But this is basically a coding dojo. Now, the difference is, if you were to work under the umbrella of a product dojo, what would happen is you would come into a dojo and you’ll rinse and repeat on how you experience a certain body of work that is coming from the end user.

So remember, I showed you the story, map, your drink, and repeat. Those are those different techniques, you’ll learn different katas and you’ll be working day in day just with the, with the product coach. There are DevOps dojos, which are specifically to build your CI/CD pipeline and really start continue to rinse and repeat. And this goes back to I think Gene Kim is a big fan of DevOps dojo. I think those were the starting points also from what I recall, of dojos into into the world of software development. So there are multiple different kinds. Recently, I was reading a book on agile conversations, and I spoke with the author and what came up was conversation dojos. That’s pretty Yeah, and it’s got it’s got like all kinds of different techniques that you can use to, you know, develop your your conversations styles in an agile environment.

Host  Interesting. I wonder if they’re coaching dojos I might need to start one I’m gonna have to..

All right. So what about others? Um, either questions, comments or even experiences that you’ve had in the dojo. Anybody have anything you want to add? All right, it looks like everybody’s all good. We’ll let you continue.

Arushi Bhardwaj  Cool. All right. So I think I’ve talked a lot about six week dojo, right. And I’ve said that it’s it can be anywhere between two and 10 weeks. So what I’m going to show you now is. What really happens in the six week duration as an example, you can shorten this you can expand this into however, however many weeks your dojo is aligned towards, but six weeks is a good way to kind of give you that feeling as to what what we do within dojo, right? And we’ll go step by step.

So we’ll start with the first one is the intake, which is a week before dojo. And this is a unique opportunity where we actually the coaches get to work with the teams on you know, getting to know them, understanding what their life is, right now, onboarding dojo, explaining, you know, what it is talking about the mission statement, setting some of the commitments, right expectations. Remember I talked about, you know, the calendars and, you know, we are so much meeting centric firm. So this is where we kind of, you know, kind of come to like an agreement as to what would our six week look like what’s a core hours going to look like. Developing the product mindset is one of the big things that we do with the team in this intake. And start to understand the context as to where they’re coming from, what is their real life like right now.

Some of the techniques, it’s another snap from Mural. You can tell already, I’m a fan of that tool. And so basically this, these are some different activities that we use to kind of work with the teams getting to understand them, getting them, giving them the opportunity to know us, and vice versa.

And then comes the frame, right. So the day one of their six week challenge is framing. Lots of activities happen in this time. This is where we are setting our goals, our planned forward, how are we going to, you know, work with each other, in terms of visual context is another one.

These are all flip charts, handwritten stuff, that basically this is an example of framing, these pictures here. And what’s happening here is, there’s a lot going on, it’s probably like a two day worth of work on these flip charts. This is to kind of, you know, understand where the team is in terms of their skills, right? Where are they right now? How much do they know? What do they know? What do they need? And, you know, how can we provide that if I don’t have that skill? Who can I go and talk to? To help them upskill that skill, right?

What are their goals? What is it that they want to learn together as a team so that they can grow together? You can tell the middle picture, the very bottom, when we were in person we used to actually take signatures, you’re committing to this, we’re gonna do this together for six weeks, we’re gonna hang out, we’re gonna make you know, make this part of our journey for the six weeks to transform our team together.

So a lot goes on in the framing. Specially i’d like to call it as Setting the foundation for how your six weeks are going to go. Right.

The next is, you know, and the six week starts. I think I talked about the iterations. There’s there’s two iterations per week – super small. And so that process that learning process starts after we have done but after we are completed with the framing. And that’s basically getting us into discovery.

Lots of techniques, nothing new, nothing, you know, crazy new. These are, you know, if you’ve seen all these images, you did reminds you have Jeff Patton, you know, see for I think, you know, if you’re into technical implementation, you’ve seen those, we basically this is just a snapshot of some of the things.

There are many techniques that we use in dojo, whatever fits to the team’s need, what we can bring. And we basically, you know, look at their backlog. We say, “Okay, well if this was your body of work that you’re bringing Let me let me go ahead and go back to your to understanding what are you doing it for, why you’re doing it right. Let’s build a story map. Let’s try to understand what vertical slicing is.” So that’s, you know, my skateboard. Not like the cars. The second picture right here, Henrik Kniberg, came up with this and, and we use this a lot right and let’s go ahead and build a skateboard. Let’s start with a very small, important valuable body of work that can actually provide you enough feedback, enough learning about your work as opposed to saying, “Oh, if it’s not a Mercedes that I’m building, it’s really not, you know, what’s the point?” In real world we say, “Okay, if I were to ask to develop a report, if I don’t have all the 25 columns of the report, there’s no point in going and talking to my end user.” Well, there is right? If you were to build the first very important five columns in that report, if you bring that out to your user for a feedback, you’d probably be amazed with what you learn from those first five columns.

So those are the, you know, as conversations that we have with the team as to you know, teaching the world at least like how to order a slice the stories, how they can build a smaller body of work that will fit in two days. Remember, two days sprints, so two sprints in a week – that’s a that’s a very, very small iteration. And so no joke. We do work with the teams to create stories that will fit in two days that will give them enough learning so that they can continue to build smaller chunks of work as they learn more about the body of work that they’re developing.

See here’s another example. If it’s you know, if it’s an application much like you know, a lot of our applications are like this that don’t have a front end, right. And if I touch anything in the code it’s going to impact so many upstream and downstream. Well, you know, let’s try to understand your architecture. Sure, and so we bring C for like techniques where it’s a, it’s a drill down version of, you know, let me look at your context diagram, then drilling into the components, I’m sorry, the container and then drilling into the component. And then let’s get into the code, you know, where the changes are going to be made, and so forth.

So a lot of techniques that we bring into the discovery phase to make that backlog more real, and you know, asking the questions, attaching our team back to their user, and, you know, continuing to develop their product mindset as they are solutioning. Another lovely example, is example mapping. There’s another one we highly, recommend and use a lot in dojo as well.

All right. Here’s, I think I’ve talked a lot about hyper iterations. But here’s the bulleted version of it right? So 10 challenges, two times a week, very lightweight sprints, and I’ve crossed out the part ceremonies and feedback loops, right? So really the idea of free two days is to go out there and work with your product owner to get the feedback, right. It’s not a ceremony. It’s not saying, well, you asked for a grey color, I gave you grey. Now, if you want a different combination, I don’t know what you want me to do. Let me and what we do is in in this kind of feedbacks is we take the feedback, we take step back, we discuss with the team, we come back with a revised plan, right?

So it’s not it’s not the, it’s not the back and forth. It’s to get the feedback. It’s not to look at what I’ve done, like look at how cool this gray color is. It’s to take your feedback because it is what you are used to seeing. It’s what you need, right? I’m developing a solution for you. And here’s what I have learned so far. So we teach and coach the team through how these feedback loops really should be, you know, designed and worked with their end users, or product owners. Or even in some cases You know the Sprint’s are so small, some cases we just, you know, kind of bring their techniques and say, “Okay, this is what this is what we have so far. What do you think? What’s your feedback? This is what we have learned.” It really depends. Pull and flow based system, sizing over estimation, right, encouraging small and vertical slices.

Host  Can I add something before you switch pages? Is that ten talent challenges over the whole dojo? Or is it 10 challenges a week?

Arushi Bhardwaj  Oh, so 10 times, right. So, so there’s, if you take six weeks, and each week is two sprints to two iterations, right? Initially, when we start the dojo, there’s about framing, there’s some time spent in that sometimes spending and discovery you know, getting to understand the team and really getting that flow going. So you know, if you want to divide six weeks into two You’ll get 12. But you know, we’d normally don’t get to those 12 the first week is a little, you know, little iffy about getting into the sprint challenge. So 10 total iterations.

Host  Okay, I get it. Thanks.

Arushi Bhardwaj  All right. Here’s another picture of how we work on our feature and roadmap. So this is, you know, once we’ve had our discovery, once we’ve had our frame, how are we going to manage our sprints as to how we’re how things are going to go every two days, right? And that’s kind of you know, we use a feature roadmap to help us visualize what’s needed now, what’s going to be needed next, and what’s going to come later. By the way, whatever is in later bucket half the time it changes because what you’re learning from now and potentially from next is going to take the shape of that later. And the other image here is, you know, the Kanban board. You can tell from this Kanban board… This is weird. looking right there, there’s WIP, there’s finally done. There are some, you know, rows to the bottom, what’s happening? What’s happening is it is cater to this particular team’s need. This team’s definition of done says, “if my product owner accepts the story, I want to call it done.” Well, my goal was to take them a little bit step further and say, if it’s done, if you have had a chance to work with your end user, and try to understand to get their feedback, then you’re finally done. So just adding another column and getting that conversation going and slowly nudging them to bring that finally done column into done was my objective. And that is why I took this picture because it’s an interesting one where we would design the dojo for the team’s need, with the intent to go back going, taking us back to those core beliefs that we have in that I laid out in the beginning. Okay, lastly, exit and this is where, you know, I love this. This part of dojo is because, look, you spent six weeks with us, you know, you’ve learned a lot, you probably have hated a few things, you know, yeah, we made you uncomfortable, but it wasn’t fun sometimes, hopefully, sometimes only. But this is where we kind of sit with you and say, “Alright, you’ve learned so much. What is it they that sits well with you as a team? What do you want to take with you? When you go back to the real world? What are those things?” Some teams have said, “You know, I love the two day sprint though it’s not possible in the real world because you know, delivery focus and you know, it gets busy it’ll be too much and all but I don’t think I can sit well in the in a two week iteration either. So maybe I want to do a week iteration.” Some cases teams say, you know, I love the whole mobbing concept, but I’m going to do diverge/converge for the entire time we work together. So we kind of work with you know, what are their team agreements, what what is it that they liked, what do they want to continue to do? And how are they Want to frame the future as they leave dojo? So this is where it ties you back to the work world, right? Like, okay, you came into this, in this immersive learning program, you took a challenge, you work together as a team, you build something you’ve learned something along the way, hopefully a lot. What is it that sits so well with you that you are going to at least focus on, you know, applying when you go back into your regular sprint schedule. And so those, those conversations happen towards the very last day of dojo. And we give them a certificate of achievement, I kind of first got the names of people just to protect them from you know, this is a Fannie Mae certificate, but, you know, to make it official, make it you know, make it more real that, you know, you went through a challenge. You finish that in six weeks, you know, to build that excitement that you’re going to continue to build to take those things that you learned when you go back.

And before I switch to the next slide I want to point out one more thing. Us as dojo coaches, we do continue to work with the teams when they leave. So our doors are open, they can come in, they come in for a session or two, they want to clarify something something’s a little bit more challenging, but you know, I’m doing I’m writing my unit test now. But that test first mindset that you talked about can be can be reinforced that can we make that happen again, we go back for a session, “you know, Arushi, the, you know, the product backlog the story map that you went through, I loved it and I want to use it but I’m having a hard time doing it.” So we go back and you know, we sit with them as a product coach to go through another story map and so forth. So so we do continue to check in with the teams here and there to see how they’re doing are they applying things that they had, you know, so excitedly kind of talked about in their exit isn’t working. What have you

Now let’s talk about the outcome. Right? So took me a while to wait, you know, the teams have graduated what’s happening. So the first image here, but what you see is a cycle time of a specific team. The yellows are the time when this team was in dojo. And the blues after that is when they have exited Dojo. Notice the spikes. Notice how big the cycle time was before and notice how small it is now. In other picture, the story cycle time, averaging days, right? That not as a trend line, right. The idea is to bring their story cycle time down enough so that they have understood the concept of building smaller chunks of work that by the way, these two are different teams, completely different programs. You know, these two have gone through dojo with us, and I’m just, you know, putting an image out here that there was a 25% you know, improvementin cycle time we saw in one of the teams when they when they completed and we saw their life after.

There was actually another metric that was very striking for me. There was a 17% drop in production incidents. The world we live in, in my company, there’s a lot of production issues. And you know you you know you got to go work at it right away, you know, day night, whatever. Having to see a 17% drop in that havoc. Awesome. I thought that was really cool. And I immediately from that number down those very, very proud.

38% improvement in story sizing, 20% improvement in unit test code coverage, right. So a lot of changes that happen not only from the product from the technical side, they’re bringing the team that developing the team as a whole. This experience did that for them. One of the teams that was there, they weren’t graduated and they were leaving dojo in their exit. They said the following, we came into dojo as a team, and we’re leaving as a family. To us, that was a bigger outcome that we were that this experience brought the team together, taught them how to learn from each other, you know, face each other’s strengths and weaknesses and work with them, not just calling them out and using that against each other. So to me, that definitely was a bigger outcome. However, in terms of metrics, here are some.

It does work. It does need a whole lot of support from not only the dojo coaches, but the leadership does the ecosystem altogether around and the next slide is exactly speaking to that the above the key contributors for how you know you want to see those changes, those potential outcome that you’ll see in your team. I kind of categorize them in three buckets. One is leadership, the others team members, and the third one is coaches. Now unpack that, in case of leadership, what’s expected is, don’t put delivery pressure, you’re gonna get a higher quality. What’s expected is protect your team from distractions, right for the meetings and things I talked about, you’ll get as a focus learning as an outcome, support and motivate your team, you will get creativity and innovation as a result. And there are many examples to this. What I’ve seen are leadership, you know, coming in and talking to the team and saying, “Okay, guys, you know, don’t worry about other things. Don’t Don’t worry about delivery. It’s okay.” And what we have seen is how the team has actually internalized that and brought a better product a better quality product out to their customer. Faster, robust and effective. So this is this is my personal experience that you know, having a supportive leadership definitely helps.

Team members, what we expect from you is to prioritize your time. Keep an open mind, try to think outside the box, what you’ll get is complete presence in learning, quality and a break free from the defined mindset. This is one of the bigger ones, right? I tend to see so many aha moments when we are, you know, when we’re progressing through the dojo, because what happens is, if I bring a product, if I bring it big body of work, and I start to, you know, break it down into smaller chunks, and how we kind of do this in dojo, you know, sort of like a bottoms up approach with the teams. You start to see, “Oh, my God, those are the questions I had didn’t think about. I know I was going to ask those questions, but it’s going to come up Later in the game, right?” We bring those out front and you and we get to see so many aha moments. There’s one big story. I remember when I was with a group as a scrum master. We talked about having to apply TDD, for example, the test driven development. And I was like, “Why can’t you guys why can’t we do this? You know, we should totally do a test first, you know, code development. Why are we doing it?” Well, then I learned they had gone through a training exercise, which was fabulous, great feedback. Awesome. But then they said, you know, Arushi, real world is so different from what we learned. It’s just so hard. You’ve got delivery timelines, we’ve got sprint schedule system. It’s just not possible. That same team six months later came in dojo, same mindset. I don’t like, I can’t do this whole test driven development. This is just not gonna work. Six weeks later, their first goal to leave to coming out from dojo was to consistently work through a test first mindset.

So basically this defined mindset of, “I have delivery pressure, I’ve got to do this,” versus “You know what, I know this works, I know this is this is going to give me quality down the line.” Having to go through that experience in the six weeks was an massive experience for me. I was like, “yes, that’s right.” And then when I checked in with them, you know time and again I still do there’s still you know working towards that goal of having a test first mindset, really cool.

Lastly, coaches right so bring your coaching skills, show don’t tell, be outcome focused, have that thought leadership, call it out, call spade a spade, be open and that is exactly where should we I’m gonna say this out loud. That is where my learning From ACC and, you know, getting into your cohorts has really helped me develop that skill, right? Calling it out being being are being direct listening has definitely helped, but expected outcome. You get to deliver results. You have hands on coaching and you ultimately have satisfied customers. There’s nothing better than having your customer come to your dojo exit meeting with all smiles with all… You can totally tell their body language that there’s accomplishment, there’s satisfaction.

With that, I will take questions.

Host  Awesome. I have another question. I am really interested in understanding the more of the How do you see teams run differently, like after they leave, they’ve done all this stuff. What percentage of what they’ve started doing do you think they actually, when they leave the dojo they retain? Is it like 20% 50% 80% and just a wild guess not a calculated number.

Arushi Bhardwaj  You know, what’s exciting, is they go back and they say 90% of the things that I’ve learned, I’m gonna totally do it. They’re so excited. Did they get to apply all of that? Not necessarily, and not really, right? I would say about somewhere upwards of 70% is what I see them applying and the 30% gets somewhere lost in the wind and, you know, brings that opportunity for the teams to come back into dojo and re hone on those on those skills.

Host  Awesome, I really love this Arushi this was a great presentation. Anybody else have questions, comments? Maybe you’ve been at a dojo and you’ve got some just thoughts of, you know what your experience has been?

Guest  Hi. Hi Cherie, hi Arushi. So yeah, I joined late. So I’ve got, I think few questions on this, dojo is just about learning new skills, regarding this timescale of six weeks, how does it fit into obviously we mentioned that leadership don’t progression and delivery. How does he is that six weeks sprints is like continuous working everyday not doing the product work or basically announcing your skills in the dojo.

Arushi Bhardwaj  Now, so it’s, um, in the beginning of the slides that kind of shared that, you know, you bring your backlog. So whatever it is that was assigned to you in the sprint, you bring that into dojo, right? And you continue to develop your skills while you’re working on the real life problems, right. So when we weren’t with them, we don’t work on, you know, and sometimes we use examples but sure, but for the most part, it’s your backlog. It’s your problem. We work with you how to split that into smaller chunks. We use different techniques like C4s or example mapping, story mapping, however, whatever works for that particular body of work to decompose, to create smaller chunks, and then a technical coach will work with you, hand in hand, through that time to improve your skills. So going back to the goals, right, like what is it that you if your goal was quality code, then we’ll bring principles of you know, YAGNI, and other core principles of code, software development, to kind of work with you on on those skills.

Guest  Okay, thank you. And those coaches, technical coaches, could be architects or tech leads within the team, right?

Arushi Bhardwaj  No, sorry. So, when we start dojo, we start with a duet of product and technical coach. They’re trained into providing coaching to the team in this under this model of dojo. So remember the four principles that I’ve talked about, they are trained to kind of use those core principles to, coach the teams and their needs. Right? So I, for example, am a product coach, I will be paired with a technical coach who will then go into the team, start their challenge and work with their body of work.

Guest  Sorry, last question. So, obviously, we do SAFe and we do PI planning. So, we obviously get the objectives and plan upfront for next few months. And then using these if we want to do dojo to we should plan saying, “Okay, that’s the backlog but we’re gonna take 20-30% of the backlog and then do dojo as well. So 50% of time spent on dojo and 50% of the time spent on the product code. No. Oh,

Arushi Bhardwaj  No, let me help you clarify. Right so, I actually so let’s put up. We have worked with a team that was SAFe in dojo and what we did was we went through their backlog. All right, we, right off the bat, we’re very clear that the velocity will drop. It’ll dip, dip and drop, mixed it for me. But it will dip and you know, that’s and of course, that was the conversations, the leadership of course, and so from their PI plan, however many velocity points they had, they shrunk it down to 50%, that brought the body of work that was necessary, and they were with us in dojo for the entire six weeks, so there’s no different time that they’re spending outside of dojo. Just think of dojo as just their day to day life. Right. Four hours from 10am to 4pm, where they are, you know, face to face with the coaches and They work with us. And it’s consistent. It’s no different.

Guest  Okay, so basically do it together but obviously plan ahead in the PI planning thing. Okay, we’re gonna 50% we’re gonna Yeah.

Arushi Bhardwaj  Yeah, and it has to happen.

Guest  So I could see that working while I’m working the moment we because we have efficient teams and they get the basis quiet and and some new commerce they don’t know the scripts like Python how to do automation testing, you know how to do regression testing. Maybe that’s a good idea. Our goal for today was to I can’t do this dojo obviously joined late because it was for me it was coming up at 7pm UK time. So I joined back off in my late initial slides. So that that’s okay, so yeah, I’ve got an idea. Cool. Thank you. Thank Arushi.

Arushi Bhardwaj  Y ou know, like I said it’s it can be applied anywhere in another system in any need. I think the core is the principles that sort of keep the focus on what is it that we’re providing? How are we providing that value to the team?

Guest  And definitely a solid improvement, isn’t it?

Arushi Bhardwaj  Yeah, and like I said, you see so many aha moments, but it’s so easy. You know, I’ve been with this coaching model for it’s gonna be two years pretty soon, I can’t even say a year and a half anymore. And I’m, you know, we learn every day on the job. It’s crazy, is because…

Guest  Yeah, and I can see that like working because people don’t get thing don’t get time to actually improve themselves. Because there’s so much pressure of product. Let’s do this delivery. We need this delivery. If we plan ahead 50% of time is all improvement. So they’ll be better in three months time if after PA the next PA they’ll do better and then we can deliver more Yeah.

Host  You’re welcome. Any other comments? Thoughts?

Arushi Bhardwaj  Gopi’s got his camera on?

Host  Yeah, there he is. I know.

Arushi Bhardwaj  Hi, by the way people.

Host  Are you a technical coach? Are you another product coach?

Guest  A product coach, mainly but with my technical background, it does definitely help me in coaching parts of technical areas. Definitely.

Host  Yeah. Really.

Arushi Bhardwaj  You are a mapping guru.

Host  Yeah. Well, this has been so fabulous. I am. I’m a fan and I’m like, I’m kind of jealous. I wish I could do this. So I’m really really excited about this. So I just appreciate that you have given this presentation and thanks to a couple of people had to drop off because it was, I guess, whatever time but had some comments in the chat box, thanks.  It was a great presentation. So I just appreciate you all coming and looking forward to seeing you in our next meetup.