Knowing the elephant: mobbing way

Once upon a time, six blind men went to find out what an elephant is.The first man touched the legs of the elephant and thought, an elephant is like a big pillar or a tree with strong skin. The second man touched the tail and came to the conclusion that an elephant is like a rope with a brush at the end and it can move right and left very easily in air. Well, I won’t bore you with what the rest thought as I’m sure you can sort of imagine.

2

What brought this story back to me from the old memories of childhood was a one day course I did on ‘Collaborative Exploratory and Unit Testing’ which was an introduction to ‘Mob Programming’ with the focus on collaboration of developers and testers. In this article I’ll try to explain why after this 8 hours course, as an experienced QA, I felt I’ve been a blind man and the projects I’ve worked on are some sort of elephants or dinosaurs! I could also sense a delicious scent of more modern Agile.

What is Mob Programming?

‘Mob Programming’ is an agile approach to software development where all the team are in one room working together with one keyboard. Just to be clear all the team means all the stakeholders, devs, testers, designers, project owners and so on. There are three roles in Mob Programming:

Navigators: Everyone in the team who ‘guide’ what should go in the keyboard. The brains of the team.

Designator: The decision maker of the Navigators. The final voice who decides what is the final decision of all the ideas to go in the keyboard.

Driver: Person behind the keyboard. The muscles of the rest of the team. Driver doesn't give feedback for the time he is on behind the keyboard and only does as being told by Designator.

There is a rota and every few minutes the roles will be switched (common rotation intervals are 5 min, 10 min or 15 min). In the training, we sat in a circle and each time the timer beeped we would shift one to the right to switch the roles.

The mobbing technique applies to all aspects of the software development process, including requirements and testing. A project owner for example will not write code but the team might decide, for example, to work on refining stories first. It can be thought of as the outgrowth of ‘Pair Programming’.

We started practicing this method in the class for a few hours in a group of 13 developers and testers. We were given an application which we explored and documented our findings. For the second half of the course, we started working on one of the bugs that we had found. We investigated the reason, made the code testable and added a few unit tests for it.

In all honesty, the first couple of hours was quite confusing. I thought it was interesting but the same way as a mad hatter tea party is! Everyone was throwing around different ideas, we didn’t know the application and the code, we had different skills and there were quite a few misunderstandings and disagreements. “How can this approach improve the performance?” I asked myself. But as the time passed, we started understanding each other's languages, we were able to prioritise ideas and started becoming more of a united force. The clouds of doubts started to fade out and some sunshine started to show up.

Why Mob Programming Felt Like Some Sunshine?

Whole team working together  improves the average team performance. Every team member is good at something and not so good at another, also everyone has bad days and excellent days. Mobbing has the potential to pick the best of the team.

There is no hand over state. This means "I can work with you on this, as opposed to handing this over to you". Teams can complete more work faster and less issues will be generated after coding.

More thinking is put into the product before an idea forms a piece of code.

It builds up a shared knowledge and leads the team to find and form a ubiquitous language. It also means less dependency on key skills and knowledge.

Tester and Developer Collaboration

As a tester what impressed me the most was how this approach promotes transparency and creates empathy between devs and QAs and has the potential to improve the quality of the product in less time. There are differences between the mindset and the language of devs and QAs. The most obvious example is indeed the word ‘Testing’.

In a developer language, ‘Test’ is usually done to:

• Check a feature works exactly as the spec says
• Creating feedback from code
• Prevent regressions by writing unit tests

To a QA, ‘Test’ means:

• Explore a feature with some guidance
• How this feature works with the rest of the product
• Look for regressions

Mobbing, gives the opportunity for these two worlds to meet in a new way.

Tester’s feedback while the code is being written can prevent a defect from appearing. This can also help the developer to write (unit-)testable code at early stages before going too far in development.

On the other hand knowing about which unit tests exist saves a lot of time for the tester when scripting and running tests. They can focus more on exploratory and integration test as well as finding out which part of the code has been touched and needs regression testing.

It also gives everyone a better understanding of the application and the state of it.

Yes to Mobbing?

Mobbing probably is not a solution for every project and every team and maybe not the best approach from start to deliver, but I think it is a method that’s worth a try if a team is struggling with delivery or aim for higher performance. It helps the blind men know sooner and better what an elephant is!

For more information about Mob Programming have a look here:

A Success Story of Mob Programming

Mob Programming Guide Book

http://mobprogramming.org/

Red Badger is currently looking for a manual tester to join our team, if you are interested take a look at the job role here.