Teams Choose How They Work

Related to our goal of allowing teams to choose how to address problems within their domain and problem space, we find it important to allow them to choose the manner in which they work. Ultimately we want to deliver value. Given every team is made up of different people that bring a variety of preferences and opinions, how they work to deliver value might look a little different from team to team. We see this variety as a strength that can be utilized as team members pull fresh ideas from their own past experiences to inform how the team can move forward in accomplishing their goals.

Mob Programming

With that said, there are a number of benefits with mob programming that teams should consider when deciding how they work. Among these benefits is a strong knowledge transfer that reduces knowledge silos, expedited onboarding for new team members, teaching each other new things on the spot, more opportunities for holding each other accountable for quality of code, impromptu decision making conversations that don’t need to wait for a meeting, and a very strong sense of collaboration that can be hard to replicate via other methods.

Paired Programming

Paired programming shares a lot of the same benefits as mob programming, with the added benefit of being one on one with somebody else. Although we strive for maintaining psychological safety on teams, working one on one can produce an even safer feeling of being able to make mistakes or ask dumb questions or go off on a tangent to teach someone a concept, all of which might be harder to do in a group setting depending on the team’s dynamics. Pairing can also help you to be more engaged in the task at hand and can help you get to know individual teammates better.

Individual / Solo Programming

Although mob and paired programming have many benefits, we should also keep in mind that solo programming can be beneficial as well. Some engineers prefer less of a social experience when programming, which is totally fine. Others want to push themselves to better understand the codebase, and see solo work as a way to build muscle in that regard. At times there may be very mundane tasks that some teams may decide does not need to be worked on by the whole group.

Considering the less collaborative nature of solo programming, code reviews and pull requests should definitely be happening often. Documenting of decisions and actively avoiding knowledge silos should be addressed regardless of the style of work, but can become even more important to emphasize when working solo.

Choose Your Own Adventure!

We have seen teams be successful in choosing how they work. Some teams choose to mob all the time, others mob 3 times a week then solo the other two days, while others choose to solo or pair a majority of their time. Whatever the choice of the team is, we want to help them understand the benefits of each option, then allow them to make that decision for themselves.

Related Engineering at Pluralsight Statements

“We support teams in choosing the way they work which might include mob programming, paired programming, and pull request workflows.”

“Teams choose how to address problems within their domain and problem space.”

Checkout our Engineering at Pluralsight document to see all of the statements that shape our engineering culture.