Get my email lessons on how you can build a tech team you can depend on.

Send Me the Lessons

No Fighting In This (Agile) Dojo with M. David Green

By Programming Leadership

Episode 46

How can we train teams to consistently produce quality code without negatively impacting productivity? In this episode of Programming Leadership, Marcus and his guest, M. David Green, discuss Agile Dojos and how they can make teams more effective. Dojos provide a six-week training ground where teams focus on recognizing and replicating value by pairing, mobbing, and swarming. Coaches like Green help them to hone their skills and go through rituals more effectively. The results will be more engaged team members, scrum masters, and a way of working that converts skeptics and naysayers into Agile evangelists.

 

 


Show Notes

  • What is an Agile Dojo? (00:53)
  • Recognizing value (6:09)
  • What kind of work are engineers actually doing in a six-week dojo? (10:05)
  • How David’s dojos differ from others (18:30)
  • Understanding extreme programming (XP) and why it’s valuable (23:41)
  • Engaged scrum masters are essential for long-term change (26:49)
  • Convincing skeptics to try a new system (32:12)
  • Defining “mobbing” and “swarming” (35:00)
  • Why pairing doesn’t negatively impact productivity (38:47)

 

 

Links

 

Transcript

 

Announcer: Welcome to The Programming Leadership podcast, where we help great coders become skilled leaders, and build happy, high performing software teams.

 

Markus: Welcome to the episode. I am so pleased to have my new friend M. David Green join with me today and we are going to talk about Agile Dojos. How cool does that sound? David, welcome to the program.

 

David: Thank you, Marcus, it’s great to be here.

 

Markus: I was really looking forward to this episode because I recently watched the original Karate Kid and I was thinking about, Daniel-san, and the moves and the wax on, and I realize it’s silly, but I kind of like kung fu movies and stuff, but let’s be serious here for a minute. What is an Agile Dojo?

 

David: Well, you’ll excuse me if I don’t want to be serious, but will be sincere if that’s okay with you.

 

Markus: I think that’s wonderful. [laughing].

 

David: Sure. So, an Agile Dojo is an opportunity for a team that has an interest in developing their Agile skills to practice those skills under the supervision of a coach who can help them learn, and go through the rituals more effectively, and develop their skill around these things.

 

Markus: Can you give me an example. What kind of skills—if I go to a regular dojo, and one time I attended a karate class, even though it wasn’t a great experience—I remember there was lots of punching and kicking and sweating and some yelling and stuff like that. I’m guessing this is different. So, what kind of skills might one learn in an Agile Dojo?

 

David: You’re setting me up to tell you about all of the punching and kicking and screaming that happens in my dojos. [laughing]. But there isn’t really all that much. So, the concept of a dojo does come from the martial arts, it comes from Aikido. It’s the concept of a place for practice, the word “dojo” just means a place where you can practice. And in an Agile Dojo, typically a team comes together, either because there is a specific development skill that they want to practice, such as, for example, test-driven development, or perhaps they want to practice how they start and stop their programming sessions or how they pair program. There are a number of different engineering practices that you can work on in a dojo environment.

 

Markus: So, I’m thinking concretely because you mentioned some great examples. So, let’s take one of them, I think you said unit testing, is that right? Your test-driven development skills, if you want to get better, a company could create an Agile Dojo, and that might be a skill that people practice—a place of practice. Is it actually a different physical room? Is that a state of mind? What is the dojo?

 

David: People have had just a lot of discussions about whether or not a room is necessary. I found that a room is actually very useful, although when I started coaching I generally tended not to use a room and I tended to prefer to work with people in the workspace where they naturally work because the work that they’re doing inside the dojo then translates more easily back to the type of work that they normally do. But as I’ve started working with a set of practices, and in particular, I run a dojo around Extreme Programming, which combines together a number of Agile practices, I find that having a room where a team can isolate themselves from the distractions of the rest of the work floor, gives them the opportunity to focus in more on what they’re doing, without concern about being pulled away for other projects or about communicating with other people or closing themselves out from different distractions that might come from the floor. The factor of having a room isn’t necessarily something that all teams end up with, but I’ve noticed that at least a third of the teams that I’ve worked with, end up choosing, in the future, to find rooms, to reserve conference rooms or whatever, and in companies where they don’t normally have their own desk space in a private room so that the team can continue to work together in that isolation.

 

Markus: Okay, this sounds like—so I’m imagining a company who might be listening. Maybe you’re a software manager, and you say, “Man, I’ve been trying to get my developers to do TDD for years. And it’s so spotty, I’m not happy with it, they resisted. Maybe a dojo is right for me.” Is there some ways that a company, or a manager, or anybody can start to play or experiment with this idea?

 

