Smaller Teams, Bigger Wins: how to split your enterprise apps teams

Neil Benson [00:00:00]:

Forming teams around components feels like a natural way to organize, and it's very common. But it's not the only way, nor is it the best way, I think, to organize into smaller teams. G'day this is Neil Benson and you're listening to Amazing Apps or watching us on YouTube. On this podcast, we help Dynamics 365 and Power Platform professionals build amazing business applications, usually by helping them adopt an agile approach. You don't have to adopt an agile approach, of course. But in most cases, you'd be mad not to. This is episode 142. You'll find show notes and a transcript at amazingapps.show/142. I was on a coaching call with Stephen yesterday morning.

Neil Benson [00:00:51]:

He's a scrum master and a Dynamics 365 architect at a Microsoft partner. He asked when's the right time to split his scrum team. The 2020 Scrum Guide recommends that your Scrum team is small enough to remain nimble and large enough at the same time to complete a significant amount of work within every sprint. Typically, that means ten or fewer people. If scrum teams become too large, they should consider reorganising into multiple cohesive Scrum teams, each focused on the same product. That means they should share the same product goal, the same product backlog, and the same product owner. Some products, including a lot of the enterprise business applications that we build, are too complex to be delivered by a single scrum team of ten people, at least within any reasonable time. I received an RFP this week from a Queensland government agency who hopes to go live with their new application before the Olympics arrives in Brisbane in 2032.

Neil Benson [00:01:58]:

Yeah, I hope it goes live before then, too. In Stephen's case, his team has a goal of retiring a large portfolio of custom applications that have got bi-directional integration with three complex external systems. Stephen's team has 22 members in it, including the product owner and himself as the scrum master. He's got 20 developers. The developers include specialists like architects and analysts and coders and app makers and testers, and they work from both Stephen's Microsoft partner organization and the customer's staff, too. 22 people is obviously way too big for a Scrum team. Stephen's doing his best to facilitate the daily scrum, for example, but that's got to be a challenge when each developer only gets 20 or 30 seconds to discuss their progress towards the Sprint goal and discuss any impediments that might be in their way.

Neil Benson [00:02:52]:

Even splitting that kind of size of team into two teams would result in two very large scrum teams, each slightly bigger than the recommendation given in the Scrum Guide of ten or fewer. But, you know, a bit like the Microsoft Licensing Guide, I reckon the Scrum Guide is a guidebook not a rulebook. But I know there are always a few people in the Scrum Police who would disagree with me. In any case, a scrum team with eleven or twelve people I think we can agree is a bit too big. Three teams of seven or eight might be better. The team is working with several massive components. There are the integrations with the three external systems, the Power Apps that they're building to replace the legacy applications, and there are Azure Services to orchestrate data migrations and other custom services. Forming teams around the components is a very common way to organize a large team into smaller teams.

Neil Benson [00:03:50]:

Stephen's teams are working on those three components, and if they split the teams into those three layers, each would be the perfect size to remain nimble and get a significant amount of work done each sprint. Forming teams around components feels like a natural way to organize, and it's very common. But it's not the only way, nor is it the best way, I think, to organize into smaller teams. You could organize into smaller teams in several other ways. For example, you could organize teams by geographic location — if you had teams in a couple of different places and you thought there was merit in organising them by the closest office if you want to collaborate in-person or by time zone if you want to collaborate remotely. Or you could organise by persona. If you're building apps for three distinct personas or groups of personas, like Finance and HR and Payroll, then you could organize by persona. Ideally, each team is self-contained and cross-functional.

Neil Benson [00:04:49]:

It has got all the skills it needs to build the app and release it into production without depending upon another team to get their work done. Organising by component — a team for external systems, a team for building Power Apps, a team for building Azure services — means that all three teams are highly interdependent and can't release anything unless the other teams have done their piece, too. It's extremely tempting to organise by component, which is often the same thing as saying, "We're organising our teams by skill set." I've done it at the Royal Automobile Club of Queensland, RACQ, a couple years ago. We had three scrum teams customising Dynamics 365 in our workstream. We couldn't migrate data, we couldn't integrate with downstream systems, and we couldn't interact with the website. That work was all performed by teams in separate workstreams. And those three teams weren't all using Scrum, they weren't all estimating using the same methods, or frankly, marching to the beat of the same drum.

Neil Benson [00:05:50]:

The result was a lot of hurrying up and waiting, waiting, waiting, and then hurrying up again. It was inefficient and stressful. In Stephen's case, another way of organising could be according to the type of application they're building. His team are building apps that integrate with one of each of the three external systems. So perhaps they could organise themselves so that each team builds the apps that integrate with external system one, external system two, and external system three. True independence between teams is never really completely possible. You'll be sharing Dataverse tables or some other common services, and you'll require coordination and cooperation between teams. But the more independently you can arrange your teams, the easier it'll be for them to manage their work and build better quality applications.

Neil Benson [00:06:45]:

