pairon

Pair Programming: Looking from the Outside-In

Last week I learned more about Pair Programming than I gained from all my previous years of working with developers. (As a Business Analyst, I have never paired for a significant amount of time, but I think I’ll be forcing that issue soon!) My team had an hour-long discussion about pair programming that filled me with new insights. Here’s a summary of my notes so you can gain some insight into this engineering practice.

Project Background: ThoughtWorks was hired to develop a set of branded websites for our Client. The team was a mix of ThoughtWorkers and Client developers, analysts, and project management. The first few months were pretty rough with a scope significantly bigger than the timeline. Worse, while we thought we could avoid the 15-year old legacy code and a myriad of systems, we couldn’t and it added significant roadblocks. The result is we struggled for a couple months in the middle of the project. We turned things around and were very happy with the end product, which was due to go live in two weeks. Except the project was cancelled!

The team history — struggling against the seemingly insurmountable scope and environment, turning the project around, and the sudden cancellation (for business reasons, nothing to do with the project itself) — built the environment for very open and honest discussions. Of the 25+ people on the project, almost 15 of us met to talk about Pair Programming. Most of the folks were developers, split evenly between the Client and ThoughtWorks. The Client developers were new to paired programming when they started with this project. Their total experience with pairing ranged from 1-7 months. The final third of the audience was spread among QA, BA, an iteration manager (think Scrum Master), and a Client program manager.

I kicked off the meeting by asking the Client devs if they had experience with paired programming before this, what they liked, and didn’t like about the experience. Starting off positive, they really liked the knowledge sharing and the cross-pollination of new ideas and information.

A month later I was exhausted, but I was completely on board.

Then we got honest and they said it was really awkward at first. “Do I touch the keyboard? Do I not touch the keyboard? I was pointing at the screen with my finger and the other person said they couldn’t see what I was pointing at.” Quickly, another Client dev jumped in and said, “It was intimidating. I don’t like to look stupid. When I work on my own it’s a process of doing stupid stuff, it doesn’t work, doing stupid stuff, it doesn’t work, and finally one day it works. It [paired programming] is like a test.”

“I thought the math meant we could do double,” said a third Client dev. “I was not on board and a month later I was exhausted, but I was completely on board. I would not go away from paired programming at all. You have fixed 10 things without even typing anything because you’re pair is catching things.” After a bit more discussion he came back and finished with, “It’s a different math, but I think the speed is double. It’s more efficient. When you’re with a pair, then you are not checking emails, you are not on YouTube. You are not doing any of that. You have almost no waste of time. It’s quite exhausting.”

From one of the ThoughtWorks devs with less than 2-years experience, the comment came “I learned paired programming and when I write code on my own it seems so much slower. If I could sit down with someone I could talk to it would go much faster.”

ThoughtWorks’ technical lead for the project had some interesting comments on using pair programming. For him, the largest benefits were for the project, not the particular piece of code developers were working on. “The only way to keep everyone marching to the same drumbeat is pairing and rotation. It only works when you have to work with everyone else. I’ve never found any other mechanism for keeping standards on a team.” Everyone was on board with the idea paired programming is about optimizing for the team, not the individual. Reinforcing this point, there are studies pointing to conditions where pairing is less effective, particularly on simple tasks and novice-novice pairing without enough mentoring.

Beyond the general statements about pairing, the team also discussed the best techniques for pairing. One Client dev said, “I found myself doing better where there was only 1 keyboard and we had to pass it back and forth.” They found it’s more engaging when you’re driving. And everyone agreed it is up to the more experienced of the pair to make the other person type.

There is no doubt the confidence of pairing developers is higher than those who work solo. This comes out in a couple ways. First, when giving a daily update on your progress that has been stalled by a bottleneck, it takes the pressure off when you can say, “We’re working on it.” Second, when you’re  in an environment with siloed knowledge, after pairing for a couple days you are willing to say “I’ll try working on that.” On the other hand, if there’s a bottleneck and the key resource is out of the office, the tendency is to look the other way. The devs do not volunteer to help and everyone has to wait for the expert to come back.

The QA lead for the team said he didn’t track the numbers to prove it, but there was a better chance of the story passing a desk check. There is a lower chance of passing the desk check if just one person worked on the functionality.

The conversation went on for a bit more, covering topics such as pair switching, optimizing space and environments, gold plating, and even introduced new ideas like the Ping Pong Pattern. (Did you know using this method in some programming languages may result in switching every 60 seconds?!)

The evening after this meeting I read The Shame of Pair Programming, by Tom Howlett. It’s a great, short read about how bad pairing can be demoralizing. It’s takes both vulnerability and strength. I didn’t see where our team suffered this problem, but it’s something to be watched for. As we talked about in our meeting, it’s not about being an introvert or extrovert, it’s about you. You need to learn how to speak within the pair.

