Dependency trading with a handshake

Microservice architecture makes it easier for multiple teams to work upon a shared tech platform – and that’s making large, multi-team programmes increasingly viable within many organisations.

But while microservice architecture can reduce dependencies, it can’t eliminate them altogether – it’s still important for teams to know what their counterparts are up to.

My EE colleague Andy Kemp recently shared one approach to working with multiple teams, by running the platform as a club – it’s a great philosophy for approaching multi-team work.

For me, it comes down to encouraging face-to-face interaction – moving away from an old-school, top-down management approach in favour of something closer to the way humans naturally exchange information. You see this happening naturally within teams – as the members agree their working practices, they form their own social contract, and it ties the team together as a single working unit.

Take the conversation beyond your team

Extending the social contract beyond your team is equally vital. It just takes a little organisation upfront. We had great success with this on one government programme, by holding a dependency trading workshop.

Every team working on the programme took part in the workshop, and was given a space to  display their project plan. Teams would then send a representative to visit all the other teams, get some information on their plan, and flag up any dependencies (with a good old-fashioned Post-It).

Once a dependency was spotted, the host team could discuss how to deal with it and come to a joint decision; the representatives would shake hands on what was agreed.

The value this session provided is hard to overstate. It meant that teams had a shared understanding of what was happening, and in one case highlighted a misunderstanding that would have caused major problems, had it not been spotted early.

Of course, everything was still documented (in this case, using Jira), but running a session like this helped us make sure that important information wasn’t locked away, out of sight. It also provided that vital sense of social contract – helping teams stick to their obligations and resolve any dependencies or blockers more quickly.

Perhaps the most important thing? As mentioned, this approach helped us spot (and solve) potential issues before they ever became a problem. By taking one day to focus on dependencies when you can make plans to accommodate them can save you many, many days of unnecessary work. Time well spent.