If Stephen could organise his teams around three external systems they need to integrate with, then another experiment he might want to consider is to rotate a couple of people between the teams every couple of sprints. We talked about experiments and empiricism on a recent episode of Amazing Apps. Go back and check Amazing Apps Episode 140. By experimenting this way, by rotating people around the teams, each team will benefit from the best ideas and practices from the other teams. Eventually, everyone will get to contribute to all of the Power Apps being built, and they'll improve their knowledge of all three external systems. That makes the teams more resilient and reduces key person risk. It also helps build cohesion towards the product goal instead of a more myopic view that teams sometimes have if they focus on just their own work.

Neil Benson [00:07:36]:

Some teams that focus on their own work so much that it's to the detriment of the other teams they're working alongside. But rotating developers between the teams will mean that there might just be a short-term impact upon the team's velocity. I think this trade-off is worth it. The velocity of all of the teams will eventually stabilise and improve as they gracefully coordinate their work with the folks in the other teams that they know well because they've worked with them when they were in those other teams. At RACQ, the Dynamics workstream initially formed two scrum teams. As we grew, we eventually decided to split into three. Who gets to decide which developers are in each of the two teams? And when we split into three, who decided who was in each of the three teams? The developers decide. No one else.

Neil Benson [00:08:27]:

I'm sure Stephen or maybe his customer's IT leadership has got some strong ideas about how the teams should be formed and who should be where. It's natural in a traditional, hierarchical organisation that a manager forms the teams. But letting the developers form their own teams instead sends a strong signal that they are trusted. They will be self managing. That they're going to be held accountable for getting the application built. In his role as scrum master, Stephen doesn't need to organise the teams and he definitely shouldn't let a manager organise them either. Let the developers sort themselves out. What he can do is coach them to agree their ways of working, to create their own code of conduct, and establish their acceptable norms and expected behaviors. If the teams have organised themselves and agreed how they'll work, it's up to the team to make it work.

Neil Benson [00:09:22]:

Sure, they can call on Stephen if someone is struggling, but if they're self-managing instead of being commanded and controlled by a Darth Vader-style manager, it's much less likely for the team member, for any of the team members, to exhibit some kind of disruptive behavior. Towards the end of our call, Stephen and I also discussed the scrum events when you've got two or three scrum teams, and not just one. We agreed that a joint daily scrum wouldn't be helpful. That's the pickle he's in already. But should Stephen run joint sprint planning, sprint review, and sprint retrospective events? That's a great question. Maybe for a future episode of Amazing Apps. If you're running a large scrum team or multiple scrum teams, get in touch, let me know, and I'll record more episodes about scaling scrum. Until then, I'll leave you with a book recommendation.

Neil Benson [00:10:12]:

The Nexus Framework for Scaling Scrum. It's from Scrum.org's Professional Scrum Series written by Kurt Bittner, Patricia Kong, and Dave West. In fact, the Nexus scaling framework was devised by Richard Hundhausen. He was a guest on Amazing Apps Episode 136. Visit amazingapps.show/136 to check out that episode. Remember you can visit amazingapps.show/142 for a transcript and show notes for this episode.

Neil Benson [00:10:39]:

While you're there, you can leave a review. You can buy me a coffee. You can check out other podcast episodes and videos and apply to be a guest on here and share your story with us. Until then, keep sprinting. Alright, I'd like to try something a little different in this episode and host, like, a behind the scenes after party. If you've joined me just to learn about splitting your scrum team, you can hop on over to whatever you've got coming up next. If you want to stick around, we'll call it the Amazing Apps Retrospective. If I had a guest on here, I'll be sharing more of my guest's backstory.

Neil Benson [00:11:16]:

This is a solo episode and I don't have a guest. Instead, I'll give you a quick update about what's going on in my life with my two businesses. Customery is busy designing a new website. Some of you were kind enough to spend an hour with my researcher, Karthik, and he's creating the copy. Louise Williams has created some new photography, and Studio1Design has created the first design draft. I'm really excited. Development is going to begin soon, and I can't wait for Customery.com, Customer.Academy and AmazingApps.Show to all find their new home on the new site. Customery Academy is going to be the home of my training courses and coaching programs.

Neil Benson [00:11:51]:

Amazing Apps will be the home of my free content — blog articles, the podcast episodes, the videos, and guides. They're all going to be available from Customery.com. Watch out for that sometime in the future. I'm also the cofounder of Superware. Superware is a Microsoft ISV creating engagement applications for Australia's superannuation funds. They're like retirement investment managers. We've just come back from a week in Melbourne where we had a go live event with HESTA. They've been an amazing customer and we're really proud of their new Unify CRM application.

Neil Benson [00:12:26]:

The team continues to refine the CRM for Superannuation app that we're building, and we'll be launching a new version of it in a couple of months. Right now, we're planning to see how many of the team will be at the Power Platform Conference in Vegas in October. I'm hoping to take my family to California for a week or two beforehand. Two of my kids were born there and we'd love to catch up with friends in LA before we head over to Vegas. Hope to see you there. Until then, thanks for joining me in this Amazing Apps after party. I hope you enjoyed it. Keep sprinting.

Neil Benson [00:12:55]:

Bye for now.