Podcast Ep. 45: The Benefits of Mob Programming with Chris Lucian

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by Chris Lucian, the director of software development at Hunter Industries and co-founder of the mob programming movement. Chris is passionate about the advancement of software craftsmanship and machine learning. He seeks the continuous improvement of himself, his family, his company and his community. He believes that we can explore the unexplored potential in all things when looking at our processes with automation and creativity in mind.

Tune in for Chris and Dan’s discussion on mob programming. Chris shares the origin story behind mob programming, what it is, how it is utilized and dispels some of the general misconceptions around it. He also highlights many of the key benefits of mob programming and explains some of the best practices.

Listen on Google Play Music


Key Takeaways:

  • Key takeaways from the origin story behind mob programming:
    • After getting hired into an organization, he was shocked by how everybody was working separately in cubicles and soon developed mob programming
    • After implementing mob programming, their quality went through the roof, their cycle time went from a year and a half to twice a day and they stopped getting bug reports from production
  • What is mob programming?
    • A software development approach where the whole team works on the same thing, at the same time, in the same space and at the same computer
    • This approach relies on face-to-face and side-by-side communication, team alignment, collaboration and whole team involvement
  • What are coding katas?
    • The intentional practice of your coding craft
    • Practicing together by writing code through games such as the Tic-Tac-Toe Game and the Bowling Game (linked below)
    • Helps to build a habit or reflex out of coding
  • Misconceptions around mob programming:
    • When multiple people are working on a single piece of workflow, it will cost more for the company
    • It is a waste of time to implement for the “simple stuff”
  • The benefits of mob programming:
    • Paired programming helps mitigate risk from siloing and provides an increase in quality
    • High-bandwidth learning
    • The code moves all the time
    • Really optimized for flow efficiency with less time being spent on waste activities like bug fixes
    • Removing impediments becomes really fast
    • A higher consciousness of experiments on the team to run about how to make things better and faster
    • Mobbing on the simple stuff incentivizes programmers to make all that simple stuff go away permanently
    • Physical cost-wise, four cubicles costs more than a single mobbing station with a high-end computer and two 80″ screens
    • Standup meetings become eliminated because the team is already aligned
    • Group consciousness is constantly being developed
    • Psychological safety and feedback becomes necessary through mob programming (which are critical components to a successful team)
    • The codebase keeps moving forward and nothing gets in its way
  • Mob programming best practices:
    • Dedicated learning time
    • Do frequent retrospectives
    • Don’t just “try” something; frame it as an experiment (regardless of the outcome, it provides invaluable learning)



Mentioned in this Episode


Chris Lucian’s Book Pick:


Intro: [00:01] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host coach and agile expert, Dan Neumann.

Dan Neumann: [00:16]  Welcome to this episode of the Agile Coaches’ Corner. I’m your host Dan Neumann. And today I’m excited to be joined by Chris Lucian, who is the director of software development at Hunter Industries and a cofounder of the mob programming tactic or initiative movements. I don’t, yeah, thanks for joining Chris.

Chris Lucian: [00:36] Thanks for having me. And uh, appreciate being here. Um, yeah, the, the, mob programming thing, uh, has, has been a lot of fun and uh, we still do it and so it’s a really great, so happy to be here, uh, spreading the word, I guess. Yeah.

Dan Neumann: [00:52]  Awesome. Yeah, I did a, uh, recording with Arie van Bennekum a while back who was one of the signatories on the Agile Manifesto. And one of the things I liked about that was hearing his perspective on how things got started there. Like I had some misconception about it and I thought I understood it pretty well and he went on to explain about the lightweight methods conference they were all at and how this thing came out. And so speaking with people who were there when the things got started really I think adds a lot of insights. So let’s start with, let’s start from the beginning then. This, this mob programming. What you, what is the origin story for you guys?

