Collaboration

Collaboration is a central tenet of agile software development. It’s an empirical observation that the best solutions to problems involving technology are solutions that emerge from multiple perspectives reflecting on the problem over time — that is, they are inherently collaborative. Even if we believe in “10x programmers,” they’re at best rare, they are focussed on some speciality, and they can’t be everywhere at once. In the end, we rely on building teams who can combine to give the impression of super-human powers, and function as a team, rather than simply acting as individuals. To combine effectively is to collaborate.

Working collaboratively offers these short-term benefits:

  • Articulating your work to someone else forces you to organise previously intuitive understanding and often triggers some rethinking.
  • Consistent collaboration detects individual errors earlier, especially when multiple perspectives and skills are involved.
  • When we have a shared understanding of our work, we can reorganise to work around individual bottlenecks.
  • Some people simply prefer to work in groups.

In the longer term, there’s evidence that safe, gelled, learning teams produce higher levels of innovation (see the work of Amy Edmondson).

It’s not unusual for people to be fine with the idea of collaboration in general, but reluctant to increase the amount of collaboration within their team. Here are a few reasons why this happens.

Some people see collaboration as requiring extra meetings, which taps into a general resistance to meetings. It can help if you ensure that most of your collaborative meetings generate concrete outcomes, and use other channels (email, wikis, posters, etc.) when you need to share information, but compared to working in individual silos there probably will be more meetings in your calendar. If it feels like these aren’t accomplishing anything, consider whether they’re making the team more flexible, generating new ideas, bringing reviews forward in time, or simply helping the team get better at working together. Sometimes outcomes aren’t obvious.

Other people may simply feel that you’re not making as much progress as you were when you worked individually. In this situation, it’s important to make sure you compare apples to apples. How long would it have taken to get to the same level of quality when you were working individually? How many reviews would have been needed, how much rework? How long would it have taken to reach the same level of shared understanding? Are the outcomes actually comparable, or did the collaborative approach actually deliver a better outcome? Also keep in mind that teams get better at collaborating over time, so what might look like decreased efficiency may actually be a transitive investment period.

Last, but by no means least, is that some people simply prefer working alone. We are gradually learning that teams benefit from a wide range of personalities and thinking styles, which can broadly be termed “neurodiversity.” A well-considered collaborative environment creates opportunities for everyone to participate in ways that are suited to them, even including time for individual work. See “The Inclusive Collaboration Experiments” by Sallyann Freudenberg for more helpful information.

Creating a collaborative work environment isn’t a binary act — you don’t simply become fully collaborative one bright, sunny morning. There are plenty of small opportunities to increase the collaboration within your team:

  • Explain the work to someone else before you start (or better yet, explain it to the whole team). Preparing will help you clarify your own thinking, you’ll get insights from other people, and everyone on the team will be better informed of the big picture.
  • Make your work in progress visible to a wider audience. Let people know when you reach a milestone — a new section, a better level of finish, whatever milestones are appropriate to your context. You don’t need to arrange formal reviews to get feedback.
  • If people are accustomed to working in individual silos, you may find it difficult to get them to shift their attention away from their personal work to give you feedback. It’s a transitional problem, and you may need to organise formal reviews to time-box their attention. A formal review doesn’t mean a formal product — the review might be of hand-drawn and photocopied diagrams, or you may sketch directly on a whiteboard. Don’t waste time polishing something that may change.
  • If you’re a programmer, arrange a review of your design before you start coding. As with the previous point, level of polish isn’t important. A “design” may be bullet points, or a hand-drawn sketch, or whatever other low-cost method conveys the meaning. Changing a whiteboard design is way faster and cheaper than changing code.
  • Pair on stuff, especially programming (analysis, design and coding).
  • Whatever you’re doing, arrange a review of your completed work.
  • Treat the computer as a collaborator — some reviews (code coverage, design metrics) can be automated so that humans can focus on the possible problems rather than spreading their attention across the entire code base.
  • Collaborate with humans outside your immediate team — include them in reviews, demonstrate things while you’re working on them, generate frequent, low-cost feedback.

If, as individuals, we were all-knowing and our work was error-free there’d be little value in collaboration (thought it would still improve team flexibility!). At least until the day we achieve those milestones, there’s lots of value in learning to be more collaborative.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.