Pair and mob programming: How Agile becomes and remains successful
At last month’s JAX conference, Thomas Much talked about pair and mob programming and how Agile becomes and remains successful. We caught up with him to talk about all this and more.
JAXenter: Hello, Thomas! The agile movement has come a long way – from the grassroots movement to today’s mainstream. What fascinated you personally about the agile movement? What’s the thrill of it for you
Thomas Much: The aim from the very beginning was to improve cooperation between the persons involved. These are not only the developers, but also the testers, the company, the departments and ultimately, the customers. On the way to the mainstream, it has unfortunately faded a little into the background between all the agile frameworks and processes….But especially in recent times there has been a growing interest in why we strive to solve tasks “agile” at all. What are the alternatives or consequences if we work on these tasks without the agile mindset?
Proper use of agility minimizes disruptions and blockages – those involved can do their work better and together. This motivates and hopefully even brings some fun to work. When the customer gets a better product and is more satisfied, it is incredibly meaningful for me as a developer.
Proper agility minimizes disturbing and blocking.
JAXenter: Many traditional companies find it difficult to become agile. Why is that? What are the typical obstacles that need to be overcome?
Thomas Much: In traditional companies, there was a culture of Command & Control that probably lived for decades. Once employees have come to terms with this system, it is incredibly difficult to get away from it. Perhaps in such a situation agility is prescribed from the very top, but that is often only Command & Control in other clothes.
Agility needs an atmosphere in which transparency, honesty, and trust can develop. Such an environment cannot be prescribed, it must be created carefully (and laboriously!). But that means change and initial uncertainty, and letting go of known (and perhaps also comfortable) working methods. It means the dissolution of incentive and bonus systems that stand in the way of overarching cooperation.
The more traditional the company, the more obstacles there are. It takes courage to initiate a change from the very top, which takes all previous company levels along on the path of (cultural) change.
JAXenter: In your session at the JAX conference, you said that simple pair programming can also backfire if developers are simply placed in front of a computer in pairs. What’s the problem?
Thomas Much: People are very different. Maybe two developers understand each other immediately – then their pair programming will work without any effort. But if two developers don’t get along so well – for whatever reason – this can quickly lead to tensions that have a negative effect on the whole team.
It is also very important that pair programming is carried out interactively so that the developers’ creativity is retained. Otherwise, you are bored, exhausted and at the end of the day, you are knocked out.
JAXenter: And how can it be done better?
Thomas Much: In addition to “doing” pair programming, reflection is always part of it: Did pair programming feel good? Did it get us anywhere? What should we keep, what should we change? Thinking about how it works without an external view is often too short or, by nature, difficult (and is therefore omitted). Here, a coach or simply a non-team developer can help by accompanying the pair and/or team with external view and give feedback.
In IT, we are brain workers. Ultimately, it’s about supporting our brains, learning and creativity – even over a longer period of time and without burning out. This can be achieved, among other things, by frequently leaving the keyboard and by taking regular, short breaks.
JAXenter: How can mob programming help here?
Thomas Much: Some people find mob programming more pleasant because you don’t sit together in such a small space as with pair programming. There are also many more developers in the room, so you’re not alone with your ignorance when there may be someone else in the room with the same “stupid” question. It’s easier to accept knowledge.
With mob programming you can efficiently distribute knowledge in a whole group.
In addition, there is more of a variety of knowledge in this space. This promotes creativity and stimulates discussion in which everyone involved acquires a deeper understanding of the current task. The fact that one can distribute knowledge very efficiently in a whole group with mob programming is almost only a pleasant side effect :)
The important difference compared to discussion rounds is that we as a mob have executable code at the end. We have a result that is part of our project code (which may then be supplemented and refined by other pairs or mobs). If you know endless discovery and planning meetings, in which none of the participants have enough knowledge and you actually have to research and build prototypes first, you can try mob programming for half a day or a whole day instead. It wouldn’t be the first time that a team suddenly blossoms, because it can put its creativity into problem solving, instead of being stuck into a fixed meeting structure.
JAXenter: Which current trend in agile movement do you find particularly exciting at the moment?
Thomas Much: The “Modern Agile” movement has been around for just over two years. It has learned from the experience of two decades of agility and describes how agility can work in the long term and sustainably from today’s perspective – in software development, but not only there. For this purpose, four guiding principles have been defined:
- Make People Awesome
- Make Safety a Prerequisite
- Experiment & Learn Rapidly
- Deliver Value Continuously
In my opinion, there is no better way to summarize what the basis for modern software development should be. If you are interested in more detailed information, you can find it at http://modernagile.org/
JAXenter: What was the core message of your session that everyone should take home with them?
Thomas Much: Methodical coaching on Scrum, Kanban etc. are helpful and important to give us an idea of how agile working can be, what rules exist and above all why they exist – so that I can adapt them retrospectively, eliminate them or supplement them with new rules or conventions.
But that’s only one part. How well this methodical framework works depends on how the people in the team – us! – work together and fill the framework with life. With many lone warriors, however, it is incredibly difficult to achieve our real goal: to provide customers with a result they are satisfied with.
In software development, pair programming and mob programming can support teamwork. In the same way, as there are rules and conventions in the methodical procedure that we question in retrospectives, one should also know a few basic behaviors for working in pairs or mobs in order to be able to analyze and improve them retrospectively. That has to be trained again and again! But then with pair and mob programming you have two powerful tools at your disposal which you can use regularly and successfully.
JAXenter: Thank you very much for this interview!