Chris Lucian: [01:25] Um, yeah, so, uh, I think a lot of things happened in a serendipitous way I guess. Um, so, uh, I was, I was actually just, just before I started where I am now, um, I was working in military contracting, environmental chemistry sort of stuff. And, uh, and in that, um, I had been going to a lot of local user groups and I had seen, uh, Woody Zuill speak. And so he said that there were positions open. And so, uh, I, I liked what he had to say about refactoring and about, you know, managing waste and things along those lines. And so I was like, oh, it’d be pretty cool to go work with them. And so, uh, I ended up working there and, um, this was kind of like three months after he started. Um, and then, uh, I got there and I was kinda shocked, like everybody was kind of in cubicles and I was expecting pair programming, extreme programming, that sort of stuff. Um, and so it just, it happens. So happened that he was just hired as well. And so he just implemented Kanban and then a couple of other things, but everybody’s kind of on their own projects. Um, you know, stuff like cycle time would be, you know, a year long year and a half long to get something out, that sort of thing. And, um, so I took on some projects and so three months go by and then, uh, one of the developers there, actually the senior most developer on the team. Um, the basically said, uh, you know, I’m not going to meet this, uh, financial related deadline. And so can we all get into a conference room and do what we’ve been doing in our learning sessions. And so, um, one thing that, Woody had put in place while we were there, was hour, day learning time for the team. And what we’ve been doing was code katas, so basically we started tic-tac-toe over and over again and we were working on writing a unit test for the first time and things along those lines. And this is all very new to the team. Um, and uh, and so what ended up happening from there is we all got into a conference room and we basically said, we’re going to do a strong navigator driver style, but we’re going to just rotate at the keyboard and we’re going to work on this code base. And we did that for a day and we, we did frequent retrospectives at the time and we just said, you know, hey, is this working well or not and what’s good about this, what’s bad and things along those lines. And we just said, let’s keep going. And so, uh, we did this every day and did a retrospective every day. And so this year and a half, two year long project ended up, uh, getting done in less than three months. And we even decided to start over. We started from scratch in that, in that period of time. So this one developer was working by themselves and, uh, and we were able to deliver on time with no bugs reported back and, uh, and it immediately started to get used. And so that led to further retrospecting. And, um, and at that time we were just reserving conference room after conference room going in two hour chunks and doing all of our development in different places. And, uh, and we just realized it really worked for us. And so shortly after our, a IS director, um, ended up saying, hey, we could put together a station to do this for you all the time. And so they actually painted the wall with projector paint and we put down projectors and things along those lines. And so, um, basically we started rotating at the keyword all the time. We, we had a dedicated place to do this. And, um, every piece of code that went into the code base was looked at by four people and our quality went through the roof. And so, um, our cycle time, you know, over the next year went down, you know, went from a year and a half to twice a day. Um, and in that same period of time we stopped getting bug reports from production and we merged our QA team into our development team. And, um, over the next three-ish years, we basically kept doing more of that. And, uh, we had a year and a half long period without a single bug report from production releasing twice a day. And, um, and then we, the company, uh, had an external consultant evaluate, uh, development practices across the company and basically said that the company should grow this for their product development. And that’s when we started scaling. And then, um, in the last four years. So we started about eight years ago and so it’s been four years of just one team and then now another four years. Uh, we just crossed that, um, and uh, recently to, to be another four years of mob programming at scale, I guess. So eight mobs kind of working all the time on different product level stuff as well as stuff that we were kind of doing in the early days.

Dan Neumann: [06:00]  That’s cool. I’m a little self-aware being a consultant. It’s kind of funny like, Hey, yeah, that team that’s releasing twice a day with no defects. Yeah, you should do more of that. Yeah. Can we have some money now? It’s interesting. So was there some skepticism or some reservation about radiating this through or was it kind of a bit of a well kept secret that you guys were kinda hitting out of the park from cycle time and quality and I’m just kind of curious.