This project was quite the ride. And despite not going live, the closing retrospectives made this one of my favorite projects ever. I feel like I learned more from our ending conversations than on some of my much more successful engagements. Please, continue my learning by adding yours. Add your comments on how paired programming worked for you. This way I, and everyone else, can learn a bit more.

super duper fast domain modelling

Don’t blame me for the extra “l” in “modelling,” Chris Matts came up with the title and he’s from the UK. They claim to know the “mother tongue” better than we do in the states, but they sure do get a bunch of things wrong!

Okay, enough jesting. Chris and I presented Super duper fast domain modelling at Agile 2013. It was a verbal walk-through and workshop based on the article by Chris and Kent McDonald, The Seven Information Smells of Domain Modelling.

The presentation went well. It went even better considering we only met 2 days previous. Well, we met online and talked over the phone, but we met face-to-face  only at the conference.

Please leave your comment on our slides or the talk below.

book jacket

Read “Discover to Deliver”

In Discover to Deliver: Agile Product Planning & Analysis, Ellen Gottesdiener (author of The Software Requirements Memory Jogger and Requirements by Collaboration) and Mary Gorman tackle one of the largest problems facing Agile and Scrum software projects, how to successfully integrate the ideas and tools made so popular over the last decade into working, valuable solutions.

dealwithit

Is Agile Just for Developers?

Are you a scrum master, coordinating with another team? You might be told, “Why isn’t that done? It should be ready by now.” 

Are you a business analyst, talking about a change that doesn’t impact today’s stories? You might be told, “Don’t mention it during the stand-up meeting.” 

Are you QA, trying to determine if this is a bug or not? You might be told, “Don’t you see the developers are busy? Why did you interrupt them while they were coding?”

And so on.

It’s an epidemic. Agile developers treat their non-dev teammates as part of their personal fiefdom, there to serve. Preferably quietly, so you don’t interrupt their thinking while they are developing. And woe unto those who are not present when called upon.

Developers are the gravitational center of the team. Everyone and everything revolves around them. For the last 5 years I’ve been saying, “Agile is methodology by developers, for developers.” I’ve been watching this behavior for years. It’s irritated me for years. But is it wrong? Should developers be the center of a team’s universe?

Picture of Andromeda Galaxy taken by Hubble Telescope

 

Where’s the value? 

First, we need to agree on a basic metric. The only time software is valuable is after it has been delivered to the users. Software sitting in on personal workstation doesn’t add value to a business or consumer. Software waiting for the next release cycle isn’t providing anyone any value. It might be “done,” but it’s not giving anyone any benefits until it’s used.

I’m a business analyst. It’s incredibly important to understand the business goals when you’re building software. A good scope document doesn’t add value. Detailed specifications don’t add value. Designs and tests and servers do not add value, either. Only working software—working in the hands of users—has a chance to deliver value.

 

Theory of Constraints (link)

If working software is the primary measure of how we add value (See Agile Manifesto Principles), then we need to organize the software development process to get more software out the door. How do we do that?

Eliyahu Goldratt, a physicist who became a management guru, noticed manufacturing lines were organized to maximize the use of all the machines. This was making accountants happy, but it caused problems with extra work, waste, and a growing warehouse full of partially completed products. Goldratt determined manufacturers can make more money by organizing their production lines for consistent throughput around the bottlenecks (constraints).

The same problems, and solution, affect software development. Agile provides a set of tools for software projects, optimizing for the bottleneck, developers. Keeping developers focused leads to a more productive team. Optimizing for developer throughput (for example, having BAs and QAs nearby to answer their questions) means working software is delivered sooner. Optimizing for developers means you increase the chance real value will be delivered. Because the real value of software comes only after it’s delivered, it makes sense to be organized around developers.

 

What about other bottlenecks? 

The truth is, processes have more than one bottleneck. After you optimize for the first bottleneck, you need to be ready to discover the next one. It takes diligent focus to watch the process and work on the next bottleneck. You cannot stop at the first one; bottlenecks are everywhere and you need to continue to watch and optimize.

Developers, because of their role, have a huge number of bottlenecks. They need the right level of requirements, properly configured workstations, the right tools, a good environment for checking in their code, time to understand the technology stack, available test systems and data bases, automated tests, and so on. If you are on a project long enough, you may find this list whittled down. I have never seen it eradicated, but I have seen it get pretty small.

 

What’s right?

Unfortunately, and I think this was part of my ongoing frustration, teams are not good at optimizing for other parts of the process. I’ve been parts of teams where the biggest bottleneck isn’t with supporting the developers, it’s with the testing or requirements supporting development. It’s not that teams cannot say, “I see you need help over there.” Rather, they seem to acknowledge the problem and then think it will go away.

Agile is right. Organizing your team for consistent throughput of working software provides the most value to customers. Supporting developers leads to better software, quicker. It’s the teams that are failing the process. When your team has a problem, discuss it. Work on it. Eliminate it.

Agile isn’t just for developers, but it will be if you don’t pay attention.

 

Do you agree, is this the right way to develop software?
Do you think it’s a problem? Why? Please leave your comment below.