I remember when I heard the term 'Mob programming' for the first time. As with new concepts, I was eager to know what the new fad was about, and if someone had again just come up with a fancy word for something we were already doing on another name.
With a little research, I learned that it was whole team working on one computer. Everyone taking turns. It mentioned testers in the team also taking their turn on the keyboard, round robin style, regardless of the activity. I can't say I was convinced it would be a good idea, or that it would be fun. And in particular, I wasn't convinced that including all the testing work into the same style of work would be a good idea. Or that I would in any way be fit for that style of work.
However, I invited Woody Zuill to Finland for Tampere goes Agile to talk about Mob programming. It seemed interesting enough, different enough, revolutionary enough to be thought provoking. I listened in particular to the parts where he was discussing wait times building up and how that could be avoided, and could see a connection to things I perceive as relevant: feedback and reaction to it. And I started thinking it would be fun to try it out, even if it meant me taking a turn on writing code every 15 minutes or looking at code most of my days. I also liked the ideas about team decision-making enabling change of mind, as learning would happen.
I suggested mob programming at work with my team to get a primitive reaction from one of the developers, who was clearly offended with the idea that introverts are forced out of their corners with all these crazy agile ideas. And when Llewellyn Falco was in Helsinki and suggested he could spend a few hours with my team on refactoring (as a mob), I did not even tell the team that we would be trying out mob programming.
So there I sat, as the tester who prefers not to work on code, working on code. We took turns on being on the computer as driver, and the rule of others navigating made it quite easy. I thoroughly enjoyed seeing how simple things were difficult for my team's developers, and how things I thought might be difficult were made simple. I feel we learned a lot about shared naming styles, about keyboard shortcuts and about regular check-ins of code (or fear related to those). But a few hours is different from the idea of actually moving to do all work like that, and we did not do any testing yet.
Another chance to think about my feeling toward mob programming came as I was in San Diego, and got a chance to spend a day with Woody Zuill's team. It was a day in early January, and the team was not in its full manpower, just three people. I somehow assumed I'd just watch, so you can imagine the shock when Woody took it as a natural thing that he would add his visitors on the team to work with the team. Apparently that is what they are used to doing. A new company, new product, no clue on what is going on whatsoever, and joining a team - sounds like a reason to panic or complete waste of everyone's time.
The timer was set on 4 minutes - allowing faster rotation with newcomers - and everyone would take turns. I can't say I particularly enjoyed the driver seat, I was always so relieved when I could get off. We were sorting out a web service call not going through and while I was totally uncomfortable, I also started noticing that I could actually follow on what we were doing. The others were super helpful, building things up from telling a beginner line by line, tool by tool, window by window, and quickly adapting to telling a little less as the simpler ideas sunk in. They were navigating on the level the person driving can understand, building up the level as we went.
I can't imagine better introduction into a new team, a more efficient way of making sure new people start learning. With half-a-day, I have an idea about one part of the product. From my interests as tester into the system, I could get a lot of information that was relevant, quickly. And some things I might not be so interested in might also rub on. Seeing the team work this way made me think of empathy and understanding - to all directions. Woody talks often about "kindness, consideration, and respect" and he seems to live to those with him team even with visitors.
With half-a-day with Woody's team, I changed my mind on wanting to work that way. In addition to experiencing my discomfort and learning, I got a tour around discussions of what needs to be done and could imagine testing done in the very same style. I saw they were organising specialised times for product level exploration, again for the whole team. Planning and learning were nicely tied to the overall package. And one being away (or half of team being away) did not stop them from making progress.
I'm still not convinced if all work in a mob is a good idea. But a lot of work in a mob would be a great idea. And I still would love to experience a "all hands testing day" with Woody's team. I have a theory from my experiences in the past that testing might be different than programming for a mob.
I've really liked coding dojos in the round robin style. It works great, having a pair at a time working on things. But with testing dojos, I always felt very disconnected while I was not in the pair. While coding, we were creating a common understanding, but while testing, we were missing out on ideas because software speaks when you use it, we were getting easily disengaged.
With testing, I like mixing different dynamics: solo work in isolation; solo work in pairs where some stuff is shared right away and most stuff is shared at end of session allowing focus for the session; paired testing on one computer in driver-navigator -settings; group testing in round robin style; group testing where some stuff is shared as it is learned, but most things are discussed after session. Pairing tester-minded people and pairing tester-developer.
My team has promised to spend half a day every two weeks like this - refactoring, programming together, hopefully testing together too. All I need to do now is follow up on the promise and schedule it. Knowing them, they would slip away if someone wasn't organising it. Any other testers out there trying this out?
With a little research, I learned that it was whole team working on one computer. Everyone taking turns. It mentioned testers in the team also taking their turn on the keyboard, round robin style, regardless of the activity. I can't say I was convinced it would be a good idea, or that it would be fun. And in particular, I wasn't convinced that including all the testing work into the same style of work would be a good idea. Or that I would in any way be fit for that style of work.
However, I invited Woody Zuill to Finland for Tampere goes Agile to talk about Mob programming. It seemed interesting enough, different enough, revolutionary enough to be thought provoking. I listened in particular to the parts where he was discussing wait times building up and how that could be avoided, and could see a connection to things I perceive as relevant: feedback and reaction to it. And I started thinking it would be fun to try it out, even if it meant me taking a turn on writing code every 15 minutes or looking at code most of my days. I also liked the ideas about team decision-making enabling change of mind, as learning would happen.
I suggested mob programming at work with my team to get a primitive reaction from one of the developers, who was clearly offended with the idea that introverts are forced out of their corners with all these crazy agile ideas. And when Llewellyn Falco was in Helsinki and suggested he could spend a few hours with my team on refactoring (as a mob), I did not even tell the team that we would be trying out mob programming.
So there I sat, as the tester who prefers not to work on code, working on code. We took turns on being on the computer as driver, and the rule of others navigating made it quite easy. I thoroughly enjoyed seeing how simple things were difficult for my team's developers, and how things I thought might be difficult were made simple. I feel we learned a lot about shared naming styles, about keyboard shortcuts and about regular check-ins of code (or fear related to those). But a few hours is different from the idea of actually moving to do all work like that, and we did not do any testing yet.
Another chance to think about my feeling toward mob programming came as I was in San Diego, and got a chance to spend a day with Woody Zuill's team. It was a day in early January, and the team was not in its full manpower, just three people. I somehow assumed I'd just watch, so you can imagine the shock when Woody took it as a natural thing that he would add his visitors on the team to work with the team. Apparently that is what they are used to doing. A new company, new product, no clue on what is going on whatsoever, and joining a team - sounds like a reason to panic or complete waste of everyone's time.
The timer was set on 4 minutes - allowing faster rotation with newcomers - and everyone would take turns. I can't say I particularly enjoyed the driver seat, I was always so relieved when I could get off. We were sorting out a web service call not going through and while I was totally uncomfortable, I also started noticing that I could actually follow on what we were doing. The others were super helpful, building things up from telling a beginner line by line, tool by tool, window by window, and quickly adapting to telling a little less as the simpler ideas sunk in. They were navigating on the level the person driving can understand, building up the level as we went.
I can't imagine better introduction into a new team, a more efficient way of making sure new people start learning. With half-a-day, I have an idea about one part of the product. From my interests as tester into the system, I could get a lot of information that was relevant, quickly. And some things I might not be so interested in might also rub on. Seeing the team work this way made me think of empathy and understanding - to all directions. Woody talks often about "kindness, consideration, and respect" and he seems to live to those with him team even with visitors.
With half-a-day with Woody's team, I changed my mind on wanting to work that way. In addition to experiencing my discomfort and learning, I got a tour around discussions of what needs to be done and could imagine testing done in the very same style. I saw they were organising specialised times for product level exploration, again for the whole team. Planning and learning were nicely tied to the overall package. And one being away (or half of team being away) did not stop them from making progress.
I'm still not convinced if all work in a mob is a good idea. But a lot of work in a mob would be a great idea. And I still would love to experience a "all hands testing day" with Woody's team. I have a theory from my experiences in the past that testing might be different than programming for a mob.
I've really liked coding dojos in the round robin style. It works great, having a pair at a time working on things. But with testing dojos, I always felt very disconnected while I was not in the pair. While coding, we were creating a common understanding, but while testing, we were missing out on ideas because software speaks when you use it, we were getting easily disengaged.
With testing, I like mixing different dynamics: solo work in isolation; solo work in pairs where some stuff is shared right away and most stuff is shared at end of session allowing focus for the session; paired testing on one computer in driver-navigator -settings; group testing in round robin style; group testing where some stuff is shared as it is learned, but most things are discussed after session. Pairing tester-minded people and pairing tester-developer.
My team has promised to spend half a day every two weeks like this - refactoring, programming together, hopefully testing together too. All I need to do now is follow up on the promise and schedule it. Knowing them, they would slip away if someone wasn't organising it. Any other testers out there trying this out?