Chris Lucian: [06:29] Yeah, so like the metrics of like cycle time and quality and things along those lines. Those are less known metrics and I think that, um, what the team had was kind of like a year long period to kind of do something different than they were because the team was essentially stalled and in most cases and um, and so they wanted to transition to agile but didn’t know really what that looked like. And so the incorporation of Kanban and um, and test driven development had kind of started the, the forward movement and it was just massively accelerated by this. Um, so my programming is a really great way to teach other people on the team how to do something different. Um, you, you aligned context very quickly. You do a lot of, uh, there are a lot of, you know, financial benefits to mobbing that that eventually came out. Um, and so the team was protected for a little while and then after the team had to start explaining why things were so effective, it became really obvious, um, that this was the financially responsible way to go. And even today, um, we have a rule, basically we take this from the open space conferences, the law of personal mobility. And so if you, if you’re not contributing and you’re not learning, then go to a different mob. And, and, um, you know, the department requirement is two pairs of eyes on code that goes into production. And so that might mean code reviews or pairs. But, um, you know, 99% of the time we’re in mobs doing work because that’s what the team believes is to be most effective just based off of the evidence provided in our history. Right.

Dan Neumann: [08:00]  No, that makes sense. I wanted to, um, you, you mentioned coding Katas and I’m familiar with that. Have some little experience with doing them and um, for folks who aren’t, the way I think of that anyway is very intentional practice of your programming craft. So you’d mentioned there’s a, in your case, I think you said the tic Tac toe game and so people are writing code together like, okay, we’re going to write a test that fails, we’re going write some code that passes and, and now we’re going to refactor as needed to get tic Tac toe playing. Is that, are we using that term the same way for folks who maybe aren’t familiar?

Chris Lucian: [08:35] Yeah, so in a, in a code Kata, um, with a strong pairing style, uh, the, the main thing is is that you might have a three minute rotation. Somebody is at the keyboard and all code must be verbalized. And so that’s just a pair programming practice that then kind of we started doing with multiple people that then kind of a maybe facilitated the birth of mob programming, so to speak. Um, and so, uh, in that, um, I’d say that, you know, basically we start, we start over from the beginning every day, so we don’t, um, it’s very like the Mr. Miyagi wax on, wax off. So we start with an empty project and then we write a test and then we start developing it out and we go as far as we can in an hour and then we throw it away. And it’s really irritating for people to have to throw that code away. But the intentional practice part of it is actually just starting new. Right. And so what you really want to come out of that exercise that we were doing for tic-tac-toe was the, the, um, the reflex to go to a unit test before writing code. That’s very hard to develop. And so the code kata, really was a great way of making that, uh, be facilitated and happen faster.

Dan Neumann: [09:46]  Yeah. I’ve, I’ve often referred to it as a habit, but I like your term of reflex on there because it’s like when when push comes to shove, people go to the thing that they’re most comfortable doing and if that’s just slinging code into the repository and hoping it builds, like that’s kind of how you end up with a mess. So getting that, like you said, the reflex, somebody taps you on the knee, your foot kicks. Um, right. The test make it pass, I love that. So what do people do under pressure? Right? Absolutely. Absolutely. And so, uh, one of the things you have a youtube show, a vidcast called mob mentality show that if people go to youtube and, and Google that they’ll find it as well as your ChrisLucian.com blogging. Do you have anything on that that goes deeper into katas on either of those platforms? If people are curious whether there’s a list of practices or a little how to, or I’m just, I’m just curious.

Chris Lucian: [10:35] All right. I think the best thing to do there is just to say to go on Twitter and talk to us and say, what are the best Katas to do? We literally did tic-tac-toe over and over again. Um, and uh, some really great resources out there are like Llewellyn Falco, bowling Kata, uh, examples on youtube. Um, and a couple of other things. I have a couple for some complex mocking that happened on Youtube as well. Uh, in the, um, basically the slice and Peel videos for, uh, dot net MVC. Um, other things along those lines. But, but if you, if you ping a ping us on Twitter, then, um, we have just a ton of resources. There’s actually a Trello board that we maintain publicly as well. Um, and uh, we can share the link with that. And, um, it’s a Trello board of resources, uh, for basically programming professional career practices, um, that people can, can look at and get better at over time. And we maintain that on a regular basis. And so if, uh, basically if anybody starts sending me a lot of really great links that I agree with, um, then I make them a contributor to that board. And so there’s like eight or nine people, uh, grooming that, that board right now that have a lot of great resources around this stuff.

