Design Pairing: Can two designers really share a screen?

Friday, May 24, 2013

This post is pair-authored by David Friermor and Nina Mehta

Traditionally, pairing has benefited both pivots and clients improving productivity and quality of output. We want to see if design pairing is a way to move creative, collaborative work forward. We define design pairing as when two designers, work with two mice, two keywords, two displays but only working off one computer. We paired all this week and want to share our reflections with the community.

This week we did remote user testing, script writing, card sorting, sketching, wireframing prototyping and some visual design. Because we worked in a pair, we had more fruitful research findings and came to a better site architecture for our current project.

What’s awesome

We found that the quality of what we produced was higher and done faster than if we worked in silos and came together just for reviews or critiques. By working in pairs, we were able to share processes, skills and techniques to find the best answers of the design problems we were facing.

Pairing also allowed us to put our work through a rigorous process and have focused discussions as decisions were made. Real-time critique makes our work better and let us execute and build upon ideas as we were having them.

What’s hard

Design etiquette and pairing etiquette is already difficult; combining the two is no walk in the park. Letting go of control is hard. Letting go of your keyboard, your ideas, and your chance to say something is all hard. And especially when you don’t want to.

Design is traditionally an internal process; it’s difficult to discuss and explain every thought. We are trained to defend our ideas and refine a thought before sharing it. Getting into each others’ minds at first was uncomfortable and made us feel vulnerable. Once we got over the first hurdle teaching each other what we knew became fun and made our work better.

Well, now what?

We only paired for a week and feel like we’re stepping into somewhat uncharted territory. We recognize that design pairing is not feasible for every project, however we want to see what this can do for other product designers.

Do you have experience design pairng? Tell us about your experience.

Procrastination, considered.

Andrew Bruce

Sunday, May 5, 2013

Last week I blogged about a new project for aiding in the hunt for test pollution, Scrubber. This is a personal side project that I began recently. It’s in the very early stages, like many of my other pet projects. It’s something I’ve worked on entirely alone, though I’d also love to collaborate with others and/or pair on it.

I was going to blog this week about the latest improvements I’d made to the code, and how it was going to improve the end-user’s experience despite being a mere refactor and a minor user interface tweak. I got bored after writing the first few paragraphs, and instead got distracted by the code, refactoring and tweaking it more than was necessary. A couple of hours in, I’d totally gold-plated the code in a way that I might have deemed unacceptable whilst on client time. This made me a little angry with myself: why was I procrastinating from blogging, and was I a bad developer who’d lost the ability to work alone?

Something we’re encouraged to do at Pivotal Labs is reflect on our behavior. Thinking about my boredom and procrastination a little, I realized there was something more interesting going on. The process went a bit like this:

Start blogging about the new features. Paste the visual output of the program into the blog post. Realize that the output didn’t meet the requirement of improving the user experience.
Start to implement the missing parts of the feature. Spend hours enjoying the freedom to refactor, delete and re-implement with no time limit, far more than when pairing on client time.

When we pair, we have a safety net to catch us when we get distracted by neat language features or elegant implementation tricks. Our partner will often remind us that we’ve spent, say, two hours making no discernible feature changes and no improvement to maintainability of the code. When soloing, however, especially on pet projects, we are free to choose a goal for the activity. Sometimes we decide to perform code katas, but other times we don’t consciously choose a goal: the goal could become apparent during the activity itself.

So it seemed that I’d accidentally found validation in what I was doing, and a potentially more interesting blog post at the same time. I’d managed to get some programming exercise in instead of banging out a not-quite-earth-shattering new feature. Specifically, I:

Thought like a user until it became obvious that changes were still needed. Switched to developer mode by accident.
Allowed myself to try out several approaches to the Presenter pattern, applying them to a trivial example that would not need a presenter in ‘real world’ programming.
Used the Introduce Null Object refactor in a situation that didn’t call for it. Yet, it felt good and might even prove useful for the project later.
Practiced several coding techniques that might become useful in the work environment.
Temporarily inverted my work-based insecurities about performance and timeliness, providing stress relief as an unexpected benefit of my brain switching itself off from the task at hand.

Reflection is a useful technique for improving well-being. Your mileage may vary. If you’d have preferred to read about the changes made to Scrubber this week, you can read the commit history!

Pairing like a Pivot

Luan Santos

Friday, April 26, 2013

Pairing is an amazing activity if you and your pair can do it right, it is one of the things we value most here at Pivotal Labs. It is also one of my favorite aspects of extreme programming since it’s the thing that makes me learn, teach and grow everyday as an engineer.

Being good at it helps you and your pair enjoy the workday, keep motivated and therefore, productive.

During the last months I have learned a lot about pair programming and I am trying to perfect this everyday. I have noticed a couple things that I think can help a person be a better pair.

Continue reading →

Pivotal: Why It Works

Will Read

Thursday, April 26, 2012

My name is Will, I’m 30 years old, and I’m a Pivot. In my three year tenure here at Pivotal Labs, I’ve found that it may be easy to see the parts that make us successful consultants, but that forrest is hard to see for all the trees. Everything from breakfast to keybindings plays a part in making us one of the top software consultancies and the greatest place I have ever worked.

My story starts with breakfast and ends with trust. Each piece plays in to another, and the result is an environment where teams are autonomous, culture and knowledge spread quickly and organically, and communication is never a secondary priority. Our clients see the results in the way which we interact with them to deliver exactly what they need. My coworkers feel it when they realize they control their own destiny and have all the power to make their situation better. You hear it when you listen to pivots like myself or others who appear at conferences across the globe. What we have here is special.

Breakfast – The Most Important Meal of the Day

We have breakfast prepared for us by an outstanding catering staff. It is delicious and you should be jealous if only because it means that there’s one less thing I have to do in the morning. It isn’t just food though, and it isn’t a ploy to eek out more hours from pivots like other companies that might provide dinner in hopes that you don’t leave till midnight. No, breakfast is much deeper than eggs and bacon – it’s a time to cross pollinate, to talk to the pivots who aren’t on your team to share in things both work and non-work related. It also gets us to the office at the same time, which makes it easy to pair together for eight hours, then we all go home together at six, and breakfast leads us right in to our all company standup.

Standup – You’re Not Alone

Yes, the whole body of developers participate in the biggest, most high value standup you’ve ever seen. At pivotal you’re never alone, and company standup is just one of the ways we assure that is always true. When you have hired the best (more on that later), why wouldn’t you want them all to be on every team all the time? Since mitosis of humans hasn’t left science fiction yet, we have to settle for osmosis. We go over who is new or visiting the office, who needs help, and what interesting stuff has come up that might be relevant to other teams. You can read our standup notes right here at pivotallabs.com/blabs. Culture starts here too. Company jokes develop over time as we all gripe about the bumpy release process a particular tool is going through. Company standup also makes it clear that it is okay to not know things. Let me say that again: It is okay to not know something.

Another pivot, Davis Frank, shared an analogy that resonated, but since my Bruce Lee knowledge leaves most wanting, I have adapted it to a much geekier Star Trek take. Being a pivot is akin to being a senior officer on the bridge of the Enterprise. We hire people who will speak up and collaborate, people who will work to make exploration sustainable. We all come to Pivotal Labs with our own expertise like Jordi with his engineering skills, and Beverly the medical doctor, but the very nature of working with startups and our other clients means that we are always going “where no one has gone before” with respect to code, and sometimes the ship’s councilor has to hot wire a tricorder. There is no manual on how to build Twitter or Groupon. Pivotal never gave me the answers to those problems, that’s not how we work. Instead, Pivotal, like Star Fleet, exposed me to a lot of problems all the time and gave me the resources and teams to help me solve them as I encountered them.

Pair Programming – The Trust Builder You’re Already Doing

After company standup and our own team standup, we pair program. That means two people, one computer, all day. It isn’t half as radical as it may seem at first glance. Has anyone at your standups ever asked for help? Did someone then go over and sit with that person at one computer? I suspect they did. Do you do code reviews? Then aren’t you really asking your team to share coding knowledge and culture? Think about it. This is what pairing is all about, we’re just set up to do it a lot more often. And getting back to trust, pairing turns a potentially threatening code review process in to a co-ownership process.