David: Well, I think the first question I would ask a manager in that position is why do you want your engineers to do TDD? What is it that you really want to accomplish? Because that’s the beginning of the conversation that leads to the possibility of whether or not a dojo should be part of your plan. If you are just trying to implement TDD as part of what your organization does because you read somewhere in a board, or an expert told you, “If you’re not doing TDD, then you’re not doing it right,” they probably haven’t thought through the issues enough to really understand whether or not you want to try to bring people into a dojo and develop these practices. One of the reasons that I encourage people to go into a dojo is because it allows a team to recognize the value of what they’re delivering, not just change their practices. If you try to enforce TDD, for example, test-driven development, from the outside, it’s not going to stick. Most engineers know how to write tests, and if you tell them, write the test first, they know how to write the test first. Just because they can demonstrate to you the ability to write a test first doesn’t mean that that practice is going to become part of the culture of your company. The advantage of a dojo is it gives a team the opportunity to work with these practices for an extended period of time, often about six weeks. And once they’ve had a chance to experience, viscerally, the benefit of these practices, they’ll tend toward them when they’re appropriate, and often teams will tend to use them in preference for the way that they were working before.

 

Markus: So, what are some of those visceral experiences, these recognizing value, I think you said?

 

David: Yes, because basically you’ve gotten a team of engineers who might be thinking about how quickly they can deliver projects in order to evaluate how effective they are as engineers. And you might even have management looking at the engineers that way, as well. I’m of the opinion, and I think a lot of people in the industry would agree with me, that from an engineering perspective, the focus shouldn’t necessarily be on how quickly something is delivered, but rather how much quality is put into the process, how well the product is developed, how easy it is to maintain, how resilient it is, how robust it is, how easy the code is to read and understand. These are things that an engineer is qualified to work with and understand better than anybody else in the company. Whereas you might have people, say in the product organization, who might be better at focusing on the delivery speed and making sure that things meet customer expectations around deadlines and requirements. By delegating the responsibility for delivery off to product and letting the engineers focus on quality, you have the opportunity for the engineers to look at the work that they’re doing, not from the perspective of, if I don’t get this many things done by the end of the quarter, then I’m going to get a bad grade and a bad rating, but rather they look at, is everything that I’m doing of the highest quality? That is, is it maintainable? Is it not going to blow up in production? Is it going to work effectively? Is it understandable? And that’s really what an engineer is his best at.

 

Markus: You used a really interesting phrase there; the highest quality. And I have to say I think that most engineers really want to build high-quality products. I don’t know of any that would say, “My goal is to build low-quality products,” but sometimes the frames and the framing of quality can be different between management, product, and engineering. That is it can mean different things to different people. Do you have a useful definition that you encourage for the engineers around quality?

 

David: Well, you might have noticed that I was using a couple of metrics that you could include, to evaluate whether or not a software project—we’re talking software engineers—whether that project is being done with quality. And the maintainability of the code, the ability for the next engineer who looks at it six months later to read it and understand it, its robustness, the fact that it doesn’t fail easily in production, the fact that it has a lower number of bugs, or that it’s easier to restart when it does stop, or it’s easier to understand and fix when there’s something broken, the fact that it’s possible to toggle on and off features depending on the needs of a product organization. There are a number of different ways that engineers can look at their code and say, “This is higher quality and this is lower quality.” That said, as you said, the management might have different criteria for evaluating the value of the software that’s being delivered to the company, and product might have different metrics that they use for evaluating these things. When I talk about quality, I’m talking about the observable quality that an engineer would attribute to the code.

 

Markus: Okay. Do you find that most companies are having these conversations about different perspectives on quality?

 

David: I don’t think that most companies are as enlightened as you are about that point. [laughing].

 

Markus: Oh, I don’t know about that. [laughing]. [crosstalk 00:09:35]

 

David:  [crosstalk 00:09:35] I’m of the opinion that most companies would prefer to use a word that they think everybody understands and just let that word apply universally rather than dig into the semantics of this particular person looks at it from this lens and this particular person looks at it from that lens. That said, I think that most companies would be willing to have that conversation, I just don’t think it’s occurred to everybody.

 

Markus: Hmm. Well, let’s talk about how the dojo might help that. So, in your dojo, it sounds like—do you create some explicit ideas about what quality looks like in the dojo?

 