Dan Neumann: [11:48]  That’s super cool. So we’ll put links to that in agilethought.com/podcast with the show notes. And your Twitter handle is escaping me right now.

Chris Lucian: [11:57] Oh, a @ChristophLucian is my Twitter handle. So yeah, almost like Christopher and you’ll get it.

Dan Neumann: [12:04]  Okay. Cause I went, I went looking for Chris Lucian and I remember I got a guy and I was like, that’s not him.

Chris Lucian: [12:15] Yeah, good to know. Thank you for that.

Dan Neumann: [12:17]  Yeah. Okay, so Christoph Lucian, good help people find you there for sure. Um, so let’s follow the money for a second. One of the things I see typically senior folks kind of really get twitchy about when we start talking about pair programming. It’s like, wait, wait, wait. Two people on one computer, like why, why wouldn’t they both be coding separately because it’s going to cost twice as much. And those types of reactions when we start talking about multiple people working on kind of a, a single-piece workflow. So can you maybe help allay some of the fears or talk about the hidden costs of not doing pairing and not doing mobbing?

Chris Lucian: [12:55] Yeah. Yeah. Um, so I, I think, you know, one of the obvious ones that I think get people past the pairing argument really upfront is the, the siloing idea, right? So like, okay, you have this rock star developer and they’re, they’re turning out a ton of code and then you have some, you know, junior, mid-level people join the team and then all of a sudden it’s like, um, that, that rock star moves on or, or ends up, uh, retiring or something like that. And then everything all of a sudden slams to a halt because it’s like actually people on the team didn’t really know what was happening or going forward or something along those lines. Right? So pairing then becomes kind of like a, maybe a logical extrapolation of just mitigating risks from, from siloing as well as, uh, an increase in quality. Um, but what ends up happening, it’s like, you know, what people I think don’t tend to do, um, is they don’t really focus on the good. They kind of like always focus on the bad. And so if you focused on the good of pairing, great, like the natural extrapolation, it’d be like if pairing is better than working solo for code quality for, um, you know, uh, removing impediments for doing all of these things, then why not try with more people? Right? And so you get to three or four people and you get a lot of great things that happen. Um, some of them are among high bandwidth learning. Um, the code moves all the time. Uh, we had somebody visit us and, uh, and we were explaining a little bit about like, Oh yeah, well, you know, they basically say, what happens when the mob gets blocked? And it’s like, well, we don’t really ever see the mob get blocked. We don’t, we don’t, we’re, we’re really optimized for flow efficiency, not, not necessarily resource efficiency. So, so something gets into production every day and nothing really gets in its way because, um, people may be writing code and they might have to go talk to a product owner. Now somebody can, that knows about the code, can get up and go walk it to talk to the product owner while things are getting done, and remove the next impediment. And so removing impediments becomes really fast and, and in that, the code moves forward. Um, there’s also a higher, uh, consciousness of experiments on the team to run about how to make things better and faster. And so, um, you know, when we started mobbing the first time, there was a developer that, uh, basically would, would say, oh, I need to, I need to go and look at something for production. You know, and they’d do this throughout the day for a significant amount of time and you could tell that they were getting a little bit stressed. And so we said, well, okay, if you’re going to do that, like why don’t we do it as the mob and we’ll just do it together? And they say, oh no, it’s really simple. We shouldn’t be doing that altogether. And so what’s really funny is like, um, over the years I’ve grown to understand like if somebody says, hey, this is going to be really simple and so we shouldn’t mob it, um, that’s usually the time where you say, okay, well can we automate it then? And people don’t think that they say, okay, you know, it’s really easy to estimate this. And so I’m always going to put it into my schedule and, and so, um, and we estimate, well what we’ve done many times before. And so, um, so typically people are incentivized to, to basically put something that they know how to do in over and over again to balance out their timeline. Right. And, um, and so we eliminated all of that stuff very quickly and in the sense that this person, we recovered 80% of this person’s time every day, they spend about 80% of their time running pre productions, uh, scripts against production. And then, um, later on, uh, we’d find out that we, we kind of found out like, hey, we can just recover all of their time, uh, when we started mobbing on it. And so mobbing on the simple stuff actually incentivizes you to make all that simple stuff go away permanently. And I think that it’s a big risk to have one person working by themselves or even a pair where they can just say, oh, well, we’ll just get past this one right now and continue rolling forward on it. Um, other things, uh, just quality and technical debt seem to evaporate too because you have, you might have one person now getting one person driving and then that third person there might be saying, what’s the technical debt that I see being generated right now? What can we refactor? You know, maybe I’ll navigate a refactoring next, maybe I’ll automate this thing that we’ve done over and over again as the next task. And so in that, we get a lot of this, a lot of these anti-patterns kind of naturally going away. Um, lots of feedback loops. Uh, you know, this is a weird one, but like four cubicles actually costs more than a single mobbing station with a high end computer and two 80 inch screens. Um, so just like the actual physical coddle. So, so our office space actually ends up being mobbing stations and actually ends up costing less to maintain the entire mob space than it is to maintain individual cubes or even pairing stations. Um, uh, meetings in ceremony kind of go away. So like standup meetings don’t need to happen cause the team’s already aligned. Um, meetings with the product owner become, we’re programming while talking to the product owner and, and the code just keeps moving forward. And so the code base is move forward with everybody’s eyes in the vicinity, uh, all day, every day, essentially. And, and that really ends up helping. We kind of develop a group conscientiousness and um, we also, uh, I don’t know if you’ve heard of the, uh, Google study that evaluated the top five skills of productive teams and, and psychological safety ends up being on top of that. Um, what I’ve noticed and what I feel, I’ve worked in a lot of like psychologically unsafe teams in the past in my career. And um, and what I’ve noticed on mobs is that the psychological safety and feedback becomes necessary because you’re working with everybody all the time. And so that interpersonal risk taking that feedback delivery happens so much more, um, that the team becomes much more effective in a high paced rate. Um, yeah, it’s kind of like a, I dunno, mob programming, you know, to me has been brought up like a kind of like a steam roller, right? Like the code base keeps moving forward. Nothing gets in its way and you keep releasing features. And so sometimes it might feel expensive or slow, but the aggregate effect is that you have flow efficiency which gets deliveries out to customers and you don’t spend a lot of time working on waste activities like bug fixes, um, uh, meetings for just communicating status and things along those lines. Estimation. All that stuff kind of just evaporates. Um, for the team.

