Team-oriented development (TOD) is a term we coined to describe flexible development within a team. As we experimented in our team, we found it unnecessary and artificial to divide our approach into “pair programming”, “ensemble programming (formerly mob programming)”, “parallel programming”, and “single fighter work”. Throughout the day we bounce around between these techniques and continually emerging variations, as the situation dictates. TOD describes this approach of flexibility and continual experimentation, not being bound by categorisation or the artificial barriers of one technique, but rather finding the best way forwards as a group with the aim of producing the best software possible whilst providing the most fulfilling experience for each individual.
We have found team-oriented development to be the ideal technique for sharing knowledge in the team, improving developer skills and increasing team cohesion and fun. In this article we will give you more details about TOD and share our experiences with TOD during real projects.
Pair programming – a good way to start
Focusing on programming techniques where two or more people are involved helped us to spread our knowledge in the whole team in a smart way. A way which also is fun.
Pair programming is a good way to start. Two programmers solving an issue together, talking about it, sharing ideas, etc. It is also a good way to bring someone up to date after vacation or illness without slowing down the rest of the team.
Various studies (e.g.  and ) report that pair programming produces higher code quality when compared with programming done by individuals (which we call “single fighter”). As soon as you start to give up the single fighter roles you will notice the difference. As a positive side effect you start to increase the bus factor and the “we feeling” inside the team.
A drawback of pair programming is contained in the word “pair”. In this method, only two programmers are involved, limiting the knowledge sharing. The two programmers involved build up knowledge which the rest of the team lacks. In the meantime, the rest of the team is building up knowledge that the two programmers of the pair session may miss in the end. Pair programming is an excellent technique, but we found that for larger groups the other methods under TOD are more effective to achieve your aims.
Ensemble programming – increase your team’s bus factor
Ensemble programming (formerly mob programming) is fun and it is a great way to spread knowledge in the whole team. Ensemble programming means that a team of developers (3-6 people are perfect) are using one computer to work on one task. One of the group is the “smart input device” while the others are responsible to navigate the person at the keyboard.
The role of the driver changes frequently, for example every 7 minutes. Here, you should experiment with your team to find your preferred shift length. You should also try different driver-navigator patterns. This all will help you to spread the knowledge in the whole team, giving a positive boost to your team’s bus factor. The bus factor describes, let’s say, your team’s health status. It estimates how many members of the team would need to be hit by a bus for the team to get in trouble through lost knowledge/skills.
Effective ensemble programming requires skill built up over time. It won’t work perfectly on the first, or even the 10th day. In a previous blog post we described the details of “ensemble programming and shared everything”. There you will also get more detailed information about the different patterns and experiments, and more focus about remote ensemble programming.
Parallel programming – break out for the win
Strictly speaking, ensemble programming and pair programming allow only one screen and one person to be typing at a time. Anyone who has worked with them will agree that there are situations in which this can be frustrating and limiting. There is an art in sticking with it long enough to let this frustration force you to learn, yet knowing when it truly is time to break up and work in parallel.
When we came to the point that it was hard to find a good solution for an issue and nearly everyone in the ensemble group had an idea how to solve it, we stopped the ensemble programming session and did what we call “parallel programming”. Everyone tried to solve the problem on their own machine while staying online in the video conference. Everyone was allowed to talk and could ask each other or talk about insights.
Traditional ensemble programming is frustrating in this situation because one person wants to read the documentation, another one wants to try changing some code or running a command, and still another person wants to search the internet for an answer. And reading text on someone else’s screen is a challenge in itself, with unexpected scrolling etc.
One of the benefits of ensemble programming is single piece flow – the idea that only one item is being worked on at a time. The value of this concept is backed by lean manufacturing. The beauty of parallel programming is that you maintain single piece flow. All programmers are still all working on the same task. But working in parallel gives them the freedom to look in the direction they want to. An example of this is bug fixing. When the bug is finally found, the person who found it explains the problem to the others. The others immediately understand the explanation, because they just had their head buried in the same issue and context.
What was useful to us was to set a timebox (around 20 minutes). After the timer finished, we came back together to share our individual research and decide whether we need more time (set up another timebox) or whether we should rejoin the ensemble programming session and try one of the found solutions. We also found it advantageous to set up time boxes, during ensemble programming and other experiments, which retains a kind of discipline.
Applying these techniques in practice
In one of our last projects we started off with ensemble programming. After a while we got discouraged by the challenges presented, and changed to pair and solo programming. But we kept trying the ensemble approach on and off. Eventually, we had achieved a certain proficiency in ensemble programming and experienced the benefits. We came to the understanding that we wanted to work as much as possible together as a team, and that we should use ensemble programming as our main technique to develop software. We strongly wanted to reduce single fighter tasks as much as we could in our daily business. But it depended on the work or task. When it fits the current task, single fighter work makes sense. We simply aimed to reduce it to a sensible minimum.
One disadvantage of strict pairing and ensembling is that work times need to be synchronised. This bears a certain social cost. We found it a better model to let everyone work when they want, loosely anchored around the standard 9-5 office hours. This is what most programmers are already used to. If someone naturally arrives at the office 30 minutes earlier than others, they should pick a job which is best-suited to solo-programming. Teams can put relevant tasks on a to-do list, ready for such moments. As other developers arrive at work, it might develop into a pairing or ensemble session, or two pairing sessions, etc.
As roughly estimated by the diagram, we used ensemble programming as our primary technique. Since we discovered the big advantages of parallel programming, we used it more often than pair programming. But, we only discovered this technique in a later state of the project, which explains the smaller bar on the graph.
Find the way for your team
The team learning process described above took time. Your team needs to find its optimum path.
Perhaps your team will discover that it is most comfortable and efficient when working primarily with pair programming. As long as the team is happy and reaches their goals, that’s fine. This is what TOD is really about: a team experimenting freely and discovering the best approach for them, together. And yet, the mindset of continuous improvement means that we really only ever discover “the best approach so far”. We keep challenging ourselves, gathering ideas and trying new experiments to further improve.
Team-oriented development is team-specific. Your team might find an ideal path, but when you as an individual join a new team, you must be ready to adjust, to restart the process and accept the learnings and outcomes in that scenario.
Team-oriented development strengthens your team
We observed, while adopting team-oriented development, that the “we feeling” and “feel good” atmosphere increased from day to day. We grew together to a strong team where every single team member was highly motivated and gave all their energy. Also, we recognized that we created something like a safe space regarding knowledge. Everyone had their own expertise and could help with different things. And everyone was willing to learn. So, nobody was afraid to say something like: “I didn’t understand that. Could you explain it to me, again?”.
All this sounds good to you? Then why not try your first small experiment today? Make teamwork great again.
 Herez Moise Kattan, Flavio Soares, Alfredo Goldman, Eduardo Deboni, and Eduardo Guerra. 2018. Swarm or pair? strengths and weaknesses of pair programming and mob programming. In Proceedings of the 19th International Conference on Agile Software Development: Companion (XP ’18). Association for Computing Machinery, New York, NY, USA, Article 43, 1–4. DOI:https://doi.org/10.1145/3234152.3234169
 Jim Buchan and Mark Pearl. 2018. Leveraging the Mob Mentality: An Experience Report on Mob Programming. In Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018 (EASE’18). Association for Computing Machinery, New York, NY, USA, 199–204. DOI:hhttps://doi.org/10.1145/3210459.3210482