It’s been an incredibly exciting last few weeks at Shutl headquarters as we prepare for our first ever Shutl Tech Blog. (if you’re reading this, it means you’re now sharing in the fruits of that labour).

At the risk of becoming a little too “meta” let’s first give a brief overview of the process of how we came up with our first Blog topics. Our very own Akash set up a brainstorming session where we came up with ideas and voted on the topics that most interested us (in case you were wondering: there were lots of stickies and a whiteboard involved).

Right away, the topic of Pairing became a serious contender for everyone’s favourite topic, so we decided to tackle this in our first few blog posts.

From one post to many

As we got further down the road of exploring this potential post, so many team members expressed interest in the topic that we decided it was time for yet another brainstorming session on how we would tackle this very big subject. What came out of that session was the conclusion that we should dedicate a regular column to the topic of pairing.

The idea here is firstly, to do justice to what we believe is a very important tech practice and secondly, to show you that even within a company where there is an entrenched culture of pairing, there are different perspectives on how to approach it, what we think of it, challenges we face and what we’ve learned. This is our way of demonstrating that we respect these differing viewpoints and we welcome a discussion in the public sphere based on our experiences as individuals and as a team.

Pair Programming vs Pairing

We prefer to use the term Pairing as opposed to Pair Programming. It is more than just developers pairing up. It’s about creating a collaborative, supportive, learning culture across the entire organisation.

Culture

Culture is key at Shutl. The foundation of our practice is based in Agile philosophies and methodology. We don’t view Agile as just “daily standups”, we view it as an all-encompassing practice that involves the whole company. It starts with the development team, continues throughout the organisation and even includes decision-making processes at a business and commercial level.

We believe there are two crucial characteristics of a high performing Agile organisation:

1. Quick feedback throughout the whole system and
2. Independent self-organizing teams.

On a spectrum of long to short feedback loops, our various feedback activities include the following:

• Demos
• Retrospectives
• Product Review
• Standups
• Production Deployments
• Continuous Integration Deployments
• Peer Review
• Test Driven-Development
• Pairing

The first line of defence

We see Pairing as the first line of defence in a series of feedback loops that are designed to keep our quality standards high. We often talk about it in interviews with candidates and based on responses we’ve come to realise that many teams apply only a subset of the aspects that we believe encompass effective pairing.

We find that Pairing is commonly used as an on-demand tool for when someone needs help. We however, see it as a default way of working that affects many aspects of team culture.

This would be a good time to clarify that although this is a common practice at Shutl, we don’t “enforce” it. The practice is adopted by every member of the team because of its efficacy.

Upcoming posts

As mentioned before, to illustrate how important this practice is, we’ve decided to dedicate a series of posts to different perspectives on pairing @ Shutl. You can look forward to reading more about it here.

As a teaser, we’re considering some of the following topics for future posts on pairing:

• • Psychological aspects of pairing

• • Why pairing is fun

• • An introvert’s guide to pairing

• • How you improve as a developer when pairing

• When not to pair

(CC image by Stuart Barr)