David: So, what I do in my dojo is I have a conversation with the engineers. I tend to work with engineers who are working in a Scrum model, which means that they tend to work in sprints, usually about a two-week sprint, that’s typical of most of the companies that I’ve worked with, and the way that I introduce the concept of quality and what an engineer might look at in terms of evaluating the work that they’re doing is by having a dialogue with the engineers in which I introduce a number of different facets of code and of coding practices. And I ask the engineers to evaluate themselves, and to look at the work that they’ve been doing and think about whether or not this is objectively the way that they think the work should be done, and to rank themselves and to rate themselves. We have this conversation at the very beginning of a dojo. We have this conversation after the retrospective, after each sprint. And then we have the conversation again after the dojo is completed, to see if the engineers have continued the practices after they’ve graduated.

 

Markus: What kind of differences do you notice in the way they, maybe, rank themselves or the way they see their own work?

 

David: Well, one of the interesting things about rankings is as soon as you put a number in front of something, people are going to try to game it. And engineers, just like anybody else, they tend to try to give themselves the highest score that they possibly can around everything. What I’ve noticed is that the teams that I’ve worked with that have the greatest maturity by the time they finish the dojo are the ones who look at the ratings that they gave themselves the highest score on before, and they rank themselves lower by the end, and they say, we actually learned something about what this means, and now we’ve realized that probably there’s more room for us to grow around this.

 

Markus: Oh, wow. Okay, so you mentioned that when you had started, or it sounded like early on in your work as an Agile Coach, the dojo wasn’t so much of a room as it was you were in with—where the engineers currently were working. But now we have sort of the idea of, they’re in a room working, this has worked well for you. What are they working on? Are they just working on katas? Which I guess is another martial arts term, right? Or forms? Or are they—like what is the work that they’re actually doing during this six-week intensive dojo time?

 

David: [laughing]. I can tell you from my dojos, I prefer to have the teams working on whatever projects they were working on when they started. Wherever they were in their projects and whatever they were working on. I don’t like to take them away from the type of work they’re familiar with, or even the languages that they’re working with. I’m not there to teach them things that they don’t already know. I’m there to give them the opportunity to practice skills in the context of what they already know. That said, the concept of an Agile Dojo is usually more broadly applied, and often, it will be focused around building a specific skill. A lot of people who run dojos will do an entire dojo specifically on pairing, and they’ll teach pairing practices, and they’ll work on the logistics of pairing, and the rhythm of pairing and getting people familiar with that. Some people run dojos around test-driven development, and it’s about how do you run a test? How do you get into a cycle where you make sure that you’ve written a test before you write any code, you make sure that the test has failed, you make the test pass in the simplest way possible, and then, once you’ve got the test passing in the simplest way possible, you go in and you refactor your code before you start writing your next test, and you do your development around that cycle. Getting people familiar just building muscle memory around that; that has value and that can be done with either katas or with the code that a team is normally working on. For me, I prefer to work with the code that a team has already got. Whatever projects the team is working on, I bring in the Scrum Master, I bring in the Product Owner, I make sure that everybody’s on board with it, and that way we are building these skills in the context of something they can take away with them, so that they can continue in that way once they’ve left the dojo.

 

Markus: Now you brought up these other two roles. I’m curious, do they have a role to play, the Product Owner and the Scrum Master? Are they a part of the dojo, or kind of just incidental?

 

David: So, I’m working in a Scrum and XP model, and Scrum and XP have some similarities, but most of the engineering teams that I’ve worked with would say that they are following Scrum. Scrum uses the concept of a development team of a couple pizzas worth of engineers, enough engineers that it would take to eat two pizzas for lunch, plus one Scrum Master and one Product Owner. The Scrum Master is responsible for keeping the ceremonies going effectively for Scrum, and the Product Owner is responsible for representing the customer and helping to defend the team from work that would take them away from work that would support that particular customer. In my dojos, I look at those roles, the developers, the Scrum Master and the Product Owner, as all of the elements of a team, and I’m coaching the whole team at once.

 

Markus: Okay, so I’m now—I stammering around because I’m—my mind is sort of swirling. I’m imagining a TDD dojo, or an XP dojo—I guess, with an XP dojo, it does make sense that the Scrum Mast—the other roles are in there, but when I think about a pairing dojo, would that involve other kinds of roles, like non-coding roles?

 

David: So, I don’t do targeted dojos around one specific practice the way that I’ve described. As I said, other people do have katas around TDD, and they might spend, for example, two hours a day for five days a week specifically focused on that, and that would be what they would call their dojo, or they might pull the engineers off completely, and work exclusively for several weeks on certain practices. I work on Extreme Programming, which would involve bringing all of those practices together, but working with the entire team on whatever work they’re normally doing.

 

Markus: Okay, got it. All right, so it sounds like that even the term dojo has a lot of flavors. How did you get into this kind of work?

 

