A practical team structure to foster cross team delivery in multi-team products

After coming across the same situation a few times, I decided it’s time to write about an approach to software delivery team structure that we have used with great success at a major government organisation around 2018-2021. Since then I have worked with three other organisations that seem to suffer from the very same problem - they find it difficult or slow to execute delivery of features or product increments where there are multiple teams involved in the end to end implementation.

Once you’ve understood the problem you may suggest that the delivery teams in such organisations could have been better aligned to value chains which would enable them to deliver each increment independently, and you might be correct. For one reason or another the structure of teams wasn’t going to change in any of these organisations. I will not go into the details of why in this article so you will have to trust me that there were sufficiently good reasons for that.


Consider the following 1000 words in the shape of a diagram and I will explain the boxes and the interactions below.

Explanation of terms

In this diagram we use several terms that may need a little bit of explanation so I’ll start with that.

• Long Lived Teams (LLTs)  - refers to software delivery teams that look after a number of services or products and have a relatively stable structure. For example consider a team looking after the Authentication services at a large organisation. This may include services like login, multi-factor authentication, single sign-on, etc. Suppose we have staffed this team with six software developers, two quality assurance engineers, one business analyst (BA), one product owner (PO) and one delivery lead (DL). When we say that it is a Long Lived Team we mean that the same people(or roles) will remain on this team for a relatively long period of time. We also expect that an LLT is a modern day team, responsible for development, deployment and live support of their products or services (aka You-Build-It-You-Run It [YBIYRI] team)

 

• Short Lived Teams (SLTs - great acronym, I know ;) ) - Short lived teams are created for the purpose of delivering a specific feature that requires changes in multiple services (or products) and will ideally include representatives from each team that owns the affected services. An SLT will also have a BA, a PO and an Architect. These three roles will have different level of involvement depending on the size and complexity of every feature. An SLT is expected to disband once the feature is fully delivered in production. Sometimes people will participate in multiple SLTs. This is at their own discretion, provided that they feel they can handle the cognitive load. It’s worth noting that in this environment Software Architects take an advisory and supporting role and aim to help teams overcome hurdles in the organisation (be it technical or political) or provide advice when asked to do so.
  

• A note on the so-called tiger teams - You may find many similarities between SLTs and tiger teams however I believe there is one major difference at least based on my experience. The way I've seen tiger teams utilised is more like an exception - a team created to solve a complicated problem over a short period of time. Tiger teams are not common in the organisations I've seen them used. SLTs are part of the usual way of working in our approach. 

 

• Feature refers to a piece of functionality that delivers value to our customers. Therefore an increment that implements a change that makes no difference to our customers is not considered a feature. Features can be very visible (e.g. involving User Interface changes) or less visible (e.g. involving performance or stability changes). Example of an increment that makes no difference to customers would be implementing the back-end part of a form filling service. Our preference would be to implement the entire feature, end to end (E2E) so that it provides value to our customers when complete. Sometimes features can be delivered by a single LLT and other times they would require the involvement of multiple LLTs. We found the latter to be the case over 80% of the time.

Running LLTs


This model doesn’t tell you how to run your Long Lived Teams except for the expectation that they will be You-Build-It-You-Run-It type of teams. The fact that all five of our teams in our original implementation used a “Kanban for software” type of process might have helped our approach but we have no reason to believe that other methods would be unsuitable. The only real requirement for your process is to be able to accommodate the running of multiple SLTs alongside your LLT and to be able to make visible progress towards delivery of features. As such a process that forces you to plan a period of time in detail for say two-four weeks might not be very suitable.


Running SLTs


This is where most of the specifics of this model are concentrated. Creating more teams and asking your engineers to be part of more teams can risk upsetting some people. But in this model, being part of one or more SLTs is nothing too onerous. In fact, this is probably what your engineers already do but are probably much more frustrated due to the lack of structure and the disconnected nature of how work gets done between dependent teams. Think of the SLTs as one way to eliminate the dependencies. Here is how it works

1. SLTs add only two separate ceremonies for the lifetime of each feature.
2. The first one is the feature kick off. It could be led by the Product Owner or the Business analyst. Depending on the size of the feature it could even be a very short informal conversation.
3. The other one is demonstrating the completed feature. Often we’ve seen teams do quick informal demonstrations of individual pieces of the feature and a little longer one, when the entire piece is complete. This may not require any more people than just the e2e QA and the BA and PO.
4. SLT team members have a common way of communicating. Usually that’s just a slack channel bearing the name of the feature. These channels are public and anyone interested can join (although they rarely do). 90% or more of the SLT communication happens via this slack channel although ad-hoc sessions or cross team pairing is often observed.
5. There are no SLT stand ups. Instead the LLT stand-ups are open and anyone can join if they wished to learn more about something.
6. SLTs might do cross team pairing or ad-hoc sessions if something needs clarification but none of these are mandatory

What does this mean for…
The DL
Delivery leads primarily look after their LLT the way they usually do. Their responsibility related to SLTs are mainly about

1. Ensure kick off happens
2. Monitor the age of tickets in the feature and have relevant conversations if a ticket approaches the service level expectation
3. Track progress and report to grown-ups
4. Help out with any release activities necessary (e.g. training, adoption, etc)
5. Announce release and praise people

We have seen DLs successfully look after 3-4 SLTs in addition to their usual LLT.


The BA