Dan Neumann: [19:46]  Before this we put a pin in the, in the conversation around estimating, maybe we’ll circle back at the separate episode cause that, that the need to or the, the a need not to. So let’s, we’ll put a pin in that. As you, as you were talking about working with the product owner, so a couple of things came into mind as you were talking through that. One was, it’s not the mob together all the time in the sense that you said, hey, if we’ve got those impediments, somebody from like spins off from the mob and maybe goes in and handles that impediment, they come back. And so it’s, I, I picture this kind of little organism or like part of it runs off over here and then bring it back to that stuff and runs off over here. Um, but then I got to curious how your product owner, because they are so engaged, where do they do anything like long range planning, um, you know, visioning, roadmapping, if that’s part of, of your approach to development, kind of refining the backlog, those types of things. Can you touch on that?

Chris Lucian: [20:36] So, so there, there’s a lot of nuance I think in our environment. So, um, some stuff that kind of got, uh, applied early on is that we want to deliver and get feedback. There’s a lot of risk creating a three year plan, um, and investing a lot of resources in that three year plan. Because what’ll happen is people are less likely to change the three year plan because they planned it. And so you’re incentivized preserve the value of that work, and so, um, so there’s a lot of risk with that. And so we don’t require that product owners don’t create a three year plan, but we do work in such a way that we only complete vertical slices and we basically get a card and, and shepherd it to production as fast as possible. Um, and that way we can get daily releases multiple times a day releases and uh, and, and while driving down, bug count and things along those lines, and then the product owner can change their mind at any time. And so a lot of, we, we basically make it as inexpensive as possible for the product owner to change their mind and in that they can go and chase really big opportunities when they arise. Um, because I think in, in my career, in the past, we basically say, hey, we’re going to have to change this massive plan to go and get this, uh, get this bit of work over here, this bit of financial gain over here. And people are like, no, let’s not do it because we, we, we have this course that we’re set on and we can’t really change right now. Um, in our environment with vertical slices, with daily deliveries, with low cycle time, uh, while we have is something where it’s like, hey, we just released something for this customer. They’re, they’re pretty happy right now. Let’s go and attack this growth opportunity really fast. And, um, and I’ve seen that happen multiple times. Uh, and as we’ve scaled, it happens on a regular basis where we actually able to make a smart financial decision based on a opportunity in the market that would have been completely, um, uh, unavailable to us in the past. And then the organization can shift around it, um, very easily because a lot of it is like saying, okay, well we’re going to have, we’re gonna invest a lot of time and um, and take developers away from development to then make this plan and then come back to it. And so our product owners do have longterm plans a lot of the time. But um, in almost every one of those situations, the, uh, the end result is that, um, they end up having the ability to change their mind. And often they do and they pushed back stuff. They rearrange stuff. Uh, they realized they were wrong because we did a production to delivery about something that they wouldn’t have received in three years. Um, all that stuff happens naturally. It’s really awesome.

