Optimising the interactions of dispersed Agile software development teams

How can you optimise the human-to-human interactions of your dispersed Agile software development teams? Over the last few years I’ve been exploring and experimenting, and it seems that these kinds of teams are where my work can make the most difference.

The impact tends to be obvious quite quickly. Information flows more easily. People develop stronger relationships. Misunderstandings are reduced.

That’s both within the team, and beyond it. Interactions with colleagues, customers, bosses and others just work better.

There’s real, even measurable, value in optimising those interactions. As Liz Keogh pointed out at London Lean Kanban Days  recently, all “value chains” are actually made of people. Handoffs between those people can either be a source of “waste“… or a great opportunity to make things better.

That’s not to say that the process of introducing Collaboration Dynamics (or its underpinning technology, Clean Language) is like waving a magic wand. It isn’t. It can be seriously challenging, both for individuals and for organisations.

How it works, where it works

Collaboration Dynamics works because it helps people to develop 3 core collaboration competencies:

  • paying attention
  • directing attention
  • speaking up about their own opinions, ideas, thoughts, feelings and experiences.

In the process, it helps a team to create a micro-climate where doing these three things becomes straightforward. That’s brilliant when the team is geographically dispersed – team members can say what they need to say, even in a phone or video conference, on Slack or on email, and know that they will be heard and acknowledged. Colleagues will ask questions to get clarity.

When connected teams go through a similar process, or even just pick up some of the same practices, the micro-climate starts to spread.

That spread seems to be faster in departments where Lean/Agile has been adopted more fully – which makes sense because in these places, solid processes are in place to continuously inspect and adapt how people work together.

More hierarchical working environments tend to be slower to adopt any helpful new practice, and may continue with unhelpful ones for a long time. Here, speaking up about opinions, ideas, thoughts, feelings and experiences is often known to be career-limiting. The micro-climate fizzles and dies.

Of course, many people in the Agile software development world are already great at human-to-human interactions: stereotypically, these are the “Agile coaches”. Others know that those interactions are especially challenging for them: stereotypically, the devs who’d rather “talk” to computers than people.

Surprisingly, it’s both of these groups who tend to get excited by what I do. Less so the people in the middle.

I think the reason is that learning and using Clean Language exposes essential parts of the structure of those human-to-human interactions to inspection. It’s like seeing the internal workings of a clock, or an engine. “Wow, that’s how it works!”

Once you can see the mechanism, it’s possible to tweak it. That means you can do things you wouldn’t otherwise do. And you can feel confident to try things out, to iterate, to inspect and adapt.

What might change, and what won’t

And then what? Well, what would you like to have happen?

Which are the interactions where you’d like something different to happen?

Where would it be useful to get greater clarity about what people really mean by what they say?

Change depends on people actually using what they’ve learned, of course. That often requires encouragement by active champions within the department, asking, “Why not use it here? Or there?”

What Collaboration Dynamics won’t do is remove conflict and disagreement from your teams or your organisation.

You really don’t want to do that! All the research suggests that conflict is an essential part of developing an effective team, and of creative collaboration. Stifle it, and you put out the fire of creativity that could lead to a big breakthrough.

What it does do in this context is provide an structured mechanism for understanding the roots of conflict, enabling people to engage with what’s going on without being overwhelmed by emotions. It helps people to separate out their own “stuff” from other peoples’, reducing blame and encouraging honest, transparent discussion of the issues at hand.

Another thing it won’t do is reduce the complexity of your fast-changing business environment. It won’t make it simple! What it provides is a helpful approach to working with people in complex environments. A mechanism for probing which tends to be pretty safe-to-fail, and which improves your ability to sense what’s going on.

The process

Teams typically pick up the basics in a couple of days’ training, or the equivalent amount of time in shorter online video workshops. A training process shorter than this tends to disrupt existing ways of working without embedding lasting benefits.

Want to try it? Contact me for details.

1 thought on “Optimising the interactions of dispersed Agile software development teams”

  1. “– team members can say what they need to say, even in a phone or video conference, on Slack or on email, and know that they will be heard and acknowledged. Colleagues will ask questions to get clarity.”

    This seems so simple, yet is so often lacking. And as you say, this technique gets people talking about what is really going on, instead of how individuals interpret what is going on, so that they can get down to working on the real problem and finding the solutions necessary. Great.

Leave a Comment

Your email address will not be published. Required fields are marked *