David: So, I was a developer myself, and I was a senior front end engineer, working at companies—I was working from Apple Computer, I was working at a bunch of startups in SoMa, but I also have an MBA in Organizational Behavior. So, I had a different perspective on things. I came to engineering rather late in my career. And as an engineer, having had the experience of working before that in other roles, I saw that the engineers I was working with were really suffering. I saw a lot of pain in the process in terms of how communication happens, how requirements are explained, and set, established, how deadlines are met and how they’re handled, a lot of things that made me uncomfortable with how engineers were experiencing their work, and I wanted to help with that. And I recognized Agile—probably about 10 years ago in my career—as something that promised to help with that, if it were properly implemented. And I was working at a couple of companies that said they were following an Agile process, and that gave us classes that taught us what Agile was supposed to represent, then I didn’t actually see that in practice. I wanted the opportunity to help with that.

 

And I made a transition in my own career. Went from being a platform developer to being a Scrum Master. I rather quickly went from being a Scrum Master to being a Program Manager, organizing Scrum Masters around the company that I happen to working at at the time. And I fell in love with it. I saw so much benefit to the people that I was working with. They brightened up, the work improved, the quality of what they were delivering improved, the communication improved, and I thought this is really what I want to be doing. I want to be helping people get more of this in their lives. So, I recognized that, in the time that I was working, and the term for that was Agile Coach, and I started transforming myself into an Agile Coach, started working with small companies, working with independent clients. Right now, I’m working with enterprise clients. It’s been a really wonderful ride.

 

Markus: So, if somebody’s listening, and they are really intrigued about how they might use an Agile Dojo where they work to build skill, to build collaboration, it sounds like maybe if they’re XP or Scrum, maybe the whole team can be in there and have something to learn. How would you suggest someone start?

 

David: Well, there are a number of coaches out there who work in the dojo model. I’m actually part of a consortium, called the Dojo Consortium, as a matter of fact, which people can go visit and find out about some recommended practices. Companies such as Target and Verizon and Delta and Walmart, there are some really big companies out there which have adopted the dojo model for their engineers and had great successes with it. I recommend people go to dojoconsortium.org for a quick look at how these different dojos are approached.

 

Markus: Nice. Okay, well, I want to dive into a couple of specific questions about dojos. And I understand that you do dojos differently than some other people do.

 

David: Mm-hm.

 

Markus: So, I’m curious, when I went to a dojo or a place where people were learning a martial art, there were some rules, and they had the rules on the wall, and they said take off your shoes, and you have to treat people in a certain way. What kind of rules, or guides, whatever you want to call them, might you like to see in a dojo?

 

David: Well, one of the things I tell people when they’re entering the dojo is, there’s this concept also from Aikido called Shuhari, which is about a progression of learning and practice. And the concept is that there are three stages of learning in a dojo, the Shu stage, where you are simply adopting traditional forms and following those traditional forms as closely as possible to get familiar with them, the Ha stage, where you have incorporated those forms, and you’re starting to practice them and work with them yourself independent of a coach, and then the Ri stage, where you might be able to transcend those forms and move beyond them. The entire dojo is handled in the Shu phase of the Shuhari. So, I come up with a set of practices that I encourage people to follow, and among them, I like the team to establish what their core hours are when they’re going to be available to work with each other. That’s important because I like the team to pair and mob on all of the work that they do, rather than work independently. No silos, no individuals working on a piece of code. If one person is working on something, everybody on the team should be aware of what it is and should ideally be able to step in and help with it. I like the team to be doing test-driven development around all of the code that they’re building so that they know how to do that test first process. I like them to use acceptance test-driven development, where the Product Owner can define the behavior of the end product, of the software as it’s supposed to be delivered, and then based on those definitions, the team can write acceptance tests, which also can fail and then be made to pass through the process of development.

 

I have the team sitting together in a room. That’s usually unusual for them. That’s not something that they’re familiar with, and often I find the first thing people say is “Why do we have to be locked in this room all day?” But by the time the dojo is over, I’ve yet to find a team that didn’t want to adopt the room and stay in there forever. And I sit with them. I sit with the developers for the whole time that they’re doing their development work, and I coach them as they go, and I try to be rather lightweight about it. But I’ll remind them if they start working on code without having first written a test, “Did you write a test for that first?” Just like asking the question, and not necessarily forcing them to do anything that they wouldn’t do, but if they recognize that there’s value to what I’m suggesting, they’ll pick it up and they’ll start doing it.

 

Markus: That’s a nice, gentle nudge towards what you’re looking for. So, I’m curious, have you found anyone who is using Agile, these Agile Dojos in a fully distributed team?

 

David: So, before I started doing dojos, myself, I actually was coaching teams that were fully distributed at one company. I worked at a company, it was a small startup, and they had no physical location at all. Everybody was spread all around the world. And for example, there was one team that had people from Portland to Pakistan. And—

 

