Enabling Coevolution of Organisational & Technical Boundaries

As your engineering teams understand more about the problem domain, and as product strategy evolves, the boundaries of your teams and technical architecture should evolve accordingly to maximise customer responsiveness.

Autonomous teams are the key to minimising lead times. But new domain insights or changes to business goals may introduce dependencies that suddenly remove team autonomy or accentuate deficiencies.

New insights may indicate the skill sets in teams should change, the size of teams should change, or even the product ownership and the technical components they own should change in order to maintain or improve autonomy.

But when teams are autonomous and working independently, how is it possible to generate these insights that require a joined up understanding of one or more teams? And even when the insights are uncovered, how can multiple teams be coordinated to reshape their boundaries?

These are the two most popular questions I have been receiving since the previous blog posts in this series and my recent talk at Domain-Driven Design Europe. So in this post, I’ll show why I believe high alignment between teams is the answer. And I’ll show you some of my favourite practices for achieving it involving:

• High Alignment via Shared Vision of Business Strategy
• High Alignment via Cross-team Transparency
• High Alignment via Cross-team Pollination

Autonomy Criteria Changes Over Time

High performing organisations I’ve worked with and spoken to have highly autonomous teams.

Teams own things that change together for business reasons — each team has the ownership to make product and technical decisions without depending on other teams. This minimisation of dependencies enables faster decision making. It is key to maximising customer responsiveness

I refer to these groupings as Autonomy Contexts: logical boundaries that encapsulate full ownership of product/business capabilities, a single cross-functional team, and full ownership of all technical components needed to deliver those capabilities.

Autonomy Contexts via my talk Aligning Organisational and Technical Boundaries for Team Autonomy

In an ideal world, every unit of work that adds value for customers is owned by a single Autonomy Context.

Boundaries for Autonomy Contexts are identified using a range of criteria, from Domain-Driven Design to the flow of work through the system. But over time, the criteria for autonomy can change or organisations may realise they can improve autonomy.

“I consider it a mistaken assumption… that alignment and autonomy are at odds with each other… alignment enables autonomy” — Henrik Kniberg

As demonstrated in my previous post, when conditions changed, certain teams suddenly became bottlenecks. The government agency realised their teams would have greater autonomy and better customer responsiveness if the Case Management system were now broken down into smaller pieces and redistributed among existing Autonomy Contexts.

High alignment helps you to build an organisational culture capable of continually generating cross-team insights like this one, and a culture that enables coevolution of organisational and technical boundaries accordingly.

High Alignment via Shared Vision of Business Strategy

Organisations have goals. Every decision everyone in an organisation takes should help better achieve one or more of the goals. Shaping organisational and technical boundaries has a huge impact on many of an organisation’s most important goals.

Therefore, everyone who is making organisational, product, or technical decisions needs a clear vision of the organisations goals.

I’ve seen and heard of hundreds of novel ways for creating a shared vision of business goals. Here are some of my recommendations.

Business Model Canvas (and other canvases)

A business model represents the essential assumptions of how an organisation will become successful. For example, it expresses who customers are and what demands they must have for a business model to be profitable.

Every single person making decisions that contribute towards an organisation’s goal should know its business model — especially IT people. Creating a Business Model Canvas(es) is the perfect way to satisfy this need.

My favourite part — teams demoing their Business Model Canvases during my Business Model Canvas workshop at DDD EU 2017

A Business Model Canvas provides many high-value clues about the optimal organisational and technical boundaries in an organisation. Maybe you should align teams with specific customer segments. Maybe you should put a boundary around key activities so less important activities do not pull resources away from them.

To get started with the Business Model Canvas you should read Business Model Generation and then start running workshops.

There are many other kinds of canvas you can use too, from the Product Strategy Canvas to the Mission Model Canvas. What is important is a clear shared vision of what matters most to the success of the organisation. And it has to be easily accessible to everyone.

Spotify’s Company Bets Spreadsheet