Pairing builds trust in all directions. It builds trust between the pair and the client accepting the user stories because I know that two people have thought about this problem. I also know that any cultural nuances that one pivot has picked up are being shared inline with the other pivot. Pairing builds trust between devs. If you talk about code with someone for eight hours a day you can’t help but understand how he approaches problems. That said, you may not always agree, but at least you understand, and you can have much deeper, more meaningful collaborations when that understanding is in place. Pairing develops trust between the team and the individual because I know that if a feature fails, I am not alone in the failure, and if the feature succeeds, I will have good company to celebrate the success.

Talking about code for an entire work day is hard, I won’t pull any punches there. Think about the last time you were in a long white boarding session. I might have been needed, and possibly energizing, but I bet you also needed to decompress for at least fifteen minutes after. Pairing is like that, so we find other ways to communicate that also happen to feed in to the trust: Test Driving. Write tests first; that way, as your pair, I know what we’re about to work on for the next five to twenty minutes. Writing tests first is a great way to enhance your pair’s understanding of how you’re thinking about a problem and the potential solution. Once you have the test, it has the added benefit of speaking to future devs who might work on this code and communicate what it was meant to do so they can make an informed decision whether you’re available or not. Speaking of which, since we rotate between projects, someone not being there is more than just a possibility, it’s just a matter of time.

Rotate your Pivots Every Six Months or 10,000 Spec Runs

The average pivot is on a project for 3-6 months, some stay longer, some are shorter if their leadership is needed elsewhere, but in general you can count on seeing a good number of projects in three years’ time. On one project you might make a JSON API, and on the next you’re up to your eyeballs in JavaScript, HAML, and CSS. Then it might be off to help a company scale and tune performance. We swap people around and expect them to be adding value on a new project day one. We do that by standardizing on a few things about our workstations. For starters, every computer is basically the same minus the project code itself. Our ops team has done a great job of having an updatable workstation image that is under test so they know when it breaks. After many holy wars, we’ve also come to an arrangement about which IDE and keybindings to use. The choices may not always be “the best” when getting down to specifics, but it is one less hurdle to jump when you find yourself on a new project with new faces, new clients, and new domain – at least your computer feels like the home you just left. It also means I don’t have to think about how to set up a machine when starting a new project, the collective knowledge of Pivotal workstation config is captured in our machine image.

Rotation is a razor sharp double edged sword. Your average dev working for a product company might switch teams once in three years. Meanwhile at Pivotal Labs, I’m seeing new problems and new solutions at a rate 3-6 times that. It means that I can demonstrate loyalty by staying at one company, but the experience of working for ten companies in that same timeframe. Rotation makes our best pivots that much better. The downside of course is that someone who demonstrates loyalty but possesses the experience that is characteristic of a senior pivot soon finds himself being invited to take on lucrative and dazzling roles elsewhere. I can’t begin to explain the sadness and frustration I feel when a pivot leaves the company, but we also can’t afford not to train up our employees. It is the same high quality that makes pivots hirable that brings in the steady stream of clients to Pivotal Labs. If we stunted or slowed that growth any way, it would weaken our offering in a way that would undermine much of what is good about Pivotal Labs.

Hire the Best

We are unwavering when it comes to hiring. When you come in for an interview, you write code on real product because that’s what we’re expecting you to do when you’re here everyday, not solve brain teasers at some white board. We want to know if you can communicate, and we want to know if you can learn and adapt. Pivotal throws pivots in to uncharted waters a lot and we expect pivots to swim. They always do because we hire great swimmers. Hiring great people means we don’t have to spend a lot of time with formal training, or managing, because people are good citizens within the company. Also, hiring great people who raise the average and are put in a place where they pair and rotate means that the average really does go up for everyone. This has an awesome effect on morale, and serves to give us all the confidence that we need to takle new problems. Having the best means that teams can be autonomous and we can trust them to interact directly with the client eight hours a day. We don’t have any need for the “heros” or the “ninjas” who can strap on headphones and have a caffeine-induced flow session. We hire largely for technical aptitude and ability to communicate which is not most developers. When you’ve hired the best for this business, delivering features comes naturally.

