The Agile OWL – Edition 2

‘Two heads are better than one’ is a proverb we see in practice all around us. Be it the world of sports, business or even fine arts and Agile methodologies. Think Larry Page and Sergey Brin, Warren Buffett and Charlie Munger, Christo and Jeanne Claude or Michael Jordan-Scottie Pippen. Amongst Agile methodologies, Extreme Programming (XP) encourages ‘pairs’ as a way of working. In this edition, of the Agile OWL – Edition 2, we carry a story of how pairs work together in Menlo. This was the same firm which has a one-week work-cycle and we featured the experience here.

Stories from the world of Agile
Monday mornings at Menlo:

On a typical Monday morning, an employee at Menlo would come in & check the notice board for their work-partner details. Once the employee finds his/her workstation, he/she would notice two chairs, one computer screen, one keyboard and mouse. The idea is employees will work as pairs and accomplish work. Collaboration is not a choice at Menlo. And if the other partner is late, the employee must wait for the partner. No starting work alone. The two employees work together on the piece of code or work assigned, discussing nuances and details as they work.  

We know this way of working as ‘pair programming’ or ‘programming out-loud’. The person with the keyboard articulates and discusses with the partner, the task, details, and complexity as he/she works on it. This articulation helps identify errors and blind spots and improves quality. The pair switches roles every few minutes, by handing over the keyboard to the other person.

To any traditional manager, having two people working on the same computer and doing the work of one is inefficient. Menlo has instead found their productivity increased by 10 times thanks to pair programming.

History of Pair Programming

Kent Beck created the Agile methodology called Extreme Programming (XP) in 1997. More about it in the trivia section below. He formally introduced the concept Pair Programming in XP. Although experiments of working in pairs have been on since 1945!

The two founders of Menlo Innovations, Richard Sheridan and James Goebel worked as a pair and found it so useful, that they incorporated it as a way of working in the new firm they founded. At Menlo not just software engineers but even staff from Quality, Purchase and at times even Managers work in pairs. This way of working has attracted so much attention in recent times, that Menlo offers this as an experience for a fee.

Advantages & What to watch for in Pair programming:

The advantages of pair programming are many. Here are a few to consider.

  • It discourages ‘towers of knowledge’ in teams. The culture moves away from a few top performers whom the team rallies around, to knowledge available with the entire team.
  • Lesser errors and pairs are more productive than individuals.
  • It is very hard to slack off when you have a pair partner working together all day. Employees are Menlo for instance, say they work harder and longer at Menlo than at any previous job. Hence pairs are encouraged to take regular breaks through the day. They have ‘walkies’ where pairs can take walks around the block.
  • Makes a recent hire more productive, faster. Since recent hires get to pair with more experienced folks on rotation. A recent hire at Menlo is not shocked with working in pairs, because their hiring was through a process called pair interviewing. No personal interview-based hiring process at Menlo. Hires experience pair-working for a 3-week trial period to know if they will like it before joining.

Getting consent of individuals is important because you cannot force people to work in pairs. No diktat from the top management can make pair-working easy, unless accepted by each team member. It also needs a culture and way of working where basic things like individual hygiene, professional behaviours and psychological safety are in place. Pair-working needs alignment with enterprise wide interventions like bonus & performance management rewarding the right behaviours.

Well, if Menlo was a restaurant instead of a software firm, collaboration would be its signature dish. One-week work cycles, pair working and even Extreme pair interviewing would be the ingredients for bringing the signature dish alive.

Here is the round up for this edition of the Agile OWL

From social media:

1. Agile intends to create a less hierarchical way of working. Yet organisations are steeped in hierarchy. A complete overhaul of the organisational structure is tough. Yet is there a way to become less hierarchical within a hierarchical structure. Read more here.

2. Technical debt and is a huge concern area for leaders who want to create Agile systems. What is Technical debt? ‘No technology can do everything. To design a system for a particular purpose, the engineer must make certain choices and trade-offs. Over time these choices have consequences and unwittingly make the system rigid’. Read more here on how to explain technical debt to executives.  

From the bookshelf:

Doing agile right: Transformation without Chaos by Darrell Rigby, Sarah Elk, Steve Berez is a useful book to consider, for coming to grips with organisational agility. The book does not focus on any agile method but rather helps executives consider Agile leadership and how agile do they want to be?

From the trivia & fact box:

The evidence of Extreme Programming ‘s (XP’s) success is highly anecdotal, but impressive. One example of its accomplishment is the sizable Chrysler Comprehensive Compensation system launched in May 1997. After finding significant, initial development problems, Beck and Jeffries restarted this development using XP principles. The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods, (Anderson 1998),

Additionally, programmers at Ford Motor Company, spent four unsuccessful years trying to build the Vehicle Cost and Profit System (VCAPS) using a traditional waterfall methodology. The XP developers successfully implemented that system in less than a year using Extreme Programming (Beck 1999). More details are here

#AgileQuotes to sign off..

 Note : This post is Edition 2 of the Agile OWL from the OWL umbrella. The Agile OWL is a newsletter focused on the human experiences and stories within agile transformations. Sign up to receive the newsletter here

Write a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.