Markus: Wow.

 

David: —it was challenging, for example, getting them to work around the concept of having a daily standup because getting a schedule that works for everybody was interesting. But finding a time when the teams could work together effectively was one of the big challenges there. We ended up encouraging a lot of pairing between the people who were in shared time zones. But remote pairing is definitely not a problem, as long as people are able to align their time effectively. I like working with distributed teams a lot because working in a distributed environment forces you to have the kind of transparency and documentation that keeps everybody on the same page at the same time.

 

Markus: Hmm. I like that answer. David, we’ve been using some terms like Extreme Programming, also known as XP or Scrum. And I know that for myself, I’ve been assuming that audience members just know what that means, as well as Agile, but you seem to have a particular affinity for this thing called Extreme Programming, which sounds pretty extreme. What is it? And why, in your mind, is it valuable?

 

David: Absolutely. Extreme Programming is something I’ve seen work for so many different teams. And one of the things that I noticed when I started getting into Agile, I was going into it because I was looking for ways to reduce the suffering and increase the joy that I saw in the teams. The teams that seemed to have the most joy were the ones that were following an Extreme Programming practice. And when I first heard of it, I wasn’t exactly sure what it was, and I had a lot of fantasies about what it might be, but it’s a fairly simple concept. With Extreme Programming. There’s a set of fundamental practices, and I’ve mentioned a few of them along the way. Teams that are doing Extreme Programming pair or mob on all of the work that they’re doing. They do test-driven development for all of the coding that they’re doing. They use acceptance test-driven development to make sure that the stories that they’re working on from the Product Owner deliver real value and are framed around real customer needs. And another factor of Extreme Programming that I think Extreme Programming inherits from Agile is this concept of reflection, where you work in short iterations, and get the opportunity after each short iteration, to look at what you’ve done, and look at the way you’ve done it, and reflect on your process, and then improve the way that you might do things the next time.

 

Markus: So, this reflection thing. I’m keen on it because I’ve been thinking lately about how to build learning teams. Is reflection the same as just a retro? Everybody talks about doing a retro, but I don’t know if XP reflection is just their version of a retrospective.

 

David: I believe that it is, and that’s the way that I approach it. And in fact, because the teams that I work with tend to use a Scrum model as opposed to an Extreme Programming model when they start I tend to build the Extreme Programming practices inside of Scrum. I’m not a purist around this. So, if the team already has a set of ceremonies that they follow, and they have a person they call a Scrum Master and the person they call a Product Owner, that’s fine with me. That’s different from what Extreme Programming would require, which is a person called an XP Coach, and another person called a Customer with slightly different names for some of the ceremonies. For me, I don’t see that the differences are all that important. So, yes, the retrospective, from a Scrum perspective, with the important caveat that a lot of teams may not be doing their retrospectives or maybe passing them off too quickly, or may not be taking action items out of them. And I like to make sure that the teams I work with recognize the value of that reflection so that they can benefit and improve.

 

Markus: I’m starting to get kind of a picture here. You don’t have them do katas or forms. These people come into the place; they say we’re going to spend six weeks together. We’re going to be in a different kind of container where we’re kind of locked away. And we’re going to work together. But we’re going to work on what we were already working on. So, the product and the codebase and the tooling is very familiar, but now we’re also going to try and be more intentional about how we write, and who we write with, and how we know it’s correct, but also how we build in learning. And I think that last bit kind of lights me up because I do talk to so many companies and developers that tell me, “Oh, yeah, we have retros. Nothing really ever changes.” But in the dojo, how do you spur that on so that you create some change?

 

David: So, the dojo works best when there is an engaged Scrum Master, and this is really one of the places where a strong Scrum Master has the opportunity to shine. When I start a dojo with a team, sometimes a Scrum Master might think, “Are you criticizing the way that I’ve been doing things? Do you think that I haven’t been doing things right?” In fact, the Scrum Master is essential element to an effective dojo, and I consider the Scrum Master to be the coach that the team gets to keep when they graduate from the dojo. So, I empower that Scrum Master, and I offer techniques and tools and tips and opportunities. Usually, it’s a very collaborative process, and by bringing the Scrum Master into the process and making sure that the Scrum Master’s vote is part of every vote, and their ranking is a part of every ranking, it cements that person as part of the team and not just somebody off to the side who forces us to do ceremonies every now and then, whom we can otherwise ignore.

 

Markus: Yeah, I think I could imagine that the Scrum Master might feel like, “Well, this is happening because I wasn’t doing my job right.” Or, David’s here, “It must mean something’s wrong because we’ve been sent to the dojo.” I don’t know if people get sent to the dojo or if they sign up for it, but at some point they’re there. And I’m curious how other roles might react to being in this environment?

 