Focusing Priorities with Pivotal Tracker

The real magic of Pivotal Labs that you might not notice at first is Pivotal Tracker. It may look like an ordinary project tracking system, but it does two things very well that most software fails to do: 1) Tracker forces clients to prioritize the work we do for them, and 2) it serves as a central communication piece. The former is very important to the success of the project. I’d like to think that because of all the other things we do, we produce more features period, but that’s not the whole picture. Because everything is prioritized, we produce the right features, or at least the features the client wants the most. It is hard for a client to be dissatisfied when we’re always working on the most important thing. We know it is the most important thing because we’ve talked about it. Tracker is the main talking point in our short, weekly meeting so we know that our client wants these features first, we talk about any technical needs we have on our side, and discuss the story details beyond what is typed in Tracker. Remember how I said it all plays in together? Well since we all sit together, and we all trust each other, it greatly reduces the need to spec out every last detail – most of the time we have enough context to make well informed decisions, or we can turn around and ask our client for clarification, or baring that we deliver a story and get some great feedback in the form of a rejected story. At Pivotal, you’d have to work really hard to not deliver what the customer wanted.

Feedback – Always, Everywhere

Being an Agile shop means we’re always gathering feedback and looking for ways to do our job better. Each project is different, so we have regular retrospectives to help us surface and adapt to those differences. This exercise is focused on getting better, and depends on honesty and therefore builds trust in a team. This goes hand-in-hand with hiring the best, because the best speak up and the best aren’t afraid to say something scary or controversial. The best lay their ego aside in order to improve a team, project, or a company. I strongly believe that, if left alone, the right people with retrospectives would arrive at a process that looks a lot like Pivotal Labs does today – in fact I would argue that’s what happened when the idea of Agile was first put to paper by Beck, Fowler and the rest of the Agile work group. Get and give feedback, act on that feedback, that’s the core. Action however, doesn’t always lead to success at first try.

If at First…

In fact, taking action leads to failure a bunch. Since the set of problems, both human and technical is huge and enormously complicated, it is reasonable to assume that most guesses at actions would end in failure. But guess what, we fail, get feedback, take action, and over time, those actions lead to successful actions. Often times the success is very different than it was originally pictured. We also have the benefit of having that experience that can now be applied to a future project. Pivotal Labs is good about making it safe to fail. Read that again, it is safe to fail here. Why? Because we start with the best, then we give them a lot of experience, and we trust them to make the best decision given the information and experience they have. And because we’ve hired for it, teams own their failures, and they’re intrinsically motivated to do better. No one has to sit over their shoulder and tell them it went wrong. They know, and as a matter of pride they’ll fix it. Most importantly, they have the skill set and the resources to fix it.

Greater Than the Sum of its Parts

By now you should be hearing it in your head, that it all feeds in to itself. The whole thing works because it is complete. Each part, start time, pairing, test driving, hiring, clear priorities, and feedback contribute more to the system than just its stand-alone value. The pieces are all obvious, but how they interrelate and build trust across the organization is what makes Pivotal an outstanding company. My name is Will, and this is why I’m a pivot.

If you’re looking for developers, and you want to get the most important things done, I hope you’ll consider becoming one of our clients, we do web and mobile work and you can drop us a line at sales@pivotallabs.com. If this resonated with you and you’re looking for a job as a developer, please send your resume to pivotallabs.com/jobs.

SF Standup 5/4/2011: Tête-à-tête

Mike Grafton

Wednesday, May 4, 2011

Interesting Things

Josh and Alexander are pairing at a new iteration of the tête-à-tête pairing desk, where they’ve hacked (with a bandsaw) a traditional Ikea desk to allow for better ergonomics and pairing dynamics. Expect a blog post with pictures soon.

Extreme Pairing

Pivotal Labs

Tuesday, December 14, 2010

Given the recent interest and discussions around pair programming, I thought that now would be a good time to write up my experiences doing dual-computer, in-person pair programming with Mavenlink at Pivotal Labs. Pivotal Labs is all about pairing and every team here pairs full time. Our standard setup is to have two developers at each workstation, with two mice and keyboards. On Mavenlink, we recently upgraded our workstations and decided to keep the older model around to try out dual-computer pairing, which we’ve nicknamed “Extreme Pairing.”