Dan Neumann: [23:16]  That’s cool. One of the things you mentioned there, the agile principle of welcoming, changing requirements, even late in development for competitive advantage. Um, a, that’s when we’re doing agile training and talking about principles. That’s the one where people like who we do not welcome changes. It’s like, oh, that’s curious why? And it’s because they’re hard. They’re expensive. There’s, um, because of the way they’re doing them, they don’t have patterns in place or they’re not doing vertical slice or for whatever reason the approach team has taken has made them very expensive. And so that making change easy is, is a game changer for folks.

Chris Lucian: [23:54] If you explore Conway’s law a little bit and then Conway’s lobbying that your software, your code base, then the development or your code base even, but the architecture of your code base reflects that of your communication patterns in your organization. Right? Um, there’s something to that regarding flow as well. Right? And so, so if you want to get a vertical slice to production, like you could do vertical slices and you can prioritize vertical slices and you can maximize for flow efficiency but in a traditionally organized environment, not doing mob programming. But it’s a lot harder because now the communication costs goes way up between people. And so if everybody’s there sitting at the computer at the same time to actually deliver that piece of code all the way out to production, you, you eliminate all the different time, the queuing theory stuff, everything that that would block you from getting that production a release out. Um, and all the communication that happens to reduce bug count, um, that all naturally goes away because you’re, you’re all talking to each other right there and you develop a feedback mechanism to give each other feedback frequently.

Dan Neumann: [24:58]  That’s super cool. One other thing you mentioned that caught my ear and I think it’s really important to amplify, is you mentioned, the nuance in your environment. As I asked about the product owner and how they do some of these things and the nuance, I think Woody Zuill said, hey, we were kind of solving some of these problems and mobbing emerged. It’s not like they went out to look on, you guys went out, looked on the Internet and went, oh, these let’s be, there’s a company called Spotify that did a thing that works for them. And then everyone else went, oh, we want to do this Spotify model. Meanwhile, Spotify has moved on. It worked because of how it emerged there and the nuances in their environment. So can you maybe, um, I don’t know, does everybody in these other companies that are mobbing now, I’m assuming they’ve adapted to their own nuances and yeah. So maybe you can talk about that and the cautions of just saying, well, they mobbed this way, so we’re going to mob that way.