David: Well, it’s a funny thing, because the very first team that went through the dojo in my current engagements was very enthusiastic about going through, and that set the tone for the rest of the company honestly. Right now, I’ve got a waiting list of teams that are waiting to go through. They’re enthusiastic and anxious about the opportunity. And it’s not because they think that they’re going to be evaluated. It’s because they see that the teams that have gone through it before have gotten so much benefit out of it. There’s a lot of evangelism that comes from this process. And the developers evangelize it among the developers. The Scrum masters evangelize it among the Scrum Masters and the Product Owners evangelize it as well. The manager is evangelizing it because they’re seeing the benefit to the teams and their ability to work and deliver high-quality code.

 

Markus: So, individuals, it sounds like, come out after six weeks, changed. How do team dynamics change? Or maybe, how have you seen them change in that six weeks?

 

David: Yeah, it’s funny, because I don’t think so much about the individuals changing. I do coach the individuals as I see people who might have specific problems, but my focus is always on the team dynamics. It’s always about how the team works together as a whole. That’s one of the reasons why pairing and mobbing is so elemental what I’m doing. If everybody on the team isn’t fully engaged in the process all the time, then the team isn’t really working together effectively. That’s one of the reasons why I encourage teams to establish core hours that are maybe four or five hours a day at most, because it’s very intensive work when you’re pairing and mobbing with people, and you have to be engaged constantly in what’s going on. You need some downtime. You need time to answer your emails. You need time to take training courses, you need time to do personal development, but you also just cannot work that many hours a day doing that kind of thing.

 

Markus: I remember, I think it was about 2004, I picked up this wonderful little white book called Extreme Programming Explained, maybe or something like that it was Mr. Kent Beck—

 

David: By Ken Beck, yes.

 

Markus: Yeah, Mr. Kent Beck. And I remember getting so excited. So, excited. I read it on a business trip on a plane, I thought it was going to be the miracle that saved the company I was at—not saved it, but like—I love the—I want to go back to something you said. It might bring more joy because there was a lot of suffering, so much suffering. And I went to the developers, and I said, “Hey, what if you guys pair programmed everything together? Like, this book says it’s going to be great.” And they went, “No way.” And then I said, “Okay, well,” I went to my manager, and I said, “What if people pair programmed? It’s gonna be great.” And he said, “No way.” So, I found resistance on all sides. And, frankly, I just kept being told, “This is a really dumb idea.” And I’m curious because, David, clearly you are a better evangelist than I was, I could get no traction with these fine people who were suffering. But, how do you start to convince both the upper management—or any management who looks at people as, like, “Won’t that half our productivity if they’re working in pairs?” And the developers who say, “No, this is individual, I need to work with my headphones on.” How do you start to change both of those mindsets?

 

David: They’re very different discussions, honestly, but they do both come down to the same concept, which is this concept of quality that I mentioned early on. Once management has their head around the fact that engineers are not code monkeys trying to churn out code as fast as possible, which results in a lot of technical debt and a lot of failures down the road, and once engineers understand that their focus is on the art and the craft of what they’re doing—and they want to create something beautiful, and something that works, and something that’s understandable, and something that can be proud of—you can convince people to try something different because what they’ve been doing in the past has always resulted in the same bad experiences and the suffering—

 

Markus: The suffering, yeah. [laughing].

 

David: —the unpleasantness. [laughing]. If you give them the opportunity to try something new and say this is going to be just for a few weeks, we’re going to try this. Give it a try, see what you think of it. And then let them evangelize it themselves, if they liked what they got.

 

Markus: Do most of the teams that come out of the dojo continue with the pairing practice?

 

David: Most of them continue with it partially. Very few continue with it fully. And some teams adopt one or the other, either pairing or mobbing and they stick with that. I’ve had more teams actually stick with mobbing consistently than with pairing, which was a surprise to me because one of the first things that happens when the team does the dojo is they say, “Okay, we had five engineers, that meant we could work on five stories at once, so we got a lot of work done. Now you’re telling me that, first of all, we’re going to pair, which means we can only work on two stories at a time because we have two people in one pair and maybe three people in the other hour. Or maybe we’re only going to work on one story at a time because we’re going to mob all the time. How are we going to get all of our work done?” Once they get the experience of noticing, oh, with everybody’s brain engaged at the same time, and with the ability to rely on this person who was otherwise working on this thing that nobody knew about, and to bring that person’s brainpower into the process, and get everybody engaged, we’re getting such better quality that we’re producing. We’re improving the quality of the work that we’re doing, so we can work faster and we can work more effectively together and more efficiently. They start to notice the benefit of this and, as I say, I’ve had more teams stick with mobbing even though it has a lower work in progress limit, because they just find it so gratifying to work together that way.

 

