Ease in to Collaborative Programming
.png)
Erik Svensson
Systemutvecklare
In this article I propose an alternative approach to pair and mob programming, that puts less tension on the team and caters to more personality types.
Pair and mob programming are the go-to standards for modern collaborative programming. However teams are still failing to commit to these coveted techniques.
%20Ease%20in%20to%20Collaborative%20Programming%20(cover).png)
So, you have a problem…
Your team works in silence, some people are even wearing headphones to avoid being disturbed while they hack away. It takes too long to get new features out and certain key people cannot go on vacation at the same time, because then everything stops.
With the upcoming changes in business requirements you realize that something must be done to increase collaboration. At the next retrospective you suggest Pair Programming. Since it promises to address the issues at hand by improved knowledge sharing, increased code quality, and overall increased interpersonal skills.
As you propose this idea to the team you are immediately met with reluctance: “I work much better alone”, “Pair programming is a waste of resources”, “Pair programming is not for senior developers”. You somehow manage to convince the team to, at least, try it for the next sprint.
Did it succeed? Most likely: No. How many sprints can you keep pushing before you end up with disgruntled team members? Why does pair programming fail?
%20Ease%20in%20to%20Collaborative%20Programming%201.png)
Change is Hard!
What you’re really asking from your team is a change of behavior. You want them to step out of their comfort zone and into a new, scary landscape where their flaws are exposed and they must verbalize their thoughts and cater to other peoples feelings and opinions. Anyone who’s been in a pair programming session knows that it’s mentally exhausting — even if you get along well with your pair-mate.
The speed of change is also individual, which can create an imbalance in the team. Some team members might actually never become comfortable with highly social collaboration. In-fact, a lot of programmers became programmers for this exact reason — they’re great at spending time alone, highly focused on a specific task for hours.
Instead of expecting your team to jump directly to pair or mob programming, let’s look at a softer approach!
Enter Swarm Programming
Swarm Programming is an analogy for a swarm of bees building a hive. They are not necessarily working together on the exact same task. One bee might be foraging while another is clearing debris from the hive entrance. Regardless they are using their shared intelligence to achieve a common goal, while keeping constant communication on their progress.
%20Ease%20in%20to%20Collaborative%20Programming%202.png)
The perhaps biggest upside with pair and mob programming is that it allows team members to share the same context, often a user story. Meaning that they don’t have to pay the context switching penalty, and don’t get stuck waiting. Actually, it’s only when they live within the same context that the other collaborative upsides happen:
- Knowledge sharing, since they must have the same level of understanding of the context to solve the problem.
- Code Quality, since they must design, implement and test a solution together given the context boundaries.
- Interpersonal skills, since, well, they must communicate to achieve things above. And possibly also communicate with stakeholders to finish the story.
How do you get team members to share the same context without forcing pair or mob programming?
A solution is to always assign at least two people to the same user story. Don’t tell them how to work the story. Make it clear that you trust them to come up with a solution in any way they deem appropriate, and then work it until completion.
%20Ease%20in%20to%20Collaborative%20Programming3.png)
Given this working contract, the introverted programmer can partake in an initial design discussion, identify a set of changes and then work alone for a couple of hours. Others can do traditional pair programming for a while, until syncing up with the rest of the swarm. This methodology requires less change of personal behavior, while still being collaborative in essence.
Ideally this will also affect how your team slices user stories. Vertical slices that cut through all layers become easier to implement when you can divide and parallelize the work within the same user story. It also works well with TDD, where the group starts off by writing tests together and then using the tests as acceptance criteria when syncing up.
In Summary
- If you fail to implement pair programming or mob programming in your team.
- Try instead to always assign at least two people to each user story, and trust them to find the best way of solving it together.
- They should keep context switching to a minimum by never starting another user story before the current one is worked to completion.
