How did you introduce pair programming at sipgate?

Recently I’ve been presenting our Work Hacks at a couple of places and talking about pairing up as part of it. Not only do we pair program but we also mob program and pair up across roles: Dev and UX designer, PO and customer support, UX and PO, dev and customer support, dev and … You get the idea. We’ve done just about every combination our very cross-functional teams allow for.

Whenever I talk about this, a common follow up question is: “How did you introduce pair programming?” or “How did you make people adopt pair programming?”

Short answer:
We didn’t. Nobody made a concerted effort to establish pair programming at sipgate.

Long answer:
Not long after we started using Scrum it dawned on us that Scrum alone wouldn’t save us. Only combined with sound software engineering practices such as the ones from XP would we be able to improve our codebase.

Sometimes I hear tales by developers from other companies about management not wanting them to pair program or TDD. In our case the opposite was true. Our management was okay with TDD and pair programming. There just weren’t many people interested in doing it.

Fortunately “not many” is more than “nobody”. There were some curious minds and teams who started to try it out.

It worked well for them so they kept doing it and told others about it. And what do you know, just a few short years later (about three or so) the tables had turned and pairing up was the new normal. Now you were the oddball when you didn’t want to pair up.

To this day it depends a lot on the team. Some teams pair up all the time, some mob, some only pair up for critical stuff. All of that is okay.

We all agree that pairing programming leads to fewer defects and better readability. And pairing up across disciplines helps us keep tight feedback loops and to spread knowledge.

PS: Like what you're reading? Join Corinna's Retromat newsletter!

Scaling through Pairing – Menlo #3

[This post is part of a series about Menlo Innovations, the company described in “Joy, Inc.“]

Cover of Joy, Inc. It’s quite common for my colleagues and me to pair. Not just developers, but also UX & dev, PO & UX, Customer Support & PO, … There are many combinations and I usually feel quite smug about our level of pair programming. Until I’ve read how rigorously they do it at Menlo Innovations:

Everyone pairs and they reshuffle the combinations Every Monday. Who pairs with whom is one of their most thought out processes and is assigned by project managers. You only work in your pair. You must not write code while your pair partner is away.

Frankly, to me that feels odd. That some project manager prescribes pairs; that I’m bound to that person and that it will be someone else every week. At sipgate we have stable teams so we always pair with the same few people. And we decide when to pair program and with whom.

Still, what Menlo gains with their rigorous practice is very attractive: The ability to scale. Fast. Up AND down. If they need to bring in more people into a project the existing members are “seeds”. They can all be paired with someone new to the project and effectively double (or half) the (wo)manpower within 1 week. That’s a huge advantage! Plus you avoid the dreaded towers of knowledge that are prevalent nowadays.

We don’t need to be able to scale that quickly because we’re not an agency, but if we were, I’d be reconsidering our pairing approach right about now.

Wall-Skills: Design the Box, Japanese Terms in Lean, User Stories, less +F

Recent 1-pagers on

Is the vision for your product rather fuzzy? Design the box is an awesome technique to bring clarity and focus.

If you’re in a Scrum environment you’ll might encounter Lean at one point. Here’s a vocab cheat sheet: Japanese Terms in Lean

User Stories in a nutshell 1 page

Does your job entail keeping an eye on log files? Try less +F for viewing logs

The NOT operator in Meteor.js (Spacebars, Handlebars)

Because a colleague praised Meteor.js I’m currently working through the tutorial and was stumped by trying to create an “if not” condition. Neither {{#if !myVar}} nor {{#if not myVar}} worked.

Maybe it’s just my inability to google, but I did not find the solution as quickly as I would have expected, so is there a NOT operator in Meteor? Can I negate an if condition?

The answer is “kind of”. You’re probably looking for:

{{#unless myVar}} ... {{/unless}}

unless is the opposite of if

I also learned that Meteor’s templating mechanism is called “Spacebars“, which is derived from “Handlebars.js”. Both know “unless”.

PS: The colleague was completely right about Meteor: It’s awesome! I love it! You should totally try it!

3 Horizons, find, Coaching Cards – 1-Pagers

New 1-pagers on during February 2015:

Are you sometimes stuck as a PO or Scrum master? Geoff Watts created Coaching Cards with questions meant to “unstuck” you. Get a feeling for them here:

But that’s not all, here’s more:

While we’re at it…

There I am, discussing a feature with my colleagues, when one of them says the words of scope creep doom: “While we’re at it, we might as well implement that other feature (that belongs in the same component). It would be foolish not to, as it’s so much work putting that component live.”

I disagreed, as it’s become second nature for me to break features into smaller parts not make them larger; let alone combine 2 features that are unrelated except for the component they’ll reside in. But why was that again? After all, the argument is so convincing: That component is hard to deploy. And the other feature is not that much more work. Oh, so tempting!

Too bad, that in my experience it never plays out that way. Even if it’s really “not that much more work” coding-wise, it usually turns out to be a bad idea for other reasons. Or in the words of my esteemed ex-colleague Stefan:

Don’t forget that the easiest part of software development is coding.

So here are effects of combining features that I’ve seen (not all at the time or for the same features): Continue reading

Code Retreats are awesome!

At least the one I attended on Saturday – My first one.

What is a code retreat, you’re asking?

A bunch of people who want to improve their coding and unit testing skills meet for a day. Everyone has their IDEs and testing frameworks ready to go. You get to tackle the same problem multiple times. We had 7 blocks, each consisting of 45 minutes coding followed by 15 minutes retrospectives. In each coding phase you pair program with someone else. To spice things up, there’s a new constraint for each round, e.g. “No IF-statements allowed”. After each round you throw away the code. Wait, what? Throw code away? *gasp* Heresy!

Why would you do a code retreat?

For deliberate practice. There’s this famous analogy: Musicians spend a lot of time practicing, then give a few concerts. Software developers – who often build something they’ve never build before – spend all of their time “giving the concerts” and hardly ever just practice the basics, let alone with someone else. A code retreat is an opportunity to learn:

  • new ways of thinking / approaching a task from your pairing partner
  • to take really small steps
  • new languages
    (Code retreats are not language specific. I got to code in JavaScript, Java and Ruby. Java was the least common denominator – it works for everyone.)
  • new shortcuts, IDEs, frameworks, …
  • to throw away code Continue reading

Useful links to start TDD / BDD

Test-driven development has a lot to recommend itself:

  • Testable code is usually well structured
  • Specifying tests deepens the understanding of what the code is meant to achieve
  • It makes sure tests are actually written, not omitted in the end (due to time constraints or “Why test? It works!”)

Unfortunately it’s not as easy as it looks at first sight (“Just add some tests, how hard can it be?”). Rather, writing testable code is a whole new skill set in its own right.

Here’s a selection of links I found useful:

  1. Nice intro on why and how to develop test-driven
  2. Great talk on how to design for testability
    (Also check out Miško Hevery’s other talks)
  3. Scope and setup of tests and why “behavior-driven design” is a more accurate name than TDD
    In this article Dan North also proposes the “Given, when, then”-format. This format is great to clearify behavior, even if you don’t use TDD / BDD.
  4. Field report of a developer on how his testing activities changed towards TDD over the years
  5. Why not have a TDD code retreat to kickstart your TDD abilities?

What would you recommend to someone starting out with TDD?