The wisdom of the Mob

Experimenting with Mob programming in Skyscanner Engineering

By Keith Kirkhope

“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.” Woody Zuill

Since December 2016 we (the Traveller Content Platform squad) radically changed how we work. We stopped using traditional concepts and ways of working, which for us was based upon picking up a Jira card and working it by ourselves, or in a pair at a desk with dual monitors.

Instead we now all work on the same task at the same time, on the same computer and we love it! ​Take a look at how I’ve found the process and if you like the sound of working here remember, we’re hiring.

The Concept

I first heard about Mob Programming two years ago when we hosted a mobbing talk by Serial Seb at our Skyscanner office in Glasgow, Scotland. Since then, other than trying it for a few hack days with our Flight Search Squad and our TCP squad I did nothing much except talk about it. Then, in November 2016, Woody Zuill was giving a talk at the JP Morgan’s European Technology Centre (two blocks away from the Glasgow office), so I went along for another perspective on it.

During the talk, it struck me that many of the issues he talked about I experienced daily in our TCP squad. We had unevenly distributed knowledge and massive skills gaps. Forexample, I came from a ASP.Net Windows and front end background and TCP is a Python Linux backend platform and after 8 months I still couldn’t work many of the systems effectively. We had issues writing up cards that either didn’t explain the problem and what we wanted resolved or were too specific so the implementation of them would necessitate​ rewriting the acceptance criteria. We could get work done but if the person that did it was off then we’d have to leave it until they were back as it wasn’t clear how they had done the task.

Doing It

In the spirit of build, measure and learn, by asking for forgiveness and not permission, I picked an unused part of the Glasgow office, found a spare TV on wheels (abandoned in the corner of the Glasgow office putting green), grabbed a foldaway table and whiteboard on wheels from a seminar room. I picked up a spare MacBook from IT Services and then we got going.

Our first mobbing station set up!

In practice it works by having a role called the typist (sometimes confusingly called the driver) who sits at the keyboard of ‘mobbly’ (our mobbing mac)​. The typist is then instructed what to type by the navigators. We use a timer to rotate the typist role about every 10 minutes, we reduce the time if the mob is large or increase it if the mob is very small. The navigators can have their laptops open and act as the researchers for the current task (or the next one you know will be coming next). Every hour or so you take a break to give everyone time to recharge.

If anyone thinks they are not learning from or contributing to the mob, they can leave the mob to do research or work on some of the smaller requests we have. Usually when this happens it’s a good checkpoint for us to validate that we are working in the right thing in the right way. When they re-join the mob they have to debrief the mob on what they have learned or done.

Mobbing in dedicated space in our Skyscanner office in Glasgow, Scotland.

We’ve been doing this for four months now in the dedicated space we’ve created in our office. Over that time, we’ve broken down many knowledge silos that existed within the squad. The squad now has a clear picture of what our purpose and goals are and the business reasons behind them. We no longer must spend hours writing Jira cards, or doing stand-ups, or having planning or pre-planning meetings. Instead if I or someone else understands the problem we act as the primary navigator and explain it to everyone. Knowing why we are doing a task means we can each challenge and/or improve how we implement it.

Is it slower?

With a team of four engineers we certainly move less cards across our Jira board and have less work in progress than we did. It can feel slower as you can’t be the tech or business ninja and blast a card across the Jira board to “Done” as fast as you could. But, that is because to get anything done your idea must go through at least one other person’s brain as they type it into the computer i.e. you must teach at least one other person how to do it.

We find our work speed is much more consistent than it was before. If you are still unsure about this then think of how many times you have been stuck on a problem for a while only to explain it to a colleague and then immediately solved it. Imagine having that available most of the time?

**How big can the mob get?**​

We are still learning and from speaking with others that do Mob Programming at other Glasgow companies I think the best rule of thumb is:

Only split the mob when people are no longer learning or able to contribute.

What did we learn?

1. We each realised what everyone’s skills and knowledge strengths and weaknesses were.
2. We realised that some of us learn very differently. Some of us will go and read up on the technology/tool and then start using it where as others will read and explore the technology at the same time. Useful to know when we are working on something that no one understands yet.
3. We continually upskill just by just observing the tools, techniques and tricks we each use.
4. Holidays and absence no longer blocks tasks. We all have the knowledge to be able to continue working on them.
5. We keep a more constant rate of progress. Issues we identify are solved as we go which leads to better software in the end.
6. Everyone is always aligned (yes really).
7. We talk/discuss/plan a lot more than before — we’re always using our whiteboards
8. It’s nice communicating and collaborating with everyone all instead of sitting next to them working on our own ​

So, should you try it?

Yes.

You don’t ha​ve to do this all the time. You could try it on certain days, for certain projects, or maybe just in the mornings.

How do I try it?

It really is a practical case of going slower to go faster. Get some colleagues together with a laptop with a timer and give it a go. It’s that simple.

Reach out by commenting below if you have any questions for me to see if we can help further.

Further reading on this that could be helpful:

• Our top 12 mob programming tips and thoughts by GOV.UK
• Experimenting with mob programming to rebuild the GOV.UK Verify frontend
• Using mob programming to solve a problem
• The Team Coder: Mob Programming
• The Mob Programming RPG

Fancy working with someone like me?

We do things differently at Skyscanner and we’re on the lookout for more Engineering Tribe Members across our global offices. Take a look at our Skyscanner Jobs for more vacancies.

We’re hiring for Skyscanner Engineering Managers

About the author

Hi, I’m Keith and I’m a Senior Software Engineer and squad lead of the Travel Content Platform squad at Skyscanner’s Glasgow office in Scotland. Outside of solving problems at work you’ll find me falling off my mountain bike around Scotland, trying to get some attention from one of my two cats or planning holidays with my wife. I find building the correct software solution in the best way is often not a technical problem but a people one. Here at Skyscanner we are able to learn and experiment with how we work, which enables us to to deliver better products.

Keith Kirkhope, Skyscanner