One commonly-expressed frustration with pair programming is that of wasted time while doing especially rote programming, research, documentation reading, or printout debugging tasks. People read documentation at different speeds, or want to try different Google searches in parallel, for example. Generally, the benefits of pair programming greatly outweigh the downsides, and we pair full-time to decrease the risk of failing to pair when it would retrospectively have been of great value due to knowledge sharing or bug prevention. However, in an effort to minimize these inefficiencies, the Mavenlink team has been exploring dual-computer pairing.

What follows is not Pivotal’s standard pairing setup. Everyone on this team has years of pair-programming experience and we have each developed our own intuition for which corners can be cut and which cannot. The following is recommended for advanced pairs only — it can make experienced pairs more effective, but may be hazardous for newcomers to the pairing environment! We never “Extreme Pair” when conducting interviews and revert to a more traditional setup in that context.

Extreme Pairing

Each of our two pairing desks house a beefy i7 27-inch iMac and a slightly older 24-inch iMac, each with its own mouse and keyboard, and linked bidirectionally with Teleport. We sit centered around the larger iMac and use the second computer when we have separable tasks during pairing, such as research, running tests, or looking up documentation. We still do traditional pairing 90%+ of the time and focus on never falling into the traps of soloing: email checking, distractions, siloed knowledge, and untested code. Having the second computer has allowed us to split our focus when we can do so while still both maintaining understanding and ownership of everything that is going on. This is most effective and appropriate when:

tracking down bugs; we are both able to apply different tactics simultaneously while talking to each other. This allows us to divide and conquer, then rejoin when we’ve made progress in our understanding of the base problem.
looking at docs; we can both read at our own pace and synchronize afterwards.
the non-driving pair can support the driver by setting up the context for an experiment, running rake tasks, etc.
googling and researching
optimizing, one person can track down issues with Query Reviewer or Rack Bug while the other can identify the underlying problems in the source.
browser testing and CSS tweaking in multiple browsers. In particular, we have found running windows in Parallels on the non-primary machine a boon to speed and productivity on the primary machine.
capturing stories in Pivotal Tracker

More generally, any time a task requires focus on two different places at once, we split it up and assist each other. I think of this as synchronization in multi-threaded code – we split and rejoin on separable sub tasks, while both continuing to perform traditional pair programming when viewed from the scope of a story. We never work on separate stories and tasks that last longer then a minute or so. Smoothly moving from traditional pair programming to separately googling, debugging, or CSS tweaking keeps us agile and efficient while maintaining all of the very-real benefits that we find to exist with traditional pair programming,

Does this sound like fun? Mavenlink and Pivotal Labs are hiring!

Git and Pairing Statistics

Pivotal Labs

Thursday, January 7, 2010

At stand-up this past Monday after the whirlwind of the holidays, our team anchor encouraged us to pair with somebody we hadn’t paired with much recently. While this was good advice I really didn’t have a clear idea in my mind of how often I’d been pairing with specific developers on the team.

On our project we use Bryan Helmkamp’s pair script to change our git author name to a pair of developers joined with “and.” Since both developer names are included on a commit in a consistent way, I was able to get a vague idea of with whom I’d been paired over the past couple of weeks with a quick git log | grep Pignata | less but I couldn’t really see any patterns from this output.

To better keep track I threw together a quick script to quickly parse out these results and show me at a glance what my pairing habits have been over the past 30 days. Now I can check every couple of weeks to see if I’ve inadvertently become part of a sticky pair or if there’s a developer I haven’t been pairing with often enough:

 jp@populuxe:~/Projects/lorem(master)$ ./pair-stats Habitasse Platea
 Pairing stats for Habitasse Platea since 2009-12-06

 Developer              Days   Commits  %
 ---------------        ----   -------  ---
 Tincidunt Nec          8      55       33%
 Congue vel Mauris      5      40       20%
 Sed Facilisis          4      21       16%
 Etiam Blandit          3      16       12%
 Solo                   1      2        1%
 ...

You can find the script on GitHub.

What tricks does your team have to ensure proper circulation of developer pairs?