Every organisation that wants to run an effective business will undoubtedly aim to structure their teams so that they are capable of working effectively and making a positive difference. As consultants we have to at least assume that to be the case...
How do effective software development teams interact
As consultants we have to at least assume that to be the case even if a specific organisation we work with hasn’t realised it yet.
An essential part of an effective structure is how teams work together to get stuff done. This article seeks to address the interaction between teams only. I see teams as service providers. They complete items of work for other teams or for stakeholders and sometimes directly for the end user. It is important for a team to know their capacity for work, to understand their ability to complete work items and be able to indicate to other teams or clients how to interact with them and what to expect. Failure to do so results in an ad hoc process which often sets everyone up for disappointment.
Teams acting as service providers probably sounds like a departure from a very common model we see in organisations. A model where team members from Team A are, in a way, being lent to other teams (e.g. Team B) to help them complete a piece of work, while continuing to be a part of their “permanent” Team A. The numbers collected from working this way does not help either Team A or Team B build reliable data for better forecasting and in a way represents a disruption to normal service for both teams.
If you find yourself in an environment like this which is usually characterised with a great number of dependencies between teams or a limited number of specialists then you may need to change your perspective and consider that perhaps either the teams are not structured in the best way possible or may be the important value delivery happens at the meta team level and you could direct more of your efforts at that level. The rest of the article assumes that this isn’t the case.
Assuming the majority of your teams are structured around value streams, except for platform teams or any specialists teams (e.g. embedded technology team), what follows is a proposal of how to make team communication not only easier but also compatible with an iterative approach to software development and the you-build-it-you-run-it model.
Before we continue on, I also want to mention another term you may have heard of - Team APIs, which some of you would say is a very similar concept. And you might be right, however, knowing that API stands for Application Programming Interface, I don’t find it an appropriate term to use in relation with teams of people. A team interaction protocol’s purpose is similar to an API and yet they are different. I strongly oppose using the word “resources” when addressing people and the use of API reminds me of the same notion. There’s much being written about why calling people resources is a bad idea - here’s one example from Ben Linders that I like (https://www.benlinders.com/2018/dont-call-people-resources/) . This is why I find Team Interaction Protocol (TIP) to be a better name.
With that in mind I am in favour of teams defining and evolving their own Team Interaction Protocol to both serve their customers well and improve the team’s flow of work. So what exactly does that mean?
It was circa 2016 when I first came across an environment in which the problem was quite evident. There were at the time about 60 different software development teams delivering services on the same platform that served one client with their multiple initiatives, providing benefits to millions of end users. As teams were working on delivering value for their service owners, it transpired that they often had to collaborate with other teams to make changes in their services in order to achieve their end goal. I’ve witnessed many examples where the rules of engagements were not established and relied on ad hoc communication and working out what to do. While these were not entirely a bad idea, there was always an element of disappointment due to different expectations on either side. And then there were other engagements in which it was clear how to request work from a team and what to expect in return. These seemed to work better in the sense that both sides were broadly aware what to expect and there was a reduced level of disappointment and fewer escalations.
What does a Team Interaction Protocol look like? What better way to explain something than to show you an example. This is a very specific example from a team I worked with. And it is just an example which may or may not be suitable for your specific circumstances. It is important to define your TIP in your own world having in mind your specific needs and the needs of your customers. The example below is for a team (we’ll call it Team G) that worked on an essential part of the customer journey for the majority of the services on a platform serving millions of end users every month. This meant the team was extremely busy and iterated on their TIP for several months before arriving at a version that was widely accepted as a big improvement on the previously used ad hoc approach.
Team Interaction Protocol (Team G)
Once Team G implemented the above protocols we observed a significant reduction on the friction previously experienced when working with other teams. This TIP sets out expectations upfront and seemed to be a welcomed approach by most teams we worked with over the following year or so.
Tips for creating your TIP
Your TIP will depend on the culture of your organisation and the specifics of your ways of working so it is difficult to provide concrete instructions. Instead here are some tips:
Teams usually exist amongst other teams. As such we often need to collaborate between teams in order to achieve our desired outcomes. To aid team collaboration, we recommend that teams create and promote their own Team Interaction Protocol( TIP). We have found this to be a useful way to set expectations from the start, reduce friction and help teams collaborate well.
Welcome to our blog!
About the author
Plamen is a LeanStack coach and an experienced Software Delivery consultant helping organisations around the world identify their path to success and follow it.