You probably don’t know me, so let me start with an introduction: I'm Radek, and I’m a Kanban enthusiast. 

No, I’m not talking about just sticking colorful Post-it notes on a board. I’m referring to Kanban as a method for evolutionary change management in knowledge work organizations. So, why am I discussing Kanban on a Team Topologies blog? Because combining the Kanban method with Team Topologies can significantly improve your work life. 

The Underestimated Power of Making Policies Explicit 

One of the core practices of the Kanban method is “Making policies explicit.” 

I know what you’re thinking—“Policies? Explicit? That sounds boring!” But it’s not about bureaucratic rules stored in a forgotten PDF on SharePoint. It’s about clarifying the rules of the game so everyone knows how to achieve their goals together. These policies often extend beyond single teams, involving how multiple teams interact. 

If you’re a Kanban enthusiast like me and have explored the Team Topologies world, you’ll notice something beautiful: both approaches rely on clear, explicit policies. Let me illustrate this with a little story. 

The “What Kind of Team Are We?” Adventure 

Imagine starting as a coach or consultant at a software development company. You ask the first team about their setup and surroundings. You quickly find out they need to coordinate with several other teams to deliver true value. Then, you ask the million-dollar question: 

“What kind of team are you?” 

Blank stares. 

“What do you mean? We’re an agile team. Isn’t that clear?” 

In today’s world, saying “agile team” can mean everything and nothing at all. That’s why using Team Topologies to map your team as one of the proposed patterns can be so helpful. It’s a fantastic way to improve workflow within and across multiple teams. 

The Joy of Clear Team Language 

Organizations often struggle to describe their teams, resorting to vague jargon. Team Topologies introduces a common, easy-to-understand, and visual organizational pattern language. 

“Are we more like X or Y? If your team identifies as X and so do we, what does that mean for our interaction?” 

Interactions between teams should be more than just lines on org charts. True business agility lies not just within teams, but also between them. The Team Topologies language of interaction patterns is another excellent example of making policies explicit. 

Introducing the Team API 

This is where the concept of the Team API from Team Topologies comes into play. Despite sounding technical, it’s a simple, clear, and explicit contract detailing which teams you work with, in what mode, whose requests you serve, and other interaction details—now and in the future. 

Now, let’s add some Kanban spice. 

You can extend the Team API with Kanban’s “pull policy”—a rule or decision algorithm for prioritizing requests. It helps teams decide which task or request to tackle next based on a common, transparent, and explicit rule. 

For instance, if you’re a team that provides services to multiple other teams, should everyone be treated equally? That might mean following a “first in, first out” rule. Or should you prioritize based on factors like urgency, cost of delay, or service class? 

Avoiding Frustration 

Without clear policies like Team APIs and pull policies, organizations often end up with frustration and bad vibes. People pull tasks they prefer instead of the most important ones. Requests bypass the official process, disrupting the flow of work. 

On the other hand, some teams feel neglected because their requests are ignored. But before assuming the worst, consider: Is it neglect, or is your request just low on the other team’s pull policy? Maybe it’s time to agree on a pull policy to ensure your request doesn’t linger too long in their queue. 

Seeing the bigger picture helps. Other teams might also be competing for the time and focus of the service-providing team. So, before you assume bad intentions, realize this might be the best way for them to manage their workload efficiently. 

Finding the Way Out 

If you’ve worked in a larger organization, these stories might sound familiar. So, how do we escape this chaos? Team Topologies’ language, tools, and solutions like the Team API are fantastic partners to establish clear, explicit policies for team interactions. They align perfectly with the Kanban Method, both focusing on the flow of value and evolutionary change rather than revolutionary reorganizations. 

Remember, whatever you agree on today isn’t set in stone. Organizations need to evolve to meet ever-changing customer expectations (both external and internal). This means adjusting their internal policies to provide adequate service levels. Regularly review and adjust your Team API or pull policy to provide adequate service levels. 

That’s it for today. Kanban and Team Topologies can help each other in many other ways. Do you know or practice one and would like to share your experiences here?  

About the author: