Doing great, Craig.
Craig: Excellent. So Woody, we have met a number of times at the last couple of conferences and one of the things that I guess appealled to me is that you’ve got some really unique approaches to the way that you attack teams and different problems.
Yeah, I hope it is not that unique.
Well, I am a developer. I have been programming for about 30+ years. And I was first introduced to what I would now call XP, Extreme Programming, in the late 90’s. And ever since that I’ve just been an advocate of the Agile approach. And my main interest is clean code, that’s easy to work on and expresses itself well and is easy to maintain. Right now I am managing a team of developers and we call ourselves the Hunter Mob, or mob programmers, and it’s a topic maybe we want to talk about. For one thing.
3. You are a manager at Hunter Industries. So what are they about, what do they do?
Yeah. So Hunter makes sprinklers and they are sort of the … I would say, they are very innovative in what they do and they have a very high quality standard, so it’s a wonderful place to work. They really understand the idea that we need to do quality work. I love working there.
Craig: So, one of the presentations that you have been giving here, in fact I first came across the mob programming, as you call it, at an Open Space session at last years conference. And I was extremely glad to see that you actually got it to a full session here at the conference. Tell us about mob programming. It is an interesting concept.
Yeah, so the basic idea is that pair programming keeps two eyes on the code at all times and increases the ability to communicate to each other about the code. We are talking about it all the time. Mob programming extends that out just a little bit to a whole team. So essentially we have everybody working on the same code, the same problem, at the same time, in the same space and on the same computer. Being on the same computer is what sort of makes it a little bit different than the way a lot of teams work.
Craig: That’s the key, right? Everything else is pretty much pair programming until you got a team of in your case five or six people, that are working on the same computer.
Yeah, that’s correct. So being on the same computer pretty much means, we have to have some techniques to make that work. But the key to this is that any concept that is going to go into our code is discussed, as it is going into the code base. So anything that we want to do, has to be verbalized and so we use this role we call driver navigator. The driver is sort of a smart input device. He or she is working at the keyboard taking information from the navigators, who are discussing how we want the code to look, what do we want the objects to do. And that means we have to express it well verbally. We have to understand it well and everybody is watching it at the same time. So if the understanding isn’t there, that’s clear to us, it’s transparent. So we pretty much go from a good idea to vetting it, to getting into the code base and reviewing the code all at the same time.
Yes, so basically to make this work, everybody has got to be looking at the same screen, and when you are working in mob programming, that really means you need to project them, or have some huge monitors. With the projecting what we get is dual monitors, but they are just big on the wall. And we also have two keyboards, although we only use one at a time, they are both are hooked up to the same computer. And that makes it easy for who ,ever is going to be driving at the moment, to wheel themselves up in their chair, to the spot one of the two keyboards and start working. Every 15 minutes we change. So we keep this roundory we call it or rotation going throughout the day, where everybody is at the keyboard for no more than 15 minutes. And the keyboard is not the seat of honor. It’s just, you are the current input device and we switch it up, so that you can gett back to being a navigator as quick as possible.
Craig: So, the 15 minute thing is interesting. I mean XP teams I’ve seen where they struggle with whether they should they rotate every day or every few days. You are rotating every 15 minutes.
Well, in pair programming you might switch off your keyboard every few minutes. And there is, I have read at least about six or seven different models of pair programming, where you do ping-ponging, or I write the test and than you fulfil it, or the person with the idea takes the keyboard and they type it in. But we really think that the value here isn’t, that I have got an idea and therefore I key it in, it’s I have got an idea an therefore I need to be able to express it. And it’s that forcing ourselves to express it in human terms, that really clears the air. We all get to understand it. There is a lot of benefits to this.
Craig: So you strive to be a crossfuntional team. And you did mention in the talk, that everybody codes.
Yes.
Craig: But not everybody on the team is a coder.
Not necessarily do they start that way. I said that kind of backwards. But somebody coming on the team might not be a very accomplished coder, but they’ll become one pretty quickly. Because there is this concept of continuous learning that happens and it accelerates your learning. So if you kind of can code a little bit, you’ll become better very quickly, when you work in this situation, because you are constantly exposed to a good way to do your work. All the shortcuts become apparent, all the IDEs we work with, the coding conventions, how code itself works, it’s all exposed and shown continuously. So when you are working alone, you often go: there must be a shortcut for this. You search around on the internet, you don’t know the right keywords to find it. Here you just ask “Hey, is there a shortcut for this”? Or you see someone use one, you go “What did you just do there”? And, we learn quickly. So we’ve got a couple of guys on the team who really started out in the QA world and a couple of us, who started out more coding, but we all have to code and we all have to do QA on this team. So those with the QA skills have become much better coders and those with the coding skills have become much better QA people.
Craig: And that was really a big, as much as I had seen it before, that was an eye opener to me, in that I struggle in some teams where you have traditional QA, to get these guys to even sit down and pair with the developers. I mean, this process is that you can’t help but understand the code, because you are actually typing it in.
Yeah, and you are watching it. An odd thing happens, I have noticed that we stay intent on what we are doing a lot more in this model. And we have a lot of little conventions we use for that. If I happen to notice or somebody notices, let’s use it the reverse of that. If I am starting to kind of nod off and someone notices it, they are going to ask me for help. They’ll say “ Hey Woody, can you help me with this, I am not quite understanding it”. So we have a lot of little tricks like that we use, to keep ourselves engaged. And then when one of use feels like it isn’t really the time to be engaged, they can always get up, go do something else, take a walk. So there is no rules, beyond we all try to pay attention. Well, we do have this little idea, that to be able to work together all day long, we really have to get along well. So we have a lot of little rules we use just about being considerate and kind to each other and having respect. We always respect the code, nobody sits down and says “I am going to undo all that and I am going to do this”. It’s always a group decision.
Craig: And you have got a reasonably good teamwork ethic as well, like you sort of mentioned that you guys go and do things at lunch time together and things as well.
Yeah, I am not sure exactly how all this kind of jelled, but it just jelled. We all get in about the same time, eight o’clock. We spend an hour studying every morning, then we work the rest of the day till five o’clock and then we go home. During the day, we are interacting all day long and as often as not we take a hike at lunch together. We could pass a sandwich shop on the way and pick up something, but our hikes aren’t just a little walk up and down the street, we are actually getting into some hilly areas, dirt trails, and we all seem to enjoy it.
So we have both the concept of automated tests of various types and the concept of manual testing. And we work closely hand in hand with our, you might call your product owner, we think of them more as our partners, and we serve seven departments, so we have a number of partners, that we work with in the company. And they come and actually sit with us. Sometimes they’ll even take the keyboard and code as well. That’s not so common, but they’ll come and sit with us as we code. And so, as the code gets written, we automatically generate tests for some other things. We also do test driven, so everything gets tests as we go. And then the automated testing, after the fact, is almost a non-issue, because the tests exist, but we can run them at any time and we do run them frequently. We still have the idea of some manual testing that needs to be done, so we count on our partners to help with that. So we try to get our work into production frequently, daily, even sometimes a couple of times a day. And they know when those changes are coming, because they’ve been working with us and we let them know the minute they are there and they vet them at the other end, or test them, or check them. Because we are always taking baby steps, the tests are kind of quick and easy to do.
Craig's full question: I know the answer to this and I found it amusing when you answered it in the course, but I’ll ask it for the people who haven’t seen it. A lot of people are probably thinking this sounds great. You’ve got a team of six people, you are are pairing around one computer. How did you sell this to management? You know, management obviously poke their head into the cubicle and go “Hang on a second, one person is typing. How does this work”?
Yeah, well. I can’t make that same joke again. The basic idea though is that, if we’re turning out code and we are delivering projects, everybody is happy. It’s way more important to see that code in use, than anything else. So, it’s kind of a problem, when we see two or three people huddled around doing the same thing and we think, maybe they are redundant, we don’t need them all doing that same thing, but the results are what counts. And I think my manager or my boss, once he saw how serious we were, he just supported it 100%. It didn’t take him long to see that. A matter of fact, can I tell a little bit of the story of how we started doing it?
Craig: Please do!
So we had done these hour and a half long study sessions every Friday, which we are also still doing, in addition to our hourly study, our daily study. And we were doing coding dojos, where we were basically doing a similar roundory kind of thing, before we did anything that we would call mob programming. And we got this large project, we were working on and we felt we all needed to sit together to discuss some things and we started passing that keyboard around, just like we do during our study. So “Oh, let me take that for a second” and someone would say “do this and do that”, and after about two hours of that we, the room we reserved, you know, we had to move out and so somebody just got on the system and reserved another room. And after about two or three days of doing that, hour after hour moving from room to room, we do a lot of retrospectives and we started saying “We had better find a permanent room”. That’s how we solved the problem of having to move from room to room. Well after a couple of weeks of that, we realized that this is a way of working, it’s really working well for us and we decided to just continue with it until we find a reason not to.
That was two years ago. So it’s working good for us. We don’t recommend it for anyone else, we recommend that you get good at doing retrospectives and let the team decide what works best for them. And this is what the team decided to do. And let’s say, over the two year period we have probably worked together 99% of the time, some really high number. The only time we are not really sitting together is when we have things to do like expense reports or to write some emails or things like that. We even have a group e-mail account, all communication comes to the team through the group e-mail account and we always answer as group. So the rest of the company kind of knows they can turn to any one of us, if somebody is on vacation, they don’t have to worry about them being served. That’s pretty nice.
Interestingly, we make a product and there are many many teams that do things other than programming, because it is a manufacturing plant. But one group had come, they worked with us a little bit on something and the next thing we’ve heard, they had set up their own little mobbing area or a little collaboration area. And another little department did. So the concept of people interacting well and working closely together, once you see it in action it’s pretty natural. And I think other people throughout the company have kind of gotten the idea that maybe it’s useful for them. We always recommend, if it looks useful, let’s try it. Tomorrow we can say, hey, we don’t like it. But we can try it.
8. Is there any special tools that you need to be able to make this whole thing work?
Well, besides having a good environment, so we basically set up two standard tables, side by side. We have a lot of room. As a matter of fact it is really critical, that you are not hurting your back or neck while you are doing work at a computer. So we noticed initially, that when we were sitting around a table and all looking to the end of the table this way at the screen, that wasn’t very good. So we had to get ourselves in a position where we could all face the screens without hurting our backs or necks. We also stand up frequently, we don’t have the same stress as you would normally have if you are at the keyboard all the time. Although many of us have laptops, because we are doing other things when we are coding. All the code goes through one computer, but we are also researching, checking things, taking care of little incidentals.
So through osmosis we are still involved in the team, but sometimes we have these little daily things that we deal with. But we are still not keyboarding all day long, most of the time we are not keyboarding. And keyboarding just means having your hands on the keyboard and maybe your wrists are in an ackward position, you know, all the things that cause physical problems. We also, it’s not so much a tool, but we use a lot of hand cleanser. So we use this hand sanitizer all the time. When you sit down at the keyboard, before you touch the keyboard you clean your hands. There is a lot of other things we could cover about this. I don’t know how much you want to cover it, but toolwise it’s very simple. You need to have an environment everybody is comfortable working with and we use things that are important not necessarily to the mob alone, but are important to our programming, such as a good unit test environment. We use approval tests extensively. We are in a Microsoft stack, so we use a lot the MVC tools. But we would program, we could do this with any language. The tools are available.
9. So it’s less about the tools and more about the set up and the team approach
Yeah, how we interact with each other, because this is what Agile is all about, individuals and interactions. I often joke about that, but once you get down to just one person, you can’t divide that team up much further. And when you are working on code, unless you are writing something for yourself, you have got to interact with somebody, somewhere along the way. And so this just emphasizes that it makes it easier to do.
Craig: So the other thing, mob programming of course they can check that out on www.mobprogramming.org, where you blog, it’s a really good resource I think, that’s building up.
Yeah.
Craig: So the other thing that I wanted to talk to you about, while I have you here, a complete change of topic, is the No Estimates movement. I come from Australia, we have a couple of people like Neil Killick in that environment, who I know are pushing that movement or pushing that idea I guess, I don’t want to call it a movement.
Yeah, we are just expressing an idea.
Sure
Craig: Because there is a lot of fear, uncertainly and doubt around that topic.
Well, absolutely. And to make a very strong point, Neil and I are good friends and we communicate about these things quite a bit. We have a very different idea about what these things mean and how we can resolve it. Personally for me, what No Estimates is about, is alternative ways to make decisions, that don’t require that we use estimates. So a No Estimate decision is a decision we made, without having to do estimates to make it. Now there is lots of things we can do in programming and in a lot of our work outside of that, that require estimates or that we can use estimates for, sometimes for budgeting we want to know how much will it cost us to maintain a team of five people over the next year and I can easily make an estimate about that. I can’t determine the exact costs, because we might need to hire somebody new or maybe we’ll lose somebody at a lower pay scale and have to hire someone at a higher pay scale, the economy could boom and everybody costs us more, but we know how many computers we need and how many chairs we need and we can budget for that, so we can estimate and come pretty close.
Some things we can’t estimate so well. And interestingly, estimates are actually quite easy to do and they can be pretty accurate. But the problem is’nt with how easy they are to do, or how accurate they are. Is has more to do with, why do we need the estimates. What is our motivation for having these estimates? Without spending a lot of time to describe it, what I noticed for myself was, we can work without estimates. So rather than saying, “well, how in the world can you work without estimates”, let’s just try working without them, see what that means and then decide at what point do we need estimates. I found out for myself, that there was very little that we were doing, and this was way before I was working at Hunter, there was very little that we were doing that really needed to have the estimates. So the basic idea is, whether we have them or not, I want to know alternatives for making decisions, other than using estimates. That’s it in a nutshell.
Craig: So I assume lots of people maybe haven’t been following the whole twitter hashtag, #noestimates
There are probably very few who are!.
Craig: And also, a lot of good blog posts both from yourself and Neil and others in the community. Most people who hear this, and I talk about it at meet-ups and things as well, most people go “But you don’t understand, my manager dot, dot, dot.
Right.
11. How do you deal with that?
Ok, this is a very good point. So the No Estimates message isn’t that we shouldn’t do estimates for the people who are asking for estimates. We should help find out why we need estimates. So if someone is asking me for an estimate, that’s not why we need the estimates, that’s just why I need to do an estimate. If we don’t have the influence in our environment to question that, then it probably kind of stops there. We have to do the estimates. This message is really more for the people who are asking for estimates. Why are we asking for estimates? Does it really help us make good decisions? As a matter of fact, it is all about making good decisions. If we could make our decisions in different ways, or have different ways of working, then maybe we wouldn’t need those estimates. So are those ways of making decisions good? So rather than ask, can we work without estimates, I want to ask why do we work with estimates? Do you have a way to prove to me that you are making good decisions?
It’s easy to make decisions based on estimates.This project is going to cost us two million dollars, that project is going to cost us 1.5 million dollars, which is a better project to do? Do we want to get more benefit? Maybe this one will give us more, maybe that one will give us more. So how do estimates help us make that decision? Most of the time in projects that I have seen, having really great on the money estimates does not necessarily lead to good decisions. It often leads to mediocre decisions. This is something we can control and therefore we’ll do it. I am not sure that’s a good way to go. I can’t really express too much more about that, without having to go into a lot of detail. But I believe that we can do better and we should be looking for ways to do better. And I think the discussions are just getting started.
Well, convincing somebody that they don’t need estimates is not a thing that I found any way to do. That’s just the way it is. And having those discussions just leads to people saying, we still need estimates. So from my point of view, and guys like Neil are working on a very different approach, which is to find a way to do some kind of a forecasting based on a work flow that allows us to break our stories down to as small as possible and just work on them. Personally I can take any size of a story and let’s just start working on it and within a few hours, maybe an hour, we’ll start identifying parts of it, that we can work on more easily right now and get to a result. Once we see that, then we focus down on just one and constrain ourselves to that one little bit, and as we work on that one, we’ll discover what part of that we want to do. So it’s kind of like this. Out of most projects I have worked on, 20% of the functionality gets in use and 80% of it never does. 20% of the features we wrote provides 80% of the value of the thing.
So maybe we can just discover as best as we can that 20% and over time it has come to me to look more like five per cent. I have noticed on a lot of projects that I have worked on, if we can get pretty quick to that five per cent that is most important, the interest in the rest of it wains and people start saying “I like what we are doing here, but we’ve got this other thing that is more important”. Well, now we have got something new that is very valuable and we may never need to do any more on that project. So why spend all the rest of that money on something to get everything we thought we wanted, when maybe we can do it with just a way less effort, way less cost. Let’s discover what’s important quickly. That doesn’t mean prioritizing by the way. I don’t need to know what’s the best thing to work on. All I need to know is something of value to work on and then steer towards best. Let’s start with something and you go “Yeah, this was useful, but I’d like to add that”. Now we are steering and we can do that pretty quickly, I have noticed. So that’s the way I like to work.
Craig's full question: Well the conversation continues on that and it’s good to see that people like yourself and Neil and Ron Jeffries and others who are in that discussion, continue to debate it out, that’s the only way we are going to find new ways and open up new channels. So Woody if people want to know more about you and all the awesome things that you are doing, where is the best place to go and find all that?
Well, I am glad you mentioned the www.mobprogramming.org site, which we put together I think between last year and this year, because so many people were asking about it. Than I have my own little blog which if you just search for me on the internet you’ll find it: Woody Zuill. I think it is www.zuill.us with a slash and some stuff after that.
Craig: And also on twitter where a lot of the conversation continues on #NoEstimates.
I am @WoodyZuill on Twitter.
Craig: Excellent. Thanks very much for your time Woody, it has been a pleasure to talk to you.
Thank you, it was a pleasure.