Chris Lucian: [25:56] Yeah. So, um, there’s a lot of great stuff that’s coming out of the community. Uh, the MOC program and community specifically. Um, I’ve started maintaining a list of companies that do mob programming on my blog. And so on the, on the right side, on the bottom there’s a link saying companies that mob. And there are so many ways that, that are really awesome, um, that, that have emerged out of there. Uh, there’s a, um, a company in Japan called cyber agent and they have what are called linking mobs. And basically they have, they have five people and they have two computers and they have a person that is linking the, basically keeping the navigators in context. And these two, two pairs that are ultimately, uh, they’re in existence but they’re pairing right next to each other and they’re working on the same thing. So it’s this all I, every five people in the same thing on two different computers and then collaborating in that way. Um, there is a Zito here in San Diego and they do, um, they basically organize their mobs, uh, their leader and their organization organizes their mobs based on, on how they’ve evaluated each individual skills and, and they switch out people based on these trio’s based on maximizing for flow efficiency on, um, in the, in those spots, uh, there’s a company in Calgary that had been scaling and the way that they did all of their hiring was they interviewed as mobs and then, um, allowed for people to, uh, onboard as mobs or not be hired as mobs. And so they would just hire all five people or not. Yeah. So, I mean, there’s a lot, a lot of great stories out there and a lot of people blogging about it. Um, there’s another couple of companies doing remote mob programming and they have a lot of tool definitions and things along those lines. Um, and then we also have a, there’s a mob programming conference in Boston every year. And so, uh, that’s where I find out about a lot of these companies doing it. Um, and uh, there are two pattern, uh, documents out there that are really popular right now. Um, one is the mob programming RPG by William Larsen, and that basically has like a list of behaviors and it’s, it’s formatted as a game that you can play when you’re doing a code Kata. And then the other one is, um, IBM, uh, and, um, uh, another organization had collaborated to, to publish a article in the Agile2019 proceedings that has patterns and anti-patterns of mobbing after mobbing for a year. Um, so there’s just been some really great, um, stuff that had had come out of it and gotten published. So, um, uh, I’m just really excited to see that. But everybody does it slightly differently. And um, and kind of my main message to people is, um, as long as you’re iterating on your process, then you’re evolving and that is caveated with you’ll only evolve in a good direction if you’re learning at the same time too. And so two things that companies should, I think in my opinion, all implement is dedicated learning time and frequent retrospectives that have one action item with an experiment to run and then evaluate at a time box. And if you’re doing those two things, you’re evolving toward better. And so mob programming might be one of those experiments for you. It might not be right for you, but you, you want to iterate and experiment often. And so, um, uh, my, my keynote in Tokyo was basically the dangers of not experimenting. Um, and uh, at the Scrum gathering 2019.

Dan Neumann: [29:19]  Is that video publicly available? I’ve not seen that one. I’m curious.

Chris Lucian: [29:24] Under my bio I have a list of talks there and I think, okay, that video is, is attached to there, but I can probably get a link.

Dan Neumann: [29:30]  We’ll look that up and try and get a link for it. And yeah, I recorded an episode of that, Adam Ulery one of my colleagues at AgileThought about an experimental mindset and I like what you’re talking about like dedicated learning time, do a retrospective, don’t just try something like frame it as an experiment. If we do this, we believe this will be the outcome. And then whether you validate or invalidate that you’ve learned, you win because you’ve, you’ve got the learning from having a hypothesis as opposed to a lot of oh crud, that didn’t work. We stink. Right. Just continuing to improve. That is awesome. Our time has flown. Yes. At least for me. It sure has. So I’m looking forward to maybe diving into that estimating thing at a future time. I had mentioned, um, when you claimed you claimed, when you had mentioned the performance of your team being really high, I pulled on that and I think you’d mentioned things you looked at where number of releases to production per period of time, bug count and production. You benched 18 months without a bug. I’m like, wow, that’s amazing. Um, the cleanliness of your code and did you deliver the right thing? Those are at least four of those. Are there any other major indicators of performance when you say this thing is better?

