Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Two, Four, Six, Eight, How do We Communicate?

When I joined the project, we went from one pair, to two. Today, we’re three pairs, six people strong. But the communication paths now are far more numerous than the one pair days.

It seems like a one pair project has it easy when it comes to knowledge transfer. Of course what it gains in simplicity, it also lacks in variety. That aside, it’s really easy; the client talks to the pair, and only two units need to be on the same page, one client unit, one pair unit.

The growing pain is easily identifiable when jumping to two pairs. Now the two pairs may agree, but the client may be picturing something else. Or maybe only one pair went on the phone call on Tuesday, so the Thursday phone call is different for everyone because they don’t all have the same context.

But it isn’t that hard to put four people on a phone call and have everyone ask enough questions to be heard and to understand. At six, now we’re talking about a lengthy discussion. Coming to a democratic consensus also becomes exponentially harder, let alone getting unanimous support. That’s OK, it is the disagreement that makes us pause just long enough to do the right thing, but it also means someone gets left out.

Going from two to four, then to six also means that you can get more work done, a lot more. How will you feed them this work? With one pair you can easily go day-by-day with just a few story lead time. When you get to three pairs, and each pair is blocked on one story, waiting for a batch job on a second story, and looking at the backlog for a third, you can’t go too long before you find yourself in a full on planning meeting on a very regular basis. Suddenly, keeping the backlog in order and stories teed up to be worked on goes from something you do at the end of the day to a full time job.

What one pair can often accomplish inline with a client, two pairs can do with some structure, but three pairs need to have a sit down and a real opportunity to have open conversations. That is not say, “Three is bad, never go above two pairs.” I’d argue for quite the opposite in fact. Three pairs have helped us flesh out how we really work, brought more areas of improvement to light, and of course, delivered more business value than ever before.

The real point is to say, “Be ready.” Our client knew this from experience, but it can be a hard lesson for a budding start up. You can try to be the head of sales and a project manager of a team of eight, but you’ll soon find yourself likened to “butter spread over too much toast”. As you grow your development team, you can also be prepared to grow your resources dedicated to keeping that team informed, fed with stories to work on, and reviewing the one’s they’ve completed.

Comments
  1. At three pairs you definitely need to start adding a project/iteration manager and a BA to the team, along with a tech lead. Also, part of the problem with the above scenario is the idea that software development should be democratic. I have seen teams try and do this and fail completely because they never come to a decision. On every team, you need to have a recognized leader. Someone who, after listening to the discussion, has the authority to make the final decisions. Ideally, this would be the client, however, this doesn’t always work–the client is unavailable or simply doesn’t understand enough.

    I always liked the expression that no army ever won a war. The same is true for software development.

  2. Will Read says:

    Chris, you’re right about the democratic approach. On our teams here at Pivotal we have an “anchor” who can serve as a single point of contact for the customer if the team is unavailable, and the anchor is typically the final word on what goes. As you alluded, the anchor’s role becomes more significant as the team size grows. At one pair, with one person being the anchor, it doesn’t mean as much as a six person team where a decision maker is required.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *