Matt : We could. We both work on Cucumber open-source project. It is an acceptance testing tool that tries to bring together non-technical people with developers to agree what the software is going to do and write automated tests to define that. Steve and I sort of specialize in the Ruby version of Cucumber. There are lots of different versions of Cucumber that run on lots of different platforms, but the Ruby one is the one that we work on. Anything else, Steve?
Steve : We also work on Cucumber Pro (code name, I think), which is our company, which is also called Cucumber, but Cucumber Ltd. It is our Software-as-a-Service product, which is about trying to get these feature files, these acceptance tests, these documents that are written collaboratively by teams to describe the behavior of their software. So out of the code base and into the hands of the people that really care about it which is the business people: the product owners, the business analysts.
João’s full question: You have just given a talk about mob programming in a remote setting. How long have you been working remotely and why did you choose this approach? Steve : I have been working remotely, not specifically mob programming. I have been working for the last five years or so. Matt and I used to remote pair on Cucumber open source every Friday for a while for a few years now.
3. Why are you working remotely?
Matt : We have been remote programming on the open source for a while and then October was when we really kicked off with this re-boot of the development of Cucumber Pro which is when we started working as a mob remotely. So that is October. So I think that is 5 months now that we have been doing that solidly.
4. And have you been enjoying it?
Matt : It is alright.
Steve : Yes, it is the most fun I have had programming for years.
Steve : I do not know.
Matt : 100%.
Steve : Well, we do not work 100% remotely. So we get together.
Matt : Periodically – I would say once a quarter – we fly everybody to the same part of the world and we hang out for a few days, sometimes that is a big house in the country, sometimes it is a few flats in a city, a few apartments in a city and we do a bit of work and we do a bit of play. So there are some times when we are physically collocated. And I know other companies – I have got a friend that works for WordPress, for example – they do exactly the same thing. Mostly, everybody is distributed, but occasionally, they all get together in the same place and meet up and hang out. I think that is an important part of making remote work.
6. […]What are the dynamics?
Matt : We do different things when we collocated. So we tend to save up the kinds of things that are better done in a room where you can throw index cards around, put big flip chart sheets up on the wall. We are trying to sort of save those exercises up for the times when we are in the same room and we have gotten good at doing the other things that we need to do day-to-day through the media that we have available to us for remote. So we use tools like Screen Hero for work on the code, we also tend to have a Google Hangouts window open either on a separate device or under the screen. We Slack because you have to nowadays, don’t you? Otherwise you get kicked out of software development. GitHub is also important for some of the asynchronous work. So those tools help. Oh, yes, drawing pictures.
Steve : We discovered a tool called Limnu, which we use to share a white board and it is really nice for the people who have tablets because they can draw with pens and things and it is pretty good. It is not perfect, but it works and we use it to draw ideas of what we are doing and just stop like waving hands like I am doing now.
Matt : That is one of the things that can get quite frustrating about working remotely. I think that also you can tend to start to try to explain every idea with code and if you were in the same room, you would draw a picture and it can be a mistake just because the thing that is in front of you is a text editor. It is not necessarily the best way to communicate the idea.
Steve : Yes. We start at 8.30 every morning and that is when we convene the mob. We get everyone together, usually a little message on Slack – who is here today? – and we fire up a Google Hangout, start talking about what we are going to do, maybe share a screen or share a Limnu drawing or a Google doc, depending exactly on what we’re doing in some kind of collaborative thing, some tools that we can work together on. And we do that until about 11.45, when we try to stop and then we have a retrospective.
Matt : And the retrospective is something that we got into this habit of doing on a daily basis, at the end of the mobbing session. It is not just reflecting on sort of how the code is and what we are going to do next, but it is also a bit matter about how do we get on with each other, if there is anything we have learned about how we can mob better, anything generally concerning us. I think that sometimes the retrospective will point out that it feels as if we are starting to run out of planned work and we probably need to have a planning session soon. Things like that will come up. So having that kind of level of conversation is a daily habit, it seems to have been really important for us and we logged that in a markdown file in the master branch of the repo that we are working in. So there is always a visibility of it for people who were not there that day. It is a really good way for you to get a summary of what you have missed if you were unable to be part of the mob that day because you can definitely feel like you are missing out on a lot of conversation. In the context of our organization, because we are distributed, [we do a lot of] Slack chat and we can keep up with nearly everything that is going on in Slack. But there would be just this big gap where the mob disappeared off when we are talking in real time in Hangout. The retrospective is a good way to catch up on that. So we sort of do it almost for the people that were not there as much as anything else.
Steve : I do not think we would say we are following any particular methodology. I mean we have all come from an extreme programming background. So I guess that is where we started. Maybe not by the book, with… like, specific iterations and we do not have all of the rituals that are there. We come from the same place.
Matt : Waffle. I think if anything, you would call it KanBan if you were going to recognize it. We use a tool called Waffle, which sits on top of GitHub tickets and allows us to see them in a continuous flow. We have WIP limits, they are self-imposed. We have a WIP limit of 1 for the mob, but it might be that in an afternoon, while you are not mobbing, you might see a problem that you want to fix and you might submit a little pull request so there might be sort of two or three other things of WIP hanging around, but they will tend to get closed by the mob the next morning. They do not tend to last for very long. So that is our general process, I guess. It is that we do things just in time. So rolling wave planning – I think that is the name given to that – we will sort of look ahead and see when it looks like we are going to need some more work to work on, then we will switch gears and start doing planning type of thinking or customer search type of work rather than programming. But what we are trying to do is to use the afternoons to keep doing the research work, so the divergent thinking, so that the mob is fed with good, productive problems to solve and we can get on with doing programming. That is not always the best thing for the mob to be doing. Sometimes it is good for the mob to talk about what is the plan.
Steve : I mean this is constantly evolving as well. We recognized last week, when you were not around Matt… that things were getting picked up and we started to work on them. What people were really trying to do was do some research on it, but the way we had set up our board made it look like they were in progress and really, what we realized, was actually no – they are at a stage before anyone was really working on them, it was researching. It was a stage to our flow. So all of this stuff – we are just doing the things that we think we need to do to make it work. And we are figuring out what the next thing to do is for the process and for the product at every stage.
Matt : It is something that we wondered about, because we all know each other and I know Martin Fowler said that it is difficult to take new people into the team when you are a distributed team. And it is something that worries me a bit if you reach that stage where we want to add in more people. Where would we find them? And who would we be restricting? Who could we add? Because it would be easier if they were people we already knew. I do not know if that is true – that is just what I have read. Attributes in general of somebody? I think anybody can find it hard. I think that we have learned that it is important to be gentle. We are all men, we can be quite abrasive with each other sometimes and we learned that people get hurt and get stressed and it is important to be careful and kind with your words. I think that is something we learned. So if somebody does that naturally, that would help.
Steve : I wanted to get back to what you were saying about introducing new people. Because actually I think we have not done this yet so it would be hard to judge. But I have a feeling that the mob, the fact that everyone in that group has learned how to do this together. Adding someone new to it, we would be able to help them learn how to do it and it would be a less stressful thing than being like the other end of the remote spectrum where you are on your own all day… Because what this mob programming adds to remote work is a real social element to working from home.
Matt : The idea of learning together. Yes. It is true. Maybe Fowler is wrong in this instance. I hate to say on camera that maybe Fowler was wrong in this instance just this once….
Matt : I think misunderstandings do happen in Slack. I could think about one particular team mate – she is incredibly sarcastic all the time and sometimes I find it really hard to tell whether she is being straight faced or not when she says something. You have to check. I kind of think about your question more about because the mob is live conversation in a Hangout and I think we have developed an atmosphere and a culture in that conversation where you kind of nip those problems in the bud. Nobody wants to hurt somebody else’s feelings. Sometimes somebody says something either because they are actually feeling a bit stressed and it is genuinely a bit aggressive, but they did not mean to be, or somebody misconstrued something. Steve, I remember you mentioning very early on, one of the things you liked about the way – we are like a married couple. We have known each other for years, we kind of bicker with each other, but we are also very good at calling each other out when something is not OK. I think this may be the general atmosphere of calling each other out when things are not OK, quickly, so that it does not get out of hand and turn it into people being upset.
Steve : There is something else that we have just started doing in general in the business. We did not talk about it in the talk, but we have started using these one to ones which I think is an opportunity of everyone in the team to just talk to somebody else on the team about how they are feeling, how they are doing, what is going on and maybe get a bit of coaching or help to figure that out. It is in very early stages, we are still experimenting with it, but I think that is one of the ways that we are trying to deal with that problem is that we are giving someone the opportunity to at least talk it through and if they have something they are worried about, give them some help to figure out how to do that.
Matt : We have this technique that we came across doing training and consulting about how to run a discovery workshop. So there is this bit that you do just before you actually write your Gherkin specification, your Cucumber test. It is called example mapping and it really involves, in the ideal setting, being in a room with a table and a pack of index cards so you kind of lay out a map on the table of your understanding of the story. That is obviously difficult to do if you are remote. At the moment, we would just do that using a Google doc with kind of bullet points to represent the different kinds of things that we are looking for in that session – the examples, and the rules and the questions. And that works OK.
Doing the example mapping which we would feed into Cucumber is harder to do remotely. We just do not have the tools yet. But I think that working on Gherkin specifications together to clarify what we are going to build feels just as useful if not more useful given the fact that we cannot actually see each other, that we can agree on our current understanding together.
Steve : We have not talked about it much, but one of the big difficulties that we are trying to solve all the time is the fact that we are programmers and owners of this business and we do not just write Cucumber in the open source. So we do not just write Cucumber Pro, we run a coaching and consulting business and we have to keep that business going because that is the thing that feeds our families and pays the bills. That is the constant problem that we are always trying to deal with…
Matt : …juggling the two. We found that sometimes it will oscillate a bit to one direction or the other. So we get a really good client and we get really busy doing training and then like suddenly there is no one around to mob and the product is not going anywhere. Or vice versa: we really need to focus on the product and then suddenly we did not make any money this month. No one has booked any trainings. So trying to find that balance and get that steady is difficult. I think that wearing so many different hats as a small company and growing… Actually none of us actually involved in the business have ever done this before. We have never grown a company like the way we are going. So it is exciting, but yes – there is a lot to learn on a lot of different levels.
Steve : I think that on the Cucumber product, there are always problems like how we are going to do a specific thing in a specific way. But the mob kind of naturally solves that. We are finding that the mob helps in solving these problems. We can either go away and do some research and bring it back to the mob and then you get four or five different heads working together on the problem. I do not feel that the challenge is that we do not know how to solve. Maybe not that we do not know how to solve them but we will not be able to solve them.
Matt : Are you not going to ask us whether we think mobbing is a waste of time considering that we are running a business?
João: You can answer that question! Matt : It just seems to me to be this sort of unspoken question. It’s almost “the” question at the end of our talks. Because somebody said what is the ROI and I said I do not know. So the experience we went through with the first version of Cucumber Pro which we tried to kind of write in a rush, under a lot of pressure, we ended up doing a lot of solo work on it and we ended up with a project which did not seem to fit what the market wanted and the core base was unpleasant to work on because it had a lot of technical debt in it. We do not want to go back there and I think we have gone maybe right to the other end of the spectrum and this code base is certainly really nice and easy to work on and so far the customers that we are talking to – and it is in its very, very early days yet – also seem to really like it. I think it has that feeling of quality right through it. It has that conceptual integrity thing that Mary Poppendieck talks about. It feels like it is true to what we need to do.
Matt : What I have noticed is that in any mobbing session, if we are getting to the point where we are starting to overly clean up the code, we are doing something that we do not need to do right now, there is always somebody that will spot that and nip it in the bud again. So rather than having a pair, than maybe spend an afternoon fixing something that does not really need to be fixed, it will get called and it will stop and we will take a step back and then we will figure out what is the right thing to do. And that has been amazing to see how well that focuses the work that we all do together and of course all the time, we all know what is going on with the code so that any one of us can work kind of independently and suggest changes via pull requests, but also, depending on who is off the next day, we are always able to keep that momentum running and keep going. Yes, it is a really powerful thing.
João: OK. Thank you so much.