Feb 2019
If you have no clue what Mob Programming is, read this:
Mob Programming by Woody Zuill
If you have no clue what Agile is, maybe you should come back later.
A whole team are sitting around one computer and solve problems. Right?
Looking a bit closer you'll find its about people and their way of working. It's their response to their environment. Their culture. And there it's getting interesting because culture always emerges and cannot be told.
The Howto and Why is explained in other posts. What I can add is some experience about preconditions for Mob Programming that may help you on your way.
I first got in contact with Mob Programming with the colleagues at TUI Nordic in Stockholm some years ago. They had a cosy place with a sofa, one screen and one keyboard and I wondered what the heck these people were doing. They explained us how they worked and what experiences they had. I instantly became a fan and decided to give it a try.
Back at my team in Berlin I introduced what I've "learned". We where 5 developers knowing each other for years and where already doing Pair Programming all the time.
So it should be a piece of cake making that Mobbing happen.
Haha. It wasn't fun the first time because we did some basics completely wrong. We were "driving" too long in the "seat", put the mate with the idea in the seat to explain and code, had long sessions evaluating articles and tools we wanted to use in our project and all kind of other mistakes.
But it still was attractive and we kept trying.
One day -or better evening- we had some very tricky stuff to do to figure out how our completely new deployment pipeline could be set up. We asked our Ops colleague to come over to help us. So we ended up sitting together with 5 developers, 1 ops and our boss who actually enjoyed the show.
And we solved our problems at the speed of light.
That was fun.
What happend? What was different to the days before?
We were so focused on the problem at hand that we unconsciously dit it right. No one had done this stuff before, everyone was only knowing parts. It was an open discussion about every single step we took, the driver was changing all the time, all pros and cons for each proposal were explained so that everyone in this round got the point. It didn't matter who actually put some lines of code or configuration in the right place. And finally we did it and everyone knew the important parts of the solution. Even our boss then understood why we did it this way and why things sometimes just take time.
When it comes to that close communication, some problems just disappear. You don't get stuck as an individuum because someone will have an idea. Code reviews are no longer needed (letting accreditations aside). Merging code is no longer an issue because you can work on one branch (I prefer working directly on master or trunk). The tooling is no longer a problem because someone knows it. Standups as well as retrospectives can become shorter and more seldom.
The problem becomes the problem and not the things around.
Later, in different roles, my point of view broadened. I learned much more about what has an influence on Mob Programming.
That's what this post is all about in more detail.
Mob Programming is often referred to as the next evolutionary step beyond Pair Programming. I totally agree. Saying this implies different things to consider. Claiming Mob Programming to be a software development approach is far too short. I would expand it to be a (software) product development approach. What I mean is that I don't see it as a tool for developers only anymore. I'll come back to that later.
By applying that approach I have learned that you need to be aware of some principles before starting your mobbing adventure.
The first thing to consider is the maturity of the team itself and the maturity of any single member. Each team member can be at a different level of maturity at the same time. And to make it more exciting, each team can be as well.
Your architecture must be suited well especially when it comes to having more than one team. If you have a monolith which goes through the door 4 times a year with all the celebrations needed it's unlikely having success with Mob Programming. The smaller the pieces of your stack are the better it'll work.
Here it doesn't end. The organization you work with must openly embrace this. Letting aside the usual question "How can this be productive?", there needs to be a culture where teams can make decisions about every aspects regarding their solutions. The approach looses track the more decisions are made upfront and without the team.
Maturity is a journey not a state.
As Martin Fowler perfectly laid out you have to go through all stages of maturity and can't overleap any single stage.
No matter what processes or tools you are using, measure where you are. (Agile) Coaches, a Maturity Model, Retrospective, Supervision all are helpful.
The following points are meant in the context of people working in teams, sitting together, working on the same code.
During my career I have seen -and actually experienced- different stages or phases of developer maturity. When acting in teams these stages sometimes cause troubles especially when you are not aware that these stages even exist. But all the stages and even differences within your teams are normal and opportunities to learn.
Once a stage is achieved one can easily switch between stages. But achieving a stage is different because it requires specific skills you have to learn.
We all know the super heroes coding all night, headphones on, rescuing any deadline, implementing any feature ad hoc and so on. This is the classic coffee in - code out mode.
There is nothing wrong with having a smart person working hard. The problems start in the long run. What happens if that guy gets sick or quit?
In general this mode shouldn't be your option if you want healthy teams. This way there is always lack of transparency, knowlegde transfer and quality. This approach does not scale.
Those people need to learn to share their work for the sake of the company. It is not their code that matters it's the company's result.
Two persons are staring at code. For what can that be useful?
There can be many reasons why this can be useful or necessary.
Code Reviews normally are leading to better naming and documentation of the code which should make it more easy to take over for other people. Basically you make the code more readable through reviews and less error prone.
I see roughly two stages or types of Code Review maturity. The first stage is working silently with merge requests. The second stage is doing the Code Review face to face. You can spend a lot of time playing a Code Review ping pong. The waste here is that you have to translate your thoughts into a written format. Regarding the time you have and the message you want to send that can be missunderstandable or can be misinterpreted.
The underlying thing is the willingness to get a good result, not only a fast result.
Nowadays Code Review is mostly done with Merge Requests, which basically shows the sum of changes in the code and where you can make comments. Only if the reviewer is satisfied the new code get's merged.
There are setups where that mode is useful or necessary. A mandatory two man rule or something like that. Or a remote colleague with an 12 hour time gap between zones. Or at least Open Source Code.
This mode should result into a better documentation, better naming of functions, variables and the other stuff and less common errors.
One thing I miss in this setup is the relation between senior and junior developers. Knowledge transfer is much harder for both sides when done by writing. Nothing beats face to face communication. You can actually handle that mode quite well but you'll be much faster if you talk to each other. That's it.
It's like having a private teacher. Even if the developers are very experienced there is always another perspective which is right.
The skills to be developed here are communication skills. The code is the star. The two developers need the capabilties to accept another perspective in a face to face conversation.
TDD (Test Driven Development) or BDD (Behavior Driven Development) is a software development approach where automated tests come first. You express up front in a test what you expect the code to do. Then you write the code. The difference between TDD and BDD is basically the way you express what to test. TDD comes more from a technical perspective and knows some interna of the software under test. BDD expresses the behavior of that piece of software in a more human readable style without knowing the underling code.
The focus switches to expressing the behavior, regardless of the concrete implementation. There is always more than one way to express the behavior in code. The code is no longer the problem. You look at your code from an outside perspective. If you cant test your code maybe it's rubbish.
The size of code is one thing the complexity is another. Automated tests address exactly this complexity. Human brains are not made for complexity especially in a changing environment.
That approach normally leads to better architecture. The behavior get's defined and the code get's along with the behavior not vice versa. And when you change the code the test will tell you if you broke the expected behavior.
There is often the argument that writing tests makes developers slow. Actually that comes from developers who somehow refuse to write tests. As a matter of fact it takes some time to learn how to test and how to write code which can be tested. When a developer overcome the hump they'll get faster because they no longer live in the debugger (Uncle Bob - Debuggers are a wasteful Timesink).
The code is documentation enough.?. - Actually not, but the tests can add a lot of value.
btw: that approach has some gamification aspects - e.g. challenge your colleague with a test that breaks the code ... I love it.
Pair Programming is basically when two developers are sharing one computer and work together at one piece of code.
Pair Programming has a lot to do with conversations about the best approach. The Problem becomes the problem. The code, the programming language, the architecture, the tooling and all technical stuff is no longer a hurdle. It's only details. Those people have a clear view at the task at hand and are more or less coding the solution the time they specify it. Up front there is no other instance like an architecture board needed putting away large architectural 5 year plans.
4 (senior) developers and guests are watching one guy coding?
The key to Mob Programming is that you need the guests. Only when Business Owners, Product Owners, stakeholders, maybe the customer himself, architects, ops team and all the other nice people actually join that space and have nice conversations then it's getting interesting. That does not mean that they have to stick there or join at a regular basis. No, only when necessary.
When you have all the right people there you are able to solve a task without any waste.
You save
It is more than the sum of its parts.
Mob Programming is the leanest software development approach I know.
I hope I could make my point that Mob Programming does not magically happen. What you can do to make it happen is to
I hope you enjoyed,
Maigl
Thanks for reviewing Jens, René, Susanne, Lydia
Thank you for the equipment Björn, Christian