Markus: Do a quick definition for me. What is mobbing? I hear mobbing and swarming as things that get talked about, so, tell us what mobbing is.

 

David: Sure. So, you’ve got the basic concept of pairing to start with, pairing being two engineers working together with one screen and one keyboard, and they’re both looking at the same code. One person is driving, that is the person that the keyboard, the other person is navigating, instructing that person on what to do, keeping track of things while the first person is typing.

 

Markus: Two people, one computer. This is fundamental. Not two computers side by side. One machine to humans.

 

David: One machine. Yeah, my teams will tease me because one of the things that I encourage them to do is to shut their laptops if they’re not the one who’s actually driving. And I will play games with that, but it’s important because if you’ve got somebody sitting across the table from you, even if that laptop is off, you don’t know that that laptop’s off. It looks like it’s open; it looks like it’s a distraction.

 

Markus: Okay.

 

David: And as soon as that laptop opens up, you’re going to be checking your email, you’re going to be getting instant messages, all sorts of things are going to come up. Very distracting. But yes, fundamentally, two people one computer. A driver on the computer, navigator looking at the screen and giving feedback on the process. Mobbing expands that so that you have one person on the keyboard, and then, perhaps, the entire team all looking at the screen at the same time, giving feedback, giving context. If there’s something that somebody doesn’t know, or that anybody doesn’t know, they can look it up on Google, right there on the shared screen together. It’s not like somebody has to open up their laptop, and look it up separately, and then report back. If there’s a resource or a piece of information that people cannot get on that one shared screen, that’s a liability to the team because if that person who had to look that up weren’t there, there’d be no other way to find that information. If it’s stuck in notes that that person wrote to herself on her own machine somewhere, and that person won the lottery and left the company, there’d be no way to get that information otherwise, and so that’s why would you encourage everybody to be looking at one screen together. So, the mobbing concept basically takes pairing and expands it out to the entire team. And you mentioned another term: swarming. I use the term swarming to mean what you might see when you have a roomful of engineers, all with their laptops, open all working on something independent, but working together on the same concept. Sometimes that’s useful in a programming environment. Sometimes, we want everybody to go off and research something for 15 minutes and then come back with a result. The key thing in that is that 15 minutes, so it doesn’t become the entire day. It just becomes, we have a specific objective and we’re going to swarm for the next 15 minutes in order to find this information. Everybody, open up your laptops. Everybody, go look out, look around, do research things. What you’ll find is people are often looking in the same place, they’re often looking at the same thing, they don’t know the person next to them is redundantly looking at the exact same thing, probably could have saved time by everybody looking together at the same screen, but they prefer to do it that way. It can be effective, as long as there’s a time box, it’s okay. So, swarming as something that the team can drop into occasionally, mobbing as a general practice, and pairing is the default. Ideally, a team should pair by default, which gives them the maximum benefit because they have the greatest number of stories in progress with two people working together at a time, but they have the benefit of having that shared information where it isn’t just in one person’s head.

 

Markus: How much—okay, I know what you’re going to say, I feel, but I’m going to ask it anyway because I’m imagining I’m a listener, and it was me so many years ago, and I heard about this and I might ask, “Well doesn’t productivity drop a whole lot? Statistically, can’t we measure that two people are just faster on two stories? And isn’t that the fundamental parallel processing idea? How does pairing effect, quote-unquote, “productivity?”

 

David: So, these practices actually do not impact productivity negatively. Because while you do have fewer channels of development happening simultaneously, each channel of development is much more robust and produces much higher quality code, so, there is less back-work, there’s less failure in the codebase. It’s easier to understand the code because it’s been written in such a way that more than one person can look at it and understand it. It’s been written to meet coding standards that the team has established mutually because they have to work together, so everybody has to be able to look at the code simultaneously. As a result, what’s actually produced and pushed out into production is much more stable and much stronger. So, the fact that there aren’t as many channels of development at the same time results in an equal amount of productivity, but with higher quality.

 

Markus: Okay, so we’re not going to see half the number of features, or stories, or whatever we’re counting, in theory. But, now when we think about—

 

David: But we might, honestly—

 

Markus: Oh?

 

David: —because if what we’ve been looking for is the concept of, let’s push the code out into production as quickly as possible, no matter how bad it is, and then work on the next feature, and then work on the next feature, and never fix the features that we’ve been putting out there, and building up technical debt at a rate like that? Yeah, we might see fewer features that are built like that going out into production.

 

Markus: I feel like you did a thing there where you redefined productivity. [laughing]. Well, let’s talk about mobbing then. I have questions, so many questions. So, the first one is, is there an effective limit of how many people can mob together?

 