Henrik Kniberg talks about an approach they use at Spotify called the Company Bets Board — a Google docs spreadsheet — a low-tech, prioritised list of the most important initiatives in the organisation. It also shows key information: who is working on each bet, what are the success metrics, etc.

Anyone can access the Company Bets Board at any time in just 1 or 2 mouse clicks.

“A bet is like a project/coordinated effort… we make them very, very, very visble… they function as an alignment piont… we show them on the Company Bets board” — Henrik Kniberg, Lean Kanban France 2016

I love this idea for its simplicity and effectiveness. Henrik says “it’s pretty simple strategy stuff”. And it should be for every organisation.

When everyone understands what the organisation’s goals are, what it’s product strategy is, and what success looks like — not just for their own team — strategic, cross-team thinking is possible leading to more effective Autonomy Contexts.

High Alignment via Cross-team Transparency

It’s important for each delivery team to keep fully upto date with teams working in a similar area of the business to them to understand their priorities and the value of what others are working on. Value and priority of work can be a trigger for re-allocating responsibilities or people.

High performance is not simply keeping existing teams busy. High performance means delivering the most valuable outcomes that help an organisation better achieve its goal — often that competes with the priorities of a single team.

Feedback on boundaries can also arise from bottom-up technical insights. For instance, a team may see other teams modelling the same concepts in their code, or having difficulty implementing a particular use case. This type of modelling insight indicates the Autonomy Context boundaries can potentially be improved.

There are a number of practices organisations use to surface cross-team organisational and technical insights.

End of Iteration Show and Tell

My favourite approach to providing visibility across teams is the end-of-iteration show and tell. This is an effective way to not only provide visibility across delivery teams but to also engage wider parts of the organisation.

During my time in the UK government, we did show and tells every two weeks, sometimes every week. We found a winning formula that was unbelievably useful.

In true GDS style, we started every show and tell with user needs; what problems are we solving for UK citizens. Our user researcher would be first up, demoing actual key insights with videos of citizens interacting with the latest version of our product or a prototype (we used an approach called dual-track agile).

Then we moved down to priorities, technical implementation and finally looking into the future.

We were working in a complex problem domain, building brand new services for UK citizens; the responsibility and ownership of each team was very fluid for a while. We had revelations almost every week.

It was both the focus on priorities — every team knew what every other team was working, and the technical demos, that facilitated the top-down organisational and bottom-up technical insights.

If you’re not doing regular show and tells, start now.

High Alignment via Cross-team Pollination

To truly understand what other teams are working on, it’s beneficial for detailed information to flow between teams. The kind of information not easily shared in a demo session.

There are a number of approaches organisations use to cross-pollinate teams. My favourites involve cross-team and cross-functional pairing.

Cross-team Pairing

Cross-team pairing involves a software developer from one team going for a little holiday to another team for a few days to pair program and soak up lots of knowledge.

This allows each team to build a deeper understanding of the responsibilities, both product and technical, of other teams.

Subsequently, with people having detailed knowledge of multiple Autonomy Contexts, there is the possibility to generate invaluable insights capable of improving organisational and technical boundaries.

Cross-functional Pairing

The boundaries of Autonomy Contexts can be influenced by business or technical insights. Sometimes those influences may clash. Therefore, help business minded people understand technological concerns and vice versa to enable pragmatic decision making rather than conflict.

Cross-functional pairing is an interesting way to solve this problem. It can involve product people working on programming activities, or software developers working in marketing.

I’ve had the opportunity to officially try cross-functional pairing just a handful of times. Unfortunately, managers seem reluctant to allow this to happen. In my experience, the benefits are huge, though.

My advice to you is don’t seek permission — just do it. Ask a product manager if you can work with them for a few hours. Go over to the marketing department for a quick chat. Ask them some questions about what they are working on and *accidentally* spend the next two hours with them.

Equally, invite some sales reps or product people to come and code with you for an hour. Remember to make Sales people turn their phone off, though.