2/4 @ 1pm Mob Experiment

Mob Experiment 2/4 @ 1pm

 

Sorry, it took so long to get notes posted.  I didn't take notes during the session.  So, I will first tell the story of my experience mobbing (which is how the session started out).  Then, I will add notes of what I remember from the rest of the conversation.  For those who did take notes or remember other things we discussed I would grateful if you added them in the comments!

 

About 6 months ago, the technical practices agile coach where I work, Quinn, came to me: "Christine, I want to do an experiment and need a team to work with."

 

I said "Sure, I'll have to get the team on board but, I'm sure we'll do it."

 

"Great! I want to do an experiment with mobbing."

 

My response was something like "Oh…" My lack of enthusiasm was because we had done a few hour training on mobbing in the past.  When we tried to mob on our own, we failed miserably. But, we agreed to do the experiment with Quinn despite previous failure.

 

For those who don't know what mobbing is, to quote Woody Zuill, it is having "all the brilliant people working on the same thing, at the same time, in the same space, and on the same computer."  While mobbing we use the driver/navigator practice.  The navigator tells the driver what to do.  They are the ones to decide what needs to be done and what direction the mob should be going.  The driver is the person at the keyboard.  They are essentially a smart input device, implementing what the navigator says.  While mobbing, you regularly rotate the roles of driver, navigator, and part of the mob.

 

The experiment was for my team to commit to mobbing for 2 hours a day for a sprint (2 weeks).  Quinn committed to facilitating the mobbing sessions for those 2 hours a day. We decided that the morning was the best time for the mobbing sessions.

 

At the time of the experiment, my team had 3 Scrum teams working from the same backlog.  My Scrum team, who participated in the mobbing experiment, consisted of 3 developers, 1 SDET, and 1 manual QA.  Our manual QA did not feel comfortable joining in on the mobbing rotation but, would sit with us and provide valuable insight from the testing perspective.

 

When our 2 weeks were up, we had nearly doubled the amount of work we finished compared to each of the previous 3 sprints.  I have been told that it is unusual for teams to increase work completed in the first sprint mobbing.  There are a few things that I believed contributed to the increase. 

 

First, three sprints prior, we had started work on code we had just inherited from another team in the company.  So, it took a little bit to get familiar enough with the code to be able make updates without having to decipher what the code is doing in that area.

 

Second, the mobbing helped the team focus on the work that needed to be done.  Since we were working on the same thing at the same time we all knew where we were at with the sprint work.  This helps to make the work being done go more smoothly and be less disjointed.  Also, since our manual QA person was sitting with us, she got to see what we had already created automated tests around and know where to focus her testing.

 

Third, because of mobbing progress was still being made even if someone has to head off to a meeting.  When working more individually, there were times when work on the next story could not be started because the person with the knowledge needed was booked in meetings or maybe on PTO.  When working together the often solutions can be found even if they don't have as much knowledge about the code as the person not there.

 

Since the experiment went so well, we decided to continue mobbing for 2 hours a day.  After 1 or 2 more sprints, we started occasionally mobbing in the afternoon as well.

 

About that time,  one of the other Scrum teams decided to try the experiment as well.  Their team had 2 developers and a manual QA.  Their QA was comfortable being the driver but, did not want to be the navigator.  After 2 days, Quinn decided that since they were doing pairing more than mobbing. So, we decided to merge the two team.  Since we had already committed to 2 Scrum teams worth of sprint work, there was some concern from our Scrum Masters, Product Owner, and manager about getting the work done but, they agreed. Happily, it worked out pretty well.  Technically, we had 3 stories carry over but, I only count 1 of them because the other 2 were completed shortly after planning was done for the next sprint.  We liked the results of the combined team so well, we have continued as a single team and are still mobbing today.

We now are pretty consistent in mobbing both mornings and afternoons.  So, there is rarely any work that anyone does on their own.

 

 

Some things we talked about during the discussion:

• The drawing in the picture is a sample of a layout of a mob team. 
• For mobbing, the computer needs to be connected to a TV (or even two).  It's hard enough for two people to crowd around a monitor.  Imagine having 3 or more people!
• The driver sits in front of the keyboard (on the right in my drawing).
• The mob sits in the middle.
• The navigator stands away from the driver.
• The reason to have the driver and navigator separated is so that the navigator speaks loud enough so that the whole mob hears what is being said.  It also helps the mob stay engaged.
• My team has the navigator stand in front of a whiteboard where we write our intent and possible steps that we need to accomplish.
• Sometimes, as we get the work done, we realize we don't need to do all the steps we thought we did or that there are other things that need to be done.  So, don't spend a lot of time talking about what needs to be done…get started doing!
• Llewellyn Falco (a technical coach/consultant) recommended not using a whiteboard but, creating a text document.  Then you can save the document, review them, identify patterns in the work the team does.  Then, you can find ways to do your repetitive work better/faster/automated.
• Rotation
• My team started off doing 5 minute rotations but, are now doing 7 minute rotations.  After 4 rotations we take a break.  Our break is 7 minutes as well, just to keep times consistent.
• Llewellyn's comments
• New teams do 4 minute rotations.  This helps everyone stay engaged (a person gets back to being navigator faster).
• 7 minutes is the absolute max amount of time you want a rotation to last.
• If the team is getting stuck, shorten the rotation time.  Since a different person becomes a navigator more often and everyone thinks differently you are more likely to get unstuck.
• Getting more junior DEVs comfortable putting their ideas "out there"
• Mobbing helps be sure that everyone's input gets applied
• Mobbing allows the junior DEVs see that the senior DEVs can make mistakes, go down the wrong path, have to restart, etc…
• Facilitating mobbing
• When starting out mobbing, it is highly recommend that there is someone who is not participating in the mobbing to facilitate the mob.
• Even when you've been mobbing for a while, I t is extremely difficult to facilitate mobbing from within the mob.  When you are in the mob, you are trying to accomplish the task that the mob is working on, so, you don't always keep the mob following the principles of mobbing. 

Sent from my iPad