Continuous Integration of People: Teamwork Is The Work

You probably don’t think about your team as a piece of software, but there are plenty of parallels. A great team is one in which everyone works together seamlessly and intuitively. We grow and augment each other’s productivity and performance. We get stuff done together. Doesn’t that sound a bit like the perfect software application? When you find a great app, it tells you something about the team that created it.

Jim McCarthy says, “team equals product.” He means that the quality of the team – including how it is structured and organized – is clearly reflected in the product the team creates, as well as in the product’s overall design and development plan. And a variation of Conway’s Law is that the ease with which the different software modules communicate with each other mimics the ease with which the people who build it communicate with each other. Want an awesome product that people love? Then you want an awesome team.

Continuous integration

The idea of continuous integration comes from the work of Kent Beck on Extreme Programming (XP), back at the end of the previous century. It’s about breaking down the deliverables into the smallest possible chunks and checking for fit at every stage of product development – so each time a new piece of code is written, it is immediately compiled, integrated, and tested with the rest of the application. It lets you identify problems and fix them in the shortest time and with minimal disruption. You set it up so that as soon each developer commits a piece of code, it’s pushed to the repository, and the CI system compiles it, runs it, and tests it. If anything breaks – well then, because it was a small code change, it’s a minor thing to roll back and fix.

When the build breaks – or, as we like to say, when the build goes “red” – the whole team stops and helps fix before moving forward on anything else. We make sure the build goes back to “green.” This idea originally comes from car manufacturing: a red light would go on in the production line where there was a fault, so everyone could see it, focus on it, and fix it.

With the build always green – integrated and functioning properly – the product is perpetually in a nearly-shippable state. Each developer’s code is added so systematically and effectively that they never have the potential to do major damage or require a significant rollback. The code they write is continuously integrated.

Consider the alternative: people doing extensive work on large batches of code that they don’t feel psychologically safe to share regularly, or they want to feel greater ownership for bigger chunks of the product. Then when they build and test it, something goes majorly wrong and undoes the work of other people, taking days, weeks, or months to fix, perhaps moving the product as a whole backward.

Even a small divergence can become a big problem.

A dis-integrated product is never a good one.

People can integrate – or the opposite can happen

In any human interaction, disintegration or disconnection can occur. Unless all parties are committed to fixing the even the tiniest problems the moment they occur, it’s easy to get way off track, fast.

Something like this happened recently to my favorite team: my wife Molly and me. We were walking to yoga class together, which is usually a relaxing fun activity. But we began the one-mile walk from slightly different mindsets. I like to leave the house 30 minutes before class. That gives me time to change my clothes, put my mat down, and take some time to settle in. I’m at my best when I arrive a bit early. Molly doesn’t need that extra time. She just rolls out her mat, and she’s ready.

So we left the house with plenty of time, from her perspective, but for me, we were already 10 minutes late. She wasn’t ready to leave the house at my version of “on time,” and she wasn’t late for her version of “on time.” She walked at a relaxed pace and fell behind my forced march. I paused so she could catch up, and she fell behind again. We were both agitated with each other, and I arrived for the class in a very non-yogic frame of mind.

Perhaps if there had been a big red light going off over my head, it would have been more obvious. We could have gotten things back on track much earlier in the journey with a quick check-in around our shared expectations and feelings. Perhaps if I had paid attention to how I was feeling and expressed it clearly and early, before working myself up into a furious state of irritation… Perhaps if I had considered the (not so) earth-shattering implications of being five minutes late to a yoga class against the more lasting impact on my domestic harmony, then things would have turned out differently.

What if I had checked our joint state of connectedness – like before it was time to leave the house – and made sure we were both on the same page and emotionally integrated?

Continuous integration of people on teams

When we work together in groups, the Core Protocols give us an excellent tool for sharing our emotional state. We don’t have to fall back on the telepathy we seem to demand in our relationships with others. We “check-in” by sharing our emotions at the beginning of the day or the start of a meeting so that we can all take each other’s moods and present feelings into account going forward.

As we move forward through the meeting or the day, our emotions might change. And while some of that might be visible in our actions and body language, we can’t assume others are going to interpret it accurately. So if we want genuinely great integration and performance together, a state of team flow, then we need to check-in more regularly, and, in particular, whenever our emotional state changes.

So if I was having a really great day until I received an email that completely annoyed and upset me, then – to stay checked-in and integrated with my team – I should share that information. Not necessarily the details of the email, but the fact that its arrival means I am distracted and frustrated and no longer going to respond to their communications and needs in the same way for the time being.

Perhaps they’ll even be able to help me fix it. And if it’s impacting our work in any noticeable way, then that would the best use of everyone’s time.

Of course, I need to feel safe and trusting with my team, so I can share with them that something amazing or terrible or exciting just happened in my life. If we have adopted the Core Protocols as our team operating system, I owe them this disclosure (the alternative being to check myself out for a while and deal with it on my own, which I have every right to do).

And because under the Protocols we all share responsibility for keeping that green light turned on, then my team members can Investigate or Intention Check me if I suddenly start acting in a way that doesn’t match my earlier check-in.

Staying integrated and on track

The main thing is, it’s far easier to course-correct early and quickly, before anything becomes a big deal. A well-integrated team is unlikely to have to have a full-blown glaring red light disintegration. On a well-integrated team, a quick “Hey, what’s up?” early on might suffice. It’s as if you were in a spaceship shooting for the moon, and your initial bearing was off by a degree and a half. You can quickly get back on track with a small maneuver early in the voyage. But if you veer off course for too long, it’s a big deal, wasting lots of time and energy to get back on course.

Staying in the green means sharing accountability for each incremental outcome, for prioritizing the continuous integration of us as teammates ahead of our individual tasks and milestones, and for a collective approach to quickly fixing small things before they have a chance to get out of control.

How are you and your team doing at continuous integration?