If you’ve ever been involved in building a single product with multiple teams you know how tricky it can be. With competing ideas and different priorities it’s not always smooth sailing.
The good thing is, there’s always solutions and good habits to overcome the types of challenges that come with scaling a project like this. Here’s some of the challenges you may come across along with the lessons learned and experiences I’ve had when I’ve encountered them.
Navigating silos and low morale
One of the first challenges you can come across with this type of work is building a truly unified team. I’ve seen this most when there’s no pre-planning session for everyone to get together and define the shared objective. This sense of siloed working becomes obvious when you soon find yourselves without a single backlog of work (more on that later). Before you know it, the whole team is feeling the pressure and now there’s low morale.
Siloed working is like eating the same food every day. Daily pizza might sound great at first, but after a while it gets dull. It’s the same with work. If you have a long project and people are working on the same stuff for too long – always seeing and receiving the same problems – you’ll get low morale across the team.
Before you know it, each team is working in an isolated fashion. So how do we fix this? It’s time to involve representatives from each group in a team meeting. This way they can be updated on everyone’s workflow and take information back to their teams. Providing this space for visibility on the work coming from everyone gives people the chance to speak with their peers and decide who’s best to take on certain tasks. I’ve also seen this space encourage teams to support one another, often happening organically – building that essential team morale.
Conflicting product backlogs
Working in silos can also mean that each team has their own backlog where there’s no visibility and you often don’t know what others are working on. With this lack of oversight it’s really easy to lose the actual goal that you’re working towards for your single product.
So the easiest thing to do is get everything onto one backlog. Then let’s share the backlog with everyone. And let’s prioritise the backlog, not per team, but as a team of teams. Having a Scrum Master be the product owner for the different teams is crucial. They’ll be the person who can help you prioritise, rather than having conflicting priorities coming for different groups.
From there you can come together to decide on what objective you want to have done in a couple of weeks. What’s that one thing you want to accomplish? Okay, now to accomplish that, what are the crucial results that we need? What are the essential outcomes of the things we need to do? That’s how to get started.
Help! There’s too many dependencies
Each team has areas they specialise in. So if the work is too dependent on one specific team then you start to see a queue grow and cause delays. On the other side of the coin, if you don’t have any work to be done on the user interface, for example, that team would be very much idle – which is no benefit to anyone.
Now, there’s often parts of a system that need more TLC than others. And that means there’s always people in higher demand. But if that team has people on holiday, it means your capacity to deliver really slows down. And then your growing queue of tasks gets even longer.
But it’s important to remember that there’s always work to be done. If you’ve been facing multiple challenges in your product so far, it’s worth thinking about refactoring and solving technical debt. Focusing on this means you’re not only working towards improving the software technically but also solving problems for the users.
If you’ve also implemented the team meeting we mentioned earlier (wink wink) then more visibility means priorities can be shifted and adapted – truly channelling the agile manifesto. In my experience, I’ve seen teams work together much more efficiently when you’ve broken down silos in this way. Teams talk to one another and everyone understands other capacities. There’s often collaboration to make sure everyone’s clear on who’s taking what task, so nobody feels the pressure.
Techniques, habits and communication
Scaling agile practices can be tricky, particularly when you’re introducing more teams to your project than ever before. When working on one product there’s a lot of priorities to balance and often conflicting challenges. But I truly believe if you draw from your arsenal of agile techniques, build good habits and strong communication you can create a unified team that delivers an effective product.
Sharing my learnings through this post I know there’s always lessons to learn and experiences to draw from. I’m excited to continue practising scaling agile with projects at Made Tech and building my own box of tips and tricks.
If you’d like to hear more from us on project delivery and more, sign up for Made Tech Insights to get new blog posts and other content delivered straight to your inbox.