Chris Lucian: [30:37] Those things are, are um, really big. Uh, we have, we have a lot of stuff that’s like, we, we were able to deliver it and other teams weren’t. Like those are like a lot of the things we work on, complex enough systems work on global scale IoT platforms that have cloud dependencies as well as API dependencies and things along those lines. Like the stuff that we’re doing is sufficiently complex too to say that this, we’re conquering some really tough problems very quickly and um, and the learning and experimenting on the teams and the mob programming, uh, really influenced that. And so we have a really great forward movement here.

Dan Neumann: [31:15]  And I love that you’ve eliminated the easy problems through automation, right? You guys are programmers that allows you, that allows you to do the really interesting stuff.

Chris Lucian: [31:23] We a, there was projects that were kind of scheduled kind of speaking of a three month timeline or three year timeline in that three year timeline. Uh, when we first started there and after we first started mobbing, we realized that that three, three year backlog was almost entirely stuff that we could just automate based on, um, uh, creation of systems that would generate code based around a scheme of, based on the model. And so, um, we actually automated all of that work away very quickly. And so their, their three year timeline became like a few months worth of work very fast. And, um, and then we moved on to stuff more interesting, which is why we had opportunities within the organization to grow. And it worked out really well for us.

Dan Neumann: [32:05]  Very cool. In the spirit of kind of continuous learning. I’m curious what you’re either reading or studying these days that maybe has you, uh, has your interest.

Chris Lucian: [32:14] Yeah. So, um, uh, I like, um, Linda Rising’s a kind of constant returning to this idea of examining our biases and, uh, because I, I do become a big proponent of things that, uh, we have some, I’m currently reading, thinking fast or slow, uh, “Thinking Fast, Thinking Slow,” um, and a kind of per her recommendation. And that’s really been awesome. And then I’ve been exploring this idea of what is chaos engineering for our teams look like. And basically, um, I, I, we have, we have people that have been in mobs for years and years and I, I get concerned that unintentional silos get formed even though we are mob programming. And so, um, how do chaos engineers determine whether or not they’re, they’re, uh, systems are resilient? Well, they, they shut down a server. They shut down in an availability zone, they shut down. And so, uh, so I think the same thing needs to happen for our teams. You need to take that really senior person. That’s been working for, uh, 30 years, is a story that I heard recently, developer that is working at three years, and you just put them on another team and make them, make them a new contributor to another team and then make them available for questions. It’s a whole lot better than having them retire the next day. Um, and so that’s, that’s kind of, those are some of the things that I’ve been thinking about lately, uh, in future forward-looking movement.

Dan Neumann: [33:34]  Yeah. Very cool. Yeah, I love the concept of biases and we’ve all got them. Even when we’re there pointed out to us, we were like, yeah, but ours aren’t as bad as theirs, you know?

Chris Lucian: [33:43] So far the book has been, uh, has been fantastic, but I’m only kind of right in the very beginning of it. Um, and so it’s thinking fast and slow by Daniel Kahneman. Very cool.

Dan Neumann: [33:54]  Yeah. Um, an economist by trade. Yeah. Nice. Yeah. All kinds of good stuff and lots of data. Like you were talking about four a four. You’re mobbing, so, yeah, absolutely. Cool. Well, thanks for joining me today, Chris. Really appreciate it.

Chris Lucian: [34:08] Thanks for having me. It’s been a pleasure.

Outro: [34:12] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.

Stay Up-To-Date