Business analysts focus on features and work across delivery teams. Far too often we have seen BAs assigned to teams and having to figure out how to split user stories to fit in with the split of teams. We found it much more logical to have our BAs focus on the entire feature and work across teams. In doing so they often have to collaborate closely with the engineers (or technical leads if you have them) to ensure that the user stories they write are the right shape and will work for the teams both long and short lived.
We found that this concept doesn’t work well for every single BA we’ve come across however it worked for most and they found it very satisfying that they can see a feature delivered end to end.


The QA


The role of the quality assurance engineers is mostly the same as on any other modern Agile software delivery team. The only difference is perhaps the ask to have one of the QA engineers take end to end responsibility for every feature. We didn’t think this would cause any problems because our QAs were already self-organising to do the end to end testing. Making it more formal actually helped ensure the workload is shared appropriately. The  E2E QA co-ordinates QA activities, may lead on demonstrating the E2E feature and looks after the feature until it is working correctly in production.


The PO


Like the BA, the Product Owner looks after a whole feature (or a few features). If you find that you don’t really need both a PO and a BA you can probably run this model with just one of these roles. In big and complicated organisations we found that both roles add value. Our BAs were focused more on the teams and actual implementation and our POs were external facing and did the job of explaining what we’re building to the rest of the organisation and making sure we build the right thing.


The engineer


This model probably causes the least change for the engineers day to day. In our experience, our engineers saw the SLTs as a positive change that brought some structure to otherwise complex environment, enabling them to communicate easily, rely on a lightweight and clear process and resolve any cross-team issues quickly and efficiently. If you have technical leads they will need to work closely with all BAs that look after features related to their teams’ services. If you don’t have technical leads then engineers will have to share that responsibility so they can advise the BAs about feature implementation.


The architect


Architects, as alluded to previously, have an advisory role and an enabler role in this model. We have seen them involved in some, more complicated features but mostly not get involved unless asked to in the majority of features. Architects may be part of kick-offs and seek for ways to help the delivery. They may also get involved in conversations with other parts of the organisation or external vendors.
​

Example weekly schedule and sessions explanation


To make this a little easier to imagine I will share a sample weekly schedule and some of the sessions that might be happening. This schedule and the sessions are clearly context dependent and you may have different sessions that work in your environment. However it should give you an example of what might be needed to make this model work.

As already mentioned the LLTs can run their own process and we won’t try to detail what that might be here. We just added a line for LLT daily stand-ups which we found to be useful when they are open to all other teams should others want to listen to the conversation of a specific team.


Feature life-cycle sessions


Every SLT is formed because of a feature and the feature begins life in the product world and usually comes from a roadmap or a backlog. Product owners and Business analysts will have confirmed with relevant stakeholders what the business and user needs are before bringing the feature to the delivery teams. They would then often have an initial session with relevant tech leads or engineers if the feature is more complicated to make sure that there is an approach to implementation that works for all existing services and LLTs. This session may not happen if the feature is already well understood. Equally, further architectural sessions may be necessary when the feature implementation is very complicated.


Every feature will start its implementation journey with a feature kick off session which will usually involve the lead BA and/or PO, the relevant engineers from every team that has involvement in the delivery of the feature, one or more QA engineers and an architect if needed. In this session the BA will ensure all necessary user stories (or work items if you like) are created and stored in the same list which the SLT members can then refer to when they need to pick up more work.


When the feature is complete and ready to demo, the e2e QA will organise a feature demo with any BAs, POs and other interested parties involved. If the demo is successful the feature will typically be deployed to production ideally via the existing deployment pipelines as part of the continuous deployment process. This doesn't mean that early feedback is not sought during the development of the feature. Quite the opposite, typically every work item that is completed is demoed to the BA unless deemed unnecessary (e.g. for changes that don't impact the user experience). 


Sometimes as a result of the demos, more work or changes are identified, in which case new user stories (or work items) will be added to the list and the SLT will continue work until it completes the new work items. In some cases the e2e QA may organise a demo earlier intentionally to get initial feedback or in expectation that there will be changes necessary.
​

The features progress review


This is a weekly session that involves all Delivery leads, all Product owners, all Business analysts, all Architects as well as any senior stake holders and people involved in feature adoption (e.g. training, change management, etc).
We would suggest that this session moves quickly through features making sure actions are being actioned and does not take more then 30 minutes.

In this session, we would walk through all features that are in progress, typically in a priority order or starting from the features that have been recently completed, then those closest to completion and so on. We would then provide a brief update for how the feature is going and highlight any delays or blockers. Further action may need to be taken when there are blockers. The facilitator will prompt action owners for updates on their actions, will take notes and record as part of the feature update and will make sure new actions have owners. Towards the end of the session we will have a look at upcoming features and may then use this information to plan for feature kick-offs.
​

How about User research and UI design?

After some initial struggles we found that integrating these roles in the model can work well with some flexibility on how and when activities are done. Depending on your available people, when we refer to UX we may include the following roles: user researchers, UI designers, content designers. Some things to bear in mind

• When a feature involves UI changes or affects customer experience then we would involve the UX people as early as possible.
• A feature implementation may start using an initial and un-tested UI design and may then take into account feedback from user testing later on to implement further changes.
• UX professionals will work closely with POs and BAs early in the feature lifecycle and will be involved in feature kick-offs and feature demos
• Feedback from UX professionals will be implemented as early as possible but sometimes in a further iteration of the feature at the discretion of the PO
• Collaboration with UI designers will be frequent during feature development and often requires them to be part of the SLT.

​Final words


If you made it to here then well done! I know I probably wouldn’t have read as much. I need your help. Do you think this would work in your organisation? If no then why not? If you are experiencing dependency problems and insufficient cross team collaboration then how do you handle it? Is there anything in this article that doesn’t make sense? I’d love to hear from you.