David: So, I do like the concept of the two-pizza team: as many people as could eat two pizzas at a given lunch. I like a team that has ideally an even number of engineers, maybe between five and nine somewhere in there. But that seems to be about the sweet spot. Eight and nine is getting a little bit high for that, where the team might feel that it’s hard for everybody to stay fully engaged. The team might break into two mobs at that point.

 

Markus: I was actually gonna ask. I’m imagining six people swarming around—mobbing, let me get the words right—mobbing around one machine. And I’m imagining that it might be awfully tempting or I’m trying to think about how to say this, but just the idea that not everybody may be engaged. People are looking at their phone, they’re feeling like, “Well, I’m not in front of the keyboard, or it’s hard to see the screen so I’m not really a part of this.” Does that happen, and is mobbing a skill that one must learn over time?

 

David: It is a skill. But it’s not one that takes a long time to learn. It does take a team’s engagement, though. It forces the team to stay more fully engaged and to have permission to keep other people engaged in the process. There’s a concept that sometimes comes up early on when I’m working with a team, where somebody will turn into what I would call a Tesla, which is a self-driving driver, sitting there at the keyboard, not actually waiting for anybody to navigate and give feedback about the work that’s going on, but rather, sitting there at the keyboard and also coming up with what’s going to be coded and doing the coding at the same time. Basically, somebody’s working alone, but on a big screen in front of a team full of people who are just watching. That is a practice that I try to discourage, and I do that by actively encouraging people to speak anytime that I hear silence in the dojo. I want there to be a constant chatter, a constant discussion, and I like to make sure that every voice has the opportunity to be heard. Getting that practice over the course of a six-week dojo, I hope, encourages the team to carry that forward after the dojo completes, and it’s up to each team to figure out how they’re going to establish their norms so that people don’t feel left out.

 

Markus: That’s really cool. Is there a particular time when you encourage teams to move from pairing to mobbing? A particular type of problem, or is it just like, “Oh, it’s Thursday so we’ll mob.”

 

David: I like the teams to have experience with both modalities so that they can choose based on the specific type of project that they’re working on, whether or not this is something we’d like to pair on or something we’d like to mob on, and generally, teams will choose to mob on things that everybody on the team wants to learn about, and that everybody wants to be fully engaged in the process. They don’t want anybody else to feel left behind, so they’ll want everybody to be mobbing on that. And as I say, there are teams that choose to mob 100 percent of the time, which is just fine. It’s completely up to the team based on the way that they work.

 

Markus: Does management have a view, when they come out of the dojo, and they’re now five, six, eight people in front of one screen? Do they have a perception of or a feeling about this huddle and productivity or other things?

 

David: Management tends to be very supportive of this because it increases happiness on the teams, it increases engagement, it reduces the other problems that can come up for management, and it brings these things to the surface, so they have the opportunity to be discussed right away.

 

Markus: So, this has been just fantastic for me, I’ve learned a ton. So, a quick recap. So, if you’re listening and you’re interested in the concept of a dojo, David, remind us of the URL people go to to find out about the group that does and runs these dojos.

 

David: Yes, I’m part of a consortium called, and their URL is dojoconsortium.org.

 

Markus: Great, okay, so there is probably you can find more information, you could get in touch with these Agile Coaches that do this brilliant kind of work. And if you’re not playing—maybe this is my last question, David, if people aren’t yet playing with XP concepts, especially with how multiples of humans write software together, is there some resources you’d like to recommend for considering how pairing or mobbing might fit into the organization?

 

David: Well, you mentioned Kent Beck’s book. And there’s a series of books that he’s involved with that can all help with that. But, when we’re at direct people right away, if they just want an overview, and they want to start applying these things right away, I direct them to extremeprogramming.org, which is a website. It’s been around for years, and it encapsulates some of the basic concepts. It’s an opportunity to learn about how Extreme Programming was conceptualized, how it works, and it’s got the fundamentals there. You can really get started with just that.

 

Markus: Cool. David, where can people find you online, engage with you, and with your work?

 

David: Sure. Well, I’m M. David Green pretty much everywhere, so all of the social media. I have a podcast called Hack the Process, which you can also look at. I talk to people about various techniques that they can use to improve their productivity and to move mindfully past having an idea in your head to having something out there in the world that you’re proud of. And if you’re interested in my book on Scrum, I just wrote a book on Scrum called Scrum: Novice to Ninja, which you can also find out there.

 

Markus: Wonderful. Thank you so much for being on the show.

 

David: Thank you for having me. [laughing].

 

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.

You may also like...

About Programming Leadership

Pin It on Pinterest

Share This