# Strategic Team Topologies for Large Agile Units

**Podcast:** Software Architektur im Stream
**Published:** 2026-03-17

## Transcript

Okay, so welcome to another episode of Software Tech on Stream from the Adramids Architecture Conference here in Berlin.
They were kind enough to provide us with some space to do this episode.
So thanks a lot.
And I'm sitting here with uh Svetelina and Priscilla, and we are talking about splitting without splitting.
So that's the name of your talk.
So first, do you want to say a few words about yourself?
Do you want to start?
Yeah.
Hi, I'm Priscilla Gunauan.
So I'm a coach together with Svety in NIQ.
And I'm also an agile coach in NAQ.
Our company is called Nielsen IQ.
So we work within market research.
And we are a big international company, which means translated roughly about 30,000 people around the world, but only about two, three thousand are in tech.
So what that means is like we are not a technology company.
We are a market research company that has a really big technology operation.
And that is mainly because we work with data, we have a lot of data uh science and different types of roles in our company.
Yeah, we have a lot of uh specialized roles.
Um not only um front-end, back end quality engineers, for example, then we also have like SRE, and then from specialization of data science as well.
We have data science, we have machine learning engineer, we have machine learning operation, and so on and so forth.
So we are very diverse in terms of roles.
I think one interesting uh points why do we have that much is because a lot of people that is working in data science as a data scientist roles in our company is coming from mathematics and uh statistics breakdown.
So, and then they learn how to code uh on the go.
And then we have people that is uh very strong at uh technology backgrounds working in for an um backend and also QA.
And of course, uh within our company themselves, there are many cases where they're cross um moving across different titles, or moving and being open as well to take up a new challenge, even if their roles um data scientists, for example, and then oh, I can fix a front-end box, and why not just do it?
So we we also have that kind of situation happens, but generally this is what in heaven.
And um I think so from the conversation that we had before, uh I I um understood that your company is actually not aiming for full stick developers, so it's sort of intentional that you have these different roles, like back in the front-end engineers.
So yes, and somewhat uh you can say that we are kind of aiming there, right?
But you cannot just do it in one go.
Like you need to give people opportunities to learn, to grow, etc.
So it's very much encouraged, but there are also some um some things in the way that you need to overcome in order to get there.
It's sometimes it's just getting a new skill, but sometimes it's like there is contractual obligations behind these roles as well.
So there is a lot of complexity in how do we move from a very role-based company that can um operate in a certain way towards a more cross-functional, com-shaped type of a company.
Yeah.
Yeah, I was just um I found that just interesting because there is this move towards full-stack developers.
Yes, and they seem to be intentionally doing something different.
So I think that's great.
Now, from what I understand from these roles and also from the conversation before, there is this problem that you have these data scientists in particular, because there is so much data.
And um it seems that sort of the go-to solution to that would be to take one data science and have it scientists or multiple and assign them to each team, and then you have a cross-functional team, and uh then you're done.
And obviously, so you're doing something different.
So, what are you doing different and why?
Want to take that one?
So in our company case, um the data scientists are very much involved in not only a business and operations support system.
Yes, they are kind of like embedded within the team for that.
Uh, but they also uh doing a lot in research uh within the data scientists themselves.
And that research is if we refer back to the double diamond, uh they are much more involved in problem space, and then they become the stakeholders of the engineers in the solution space.
So somewhat.
Yeah.
Maybe another point is like a lot of our data scientists also work in academics.
So they are bringing in papers on their own work, they are sometimes professors.
Yes.
And on the other hand, there is also a lot of new students that are also being integrated into the work.
There is a lot of different types of activities and research.
Sometimes it's more operational, yes, but sometimes it's more novel stuff.
How do we bring this in in this double diamond structure?
So what did you find works best for you to uh to uh uh deal with these data scientists and these multiple different roles?
So maybe there is not one perfect solution.
I think this is kind of the biggest realization that we've made that there is actually no perfect solutions.
Yes.
And um in the industry, there is this obvious solution to a bigger team that has a lot of different roles.
Um and this has grown beyond like let's say 20.
Yeah.
The obvious solution is hey, split this team.
Like why not just split them?
They will be more effective, they would have less bigger calls, they would have nicer discussions.
And this is somewhat true.
But then on the other side, you have to really consider is this situation you're in, is this team really able to split in a way that's gonna be effective?
Because in our case, with so many different roles and so many things to integrate, it might make sense to consider finding other ways to make the environment more productive for everyone without having a hard split between the different parts of the team.
So this is a little bit different thing to get your hand around is are we now one team?
Are we two teams?
And in the end, we are one team that has one team culture, one team name.
We have principles that work for to uh for us together, but then we also create spaces where we can deep work separately.
So it's a little bit of a pattern of creating spaces for a team to be separate and creating a space where they can be together.
Yeah.
So what is the size of the team that you're talking about?
So is it the scrum this magic scrum number of seven, or is it something different?
No, we start with um probably we were starting it with seven or ten at the first place, and then we grow big into around 20, 21, 24, less than 25, and that's when we decided that it is now the time for us to rethink how uh we should work together.
Whether we split, but if we want to split, let's split wisely.
Um, or we don't split, but how to navigate if we don't split, and that's why we have four different cases there, and four different teams with four different backgrounds, uh, four different culture as well, and how every single team probably creating the same pattern, you can say so, but uh the approach is different.
Their ways of working approach is different.
So can you give a concrete example?
I think uh in the conversation that we had before, you you gave that example about those three backlogs that were shared across all the people.
Oh, that was a fruit team.
Yeah, so for this team, um we we have a team uh that's doing um uh a shop management for that.
And then this, oh no.
It wolfy automatically, yeah.
Like for auto matching, like uh for Wolfie, uh this team is doing auto matching.
So they don't have front end.
Um they're having only data scientists within them.
And then uh they have three different blocks uh three different backlogs for them because they need to be involved in three different streams.
The business operation support system streams, and then the data science streams that is much more related to research, and then the other one is uh the engineering streams.
There is uh our engineering practice will also have certain standards that we we all team have to fulfill as a one company, right?
Security, for example, versioning, for example, and so on so forth.
And they have three different backlogs, and depending on uh the priority of its backlog items, um they will reteem themselves against and against every single sprint.
So I think this is a very um provoking ideas, or say this uh fleet teams, because it is not stable at all.
They will change every single sprint depending on the priority and the backlog.
Let's say, for example, like spring one, we need um certain items ready for the B BOS.
You there is a a contract, and then there is a time limit that you have to deliver that.
And then, all right, then if we want to fulfill that contract because it's black and white, and then there is an urgency for that, and then the team will be um, oh, we need more people on his side, and then you can, what can you drop in the other backlog?
Certain team members will go to these streams.
And the next sprint, when this season is over, they said, oh, we have to do security, because security is also sometimes there's a deadline for that.
So then let's return back the people who could do security things to do to tackle the engineering backlog while the other still maintaining others.
Or also another cases is that maybe Sprintry, that a data science that's doing the research.
Oh, I think this is important for us to do these things.
And we let's implement it this way.
And other data scientists, like how we need more help.
You are the only one who have that knowledge.
Okay, then I will do it together with you with this knowledge sharing and all stuff.
Then he pulled back from the data science streams, go to the BOS.
That also could potentially happen.
And they keep retreating every single sprint.
We could say that.
Um because they have a touch points, they have many touch points in the refinement, in the dailies, and so on so forth.
They can sense which what is coming.
They have these refinements because uh of course they need to figure out what the work is gonna be so they can already sense where it's gonna be more need, where it's gonna be more demand for the different types of skills.
And even if we are not yet starting the sprint, we already know next sprint is gonna be this situation, and then we do the sprint planning according to what we learned during the refinement.
Yeah, okay.
So that me, yeah.
So if I understand correctly, it means that every sprint uh you take those or those 25 people take themselves and split them into some teams that would then work on some backlog items from these three backlogs, and that's basically it.
Um I mean, one of the reasons um so we at the end of the day we are in in uh in a stream that also talks about software architecture, and one of the reasons why uh traditionally you would split into teams is the idea that you only have to understand a certain part of the system, so you have limited knowledge, and that allows us to scale software engineering.
Now, what you seem to I mean, obviously what you're suggesting works, but uh it probably means that everyone needs to understand everything, so there's a limit to the complexity of the system that you're building.
Is that the case, or do you have different experiences?
I guess it depends a little bit.
Um, what we've seen is that not every team is interesting in interested in understanding everything.
Um, for example, we had a team where um they were not interested in the how of the other sub-team, like they would they would uh there was those two sub-teams, and they were both interested in what we're building and why we're building it, but they were not so interested in the very details on how do we train the model, how do we do this type of um activities in that are very narrow and very focused.
They were more interested in the what um than the how, but then they would still have some common guidelines, like some of the how would be common, like coding standards, um definition of done, testing, all of these more cross-cutting concerns would be common to all of them.
And what makes this type of environment work well is that they would still feel like they are part of the same team, they have the same principles, they share the same values.
So there is a lot more trust.
And in the example where we had fluidity, I think we thought about this as well.
Would we be able to have this fluidity if all of these three teams were actually separate teams with their separate names with their separate cultures and agreements?
And we were like maybe not.
Like it's like in the middle, yeah, exactly.
And it's also not working for every team.
And then that's why we we have like four, three other examples for three other different teams.
But in terms of like the complexity, whether you're uh sealed by a certain complexity, I think because you will always have need for interaction if you're working on one system.
Because there is always gonna be dependencies, it's one system.
We we want to try to decouple as much as we want, but at some point, if you want if you're working on one system, you have dependencies, otherwise it's like meaningless.
What if anything that doesn't have dependencies is kind of a little bit too simple.
So you would be it's important to make sure that you don't go into one or the other extreme.
You don't want to decouple everything and try to be like completely nobody knows anything anymore.
But you also don't want to be a big mess.
You want to have enough separation so people can deep focus on their own stuff, but you want to have enough understanding so they can solve problems quickly between each other and solve cross-cutting concerns together.
So now what you said is that there are some, let's say, rules like coding standards, for example, or definition of done, these kinds of things.
Now how who sets them in place?
Because uh in if you yeah, I mean, is it you're saying that that the teams are basically self-organizing a lot?
Uh so people would uh uh flock together to the um backlog items that are the most important ones.
So, how do you deal with these uh definition of done and these these other things that somehow need to be decided?
Wanna take that one?
There are certain parts of it coming from the practices, like the whole company practices, certain set of it, and more than that, it's team and um every team have their own agreement.
And we, as the scrum masters, less agile coaches, we are facilitating that agreements to be happened and also like involving people to say, like, what do you think about this?
Like, are you agree?
Are you really agree?
Because when when it's already written down, does it make sense in our context what the company is like suggesting or recommending?
Does that make sense in our context?
Is our context in any case different?
Yes.
So we let people make some intelligent decisions based on their own context.
And it's also like um so we are still talking about a big company, so we are working with teams of about 25, but they are also working together, so they are not just in isolation, they're also working together with other teams on a bigger thing.
So they have though this is this balance between um how much like this this component is cohesive enough to be its own thing, but it's still connected to some other things that are in themselves also cohesive enough to be their own little bowl.
Um, and within this cohesiveness, we have some rules that might be different than the rules that the other cohesive bowl has.
So this is how we try to think about these things.
Okay, so in a way you're saying that there is some process that uh well sort of leads to some agreement about fundamentals as you just mentioned.
But now you spoke about basically, in my opinion, software architecture, where you said, okay, there is some stuff that is cohesive, which is you know, whatever you would call them, like these typical boxes that we have in software architecture.
So, what you're saying in a way is that uh in order to make to come to these conclusions to set up these rules, is it's influenced by architecture.
But you're you're you said that you are agile coaches, right?
So are you so is that something would you consider that um truly the domain of an iagile coach, or is that something that you rather feel is uh is something that a software architecture uh would do, or does that distinction not make any sense or so you mean the setting of the standards like coding standards or yeah, but but but what you just described, or what what I what I what I understood from what you're saying is that uh you have to look at the cohesive stuff, which is you know, some part of the software architecture, and that influences uh how you make those decisions and how those teams would interact.
Now, the team interaction is something that I understand you're facilitating as agile coaches, while the other part, like uh the cohesive stuff that you were talking about, you could argue it should be hidden from you because you're not a software architecture uh architect, right?
You're Azure coaches.
So I'm wondering about the the boundaries of these two things.
Okay, I think at this point we also know about the Conway's Law that the social actually impacts technical.
So there is it's gonna it's gonna be hard to be hidden, like to keep this hidden because you kind of see it on the way that people interact already.
And what we found in our work is that it's very important to when you when a team, for example, wants to make a decision on how we collaborate.
Right.
It's important for them to consider this decision from different viewpoints, or we call them forces.
For example, the architecture of the system is one force.
It could be how we are coupled, what is our tech stack, code base, etc., how we are guy um governing this part.
But also the product.
What's the vision?
What are our stakeholders?
Where do our change requests come from?
What is our product development lifecycle stage?
Are we pre-prod or are we already on production and scaling?
Um and on the third force, which is the one of the often forgotten ones, is the team, the people, like how the people interact with each other, who communicates with whom, who needs to deal with whom, or who likes each other, who doesn't like each other.
So these kind of dynamics that are within the people's scope are also incredibly important.
And for us as coaches, it's important for us not to make those decisions for the teams, but give them the space and the tools to visualize every aspect of these so they can reason about their own situation and make decisions that are more suitable for their context.
Yeah.
And I have to admit, uh what I liked about what you're saying uh concerning these three forces uh when we had the conversation before is that you're you're having people as uh uh as a first class citizen in there, like uh on on the same level as architecture and and product.
And during that conversation I noticed how you're basically saying, well, you know, some people want to work together and some don't, and some want to be in a stable team.
So you you you have to listen to them and make sure that they are comfortable with that.
So I think that's that's great.
Um I lost track.
So the I'm sorry.
Um so that's the the uh general uh uh concept that you would abstract away from that, right?
Yeah.
Wow, okay, and that you could also use in in other environments.
Yes, um yeah.
From your so we already spoke about about fluid teams.
Um concerning that concept where you said that there is like a team that flocks together at certain parts of the uh of the backlog.
Um I understand that there is also um an influence of less to what you're doing.
Yes.
So what is less even?
I have to admit that I sort of roughly have an understanding where it fits in the overall landscape, but what what is it and what problem does it try to solve?
So it's a lightweight ways of working.
Okay.
And it is very easy to implement.
And it is uh a very it is very easy when you scale or descale from Scrum without adopting a lot of many things and then you and because it is basically it's just Scrum.
Okay.
And for our cases when we adapt, I don't want to say that we adapt less because we only adapt some elements that is makes sense for our team uh perspective to implement.
We uh we like that so much.
So we have a team that is consist of 21 people and doing um outlier detection.
So in this team, uh beside the business operations support system, uh, of course, they have like uh for and back and and qA for the the business operation support system part, and they have uh a lot of uh the the brain, the data and also the AI model is what created uh inside that uh by the data scientists as well.
And we have another things uh in this is architectural, like we have something that's called in the middle, we call the glue that is gluing everything, also including gluing this uh system into the external system.
So we have a lot of people and varies there.
Um and then one fine day we found out that we stuck with Scrum events that's become longer, obviously 21 people in one team, and they don't have enough deep work.
Then we came out on uh uh a question.
We we came out like something question that isn't this is already the best time for us to split.
Yes, but how?
Because we don't want just to simply split it and then make everyone suffer.
So when we we we ask around and like how do you like things would be, and they said like we don't want scale.
We don't want to we hesitate to split because we don't want a scale, we hate it's dogma.
It was like from the team themselves, they say that.
Um so all right, so we need to find something else that's lightweight, that's easier to that.
Then we came out some elements of it, and let's see what do we have right now.
Okay, which one that is event in the events that is paying you so much, and then they point out, oh, sprint planning pains us so much, or refinement paints us so much, retrospective is superficial.
Uh, all right, and if that's the case, we can have that in in two, like sprint planning one, spring planning two.
The what together, and then we choose who's gonna do that, like the teams that's gonna do that, and then um the how part.
You decide your own.
Of course, uh we do have a background that I told you, like data scientists coming from mathematics and scientists uh uh statistics backgrounds.
There's also the one uh engineers that is much more familiar with the BOS system.
So there are certain things, the items that naturally uh we will take this and so on so forth, but then they uh they work in a sense of like um sprint planning split it into what together, how separated, and the refinement, what together and how separated, and the retrospective is separated, so they can't have a discussion that's not superficial anymore, and we have like uh overall retrospective of once per quarter.
And after that they are very happy with it, and we gain like plus sixty-three points after our satisfaction survey.
We have satisfaction survey for that.
And it works for this team.
May not work for other teams that's uh purposely say we like scale, for example.
So it's really depends on the team.
So then that's also go back to the forces that Susani was talking about.
Like the people is in the same status with product and also our structure.
But it's also interesting that basically all of our teams don't like Save.
And we ended up still with some different things.
I mean, it's true.
Our teams don't like the uh bureaucracy.
And I think you can ask any team and they would be like this bureaucracy is too much.
Um so nobody of them is like a big fan of SAFE, but still we ended up with different solutions.
So it's not just that we don't like SAFE and we put something else in place.
We really actively need to think about our own context, our own different environments, and then craft the ceremonies and everything we do in the work, the the way that it fits it.
So we have we end up with four different solutions.
Yeah, actually, even though you could say oh, they all uh hate safe and then let them do something else.
Yeah.
So under the hood, it's always like this.
Um it's very interesting to see that on the outside we look like a safe shop, but when you look closer, you see like lots of teams that are doing things that are nothing like safe, and they organize in their really different ways, cherry picking of different frameworks or uh schools of thoughts on how to manage and organize um work in software development, and then craft their own solutions.
Yes.
So if I understand correctly what what you're saying is that uh this is uh is a framework like uh save to scale agile processes, and uh you took some uh some inspiration from that, like uh this two-phase um uh ceremony that you were talking about, and this is uh how you and then you cherry-pick the stuff, and the other the other thought that that I got is that uh from a management level you're sort of doing safe while in fact you're doing something different.
Um and I thought that was quite interesting when you when you talked about that uh beforehand, because um I can totally see how management is satisfied with that kind of abstraction where they basically say, Okay, uh it's safe, so we are safe.
Yeah, um while in fact there is something different happening, and uh it's also interesting, I think, because uh it it uh it correlates with my experience that if you if if someone says we're doing this and then you ask about the details, in fact, they're doing something quite different, and I think that's more commonplace.
So maybe one of the one of the things would be to ask people who are doing uh safe what they are actually really doing.
Yeah, so there's yeah, so there are some questions in the chat.
Let's see.
Uh so there is a very long one.
I'm not sure whether I want to check that right away uh so there is one that says interesting talk thank you how long did the transition to the right team model took you how many team setups did you drop and after how much time I think this was different in each case differ yes so some some was very quickly others were taking over a year to actually improve some yes have some improvement um I can speak about one team where it was a bit of a different situation where we had two teams who were that were working in different products and then there was a decision to merge them because it did make some sense on to like the problem space that they were dealing with there were similarities and things that were supposed to be synergetic between those two teams so they were merged and in the beginning people were kind of okay and then very suddenly okay no we don't like this we don't have time and space, etc.
And people were quite quickly arriving at this realization that we need to do something because it doesn't make sense.
We have completely different backlogs.
And talking about this product while the other people were absolutely not interested didn't make sense in this way.
So we made some improvements that were pretty obvious.
We still asked them, do you think maybe you should now separate?
Because maybe this merges that didn't work.
And they were like, no, we still have potential to learn from each other and help each other out.
So we still see some benefits in being more close together and embedded in one team, but we just want to be able to do our own work within our own spaces.
So we made some obvious changes to this process, and within a couple of weeks and sprints, we've arrived immediately at a better result.
So it was really depending on the situation.
In this case, it was rather fast.
In another case, it took a year, and then of course you're always going to continuously improve even further based on how things change.
Yeah.
Which basically means that uh if well it's it varies, it varies, it varies a lot.
And it shouldn't be too surprising because it's humans at the end of the day.
And also what you said is that in a way that you're that you're still improving, so you haven't arrived at the right model.
Uh, and you're you're you probably never will.
Um okay, so there is another one by the same person, no name is the name, no name dash, some some uh random characters.
Did you have to argue with management for all the efforts and time it took to get it right?
Oh why did you give that to me?
So the answer seems to be no.
Uh yes and no in the same time.
Uh like it because we we we have four teams that now uh that we we're gonna talking about, like it's really depends on which teams.
Um teams when we have a very open-minded manager, have very open-minded leadership that you could uh can we let the team can we include the team to be involved in the solution, and the m leadership was like, yes, and so we can have this experiments and the team was also very on board, very involved.
Then no, of course, right?
We don't have that.
That's all the pitching and then all the the the responsibility that we have to do is that this is the data before, and then this is the experiments that we did, and this this is the data after I'm talking about the survey data.
And always good.
Normally, if it's emerged from the team themselves, it will be very fast experiment and it will always be good.
That was the battle.
But it was if it's driven by other forces, and uh it was not very happy experiments, and then we also have the data.
That's when we have to pitch, and then give this as a reality, like uh to the leadership themselves.
Like, hey, look, this was before, this was after our experiments here.
What do you want to do about that?
Do you still want is to follow your way, or you want to include the team inside this experiment, and it's also varies depending on this leadership um answer.
Yeah, right.
Depending on the person and how open they are.
So it seems that these uh surveys and their satisfaction surveys, right?
That's what you said.
Yes.
Uh seem to be uh crucial.
Um can you say a few more words about that?
Is it just like how happy are you at work or is it more complex?
So there's a Dora metric.
It's a little bit, yeah.
So we use the STX survey um for some of the work.
Sometimes it applies, and you can see it very well in the data that, for example, the driver of efficient processes has improved, or deep work has improved, but sometimes that's not enough because it's like you have to have a conversation, for example, in one of the teams.
You can clearly clearly see it in the DX survey.
No questions needed, not much at least.
And in the other one, it was like, okay, the efficient processes, we saw an improvement, but deep work was down, so what's going on here?
And then we were like, okay, we had a different problem because of some customer complaints getting more and more and more frequent.
So we had a completely different problem that was affecting the deep work.
So you couldn't say, okay, the experiment didn't make sense because the ceremonies now don't work anymore, and we don't get any deep work.
This was another problem.
So you have to have a conversation about those uh surveys with the team, which is very which need requires a lot of trust and um a lot of open-mindedness as well.
And and apart from that, uh, if we are talking about the metrics that we have, we also have like a job practice matrix, uh the agile maturity matrix.
It's also we only roll out recently, but we we see the potential on that.
How to see that, like how is the practices?
Are you happy with these practices and all stuff?
There's much more people and process-oriented.
Okay.
So you were talking about I think DX surveys, so that's a standard.
Developer experience.
I see.
Okay, and that's like a standard, like uh you would find it on the web or common now.
I think it's a company that's been doing this based on the Dora metrics for some years.
It's a I think a relative good way to measure team happiness and satisfaction for us.
For us, it's been rolling for about a couple of two or three years, I believe already.
Oh it's like your decision or is it something that has been introduced on the on on the company scale?
So half half, I would say, because it wasn't specifically so much our decision, but it was in line with the way that we were needing like what we were needing, what we were also thinking, like we are happy that it's based on Dora, which is great, very progressive uh ways of measuring things, and it's focused on the experience of the developers rather than on vanity metrics and yeah.
Okay.
I'm just wondering because it seems that that uh what what you're saying is once you have these metrics in place, you can argue about them, and that gives you a very good position to actually talk about whether you're making progress or not, and then talking to management is quite a different thing.
Absolutely, yeah.
Yes, but also you have to keep in mind that the metrics are one part, but who is using them, how they're using them, this would affect the measurement.
And if you are in an environment, you can have the best metrics, but if you use those metrics to make um people's lives harder, then you're not gonna get a fair measurement.
So you can't use them, you still have to do it in the retro.
Yeah, and obviously you can treat any metrics.
Yes, yeah, yeah.
So the the um sorry, the the response by no name was thanks for the candid insights.
So I think that was great.
There is another longish question about a very specific case.
Not sure whether I want to talk about that.
Um yeah, we we can try, maybe see what comes out of that.
Right.
So it's by uh Muhammad Yusuf, and he says, Um, consider this uh big team as an example, six QA engineers, 12 developers, one UX UI person, one technical manager, one product owner, two business analysts, all working as one scrum team.
So, how many in total was that?
Yeah, I was just wondering.
So it's six, twelve, eighteen, twenty, twenty-three.
Okay, okay.
Uh at least.
Uh, all working as one scrum team because the application architecture is microservices-based.
Um where some services are common and others are based on different functionalities.
The technical managers are taking technical decisions uh for all related functionalities, combined planning, combined scrum, combined retros, and reviews take place.
So there is no question.
I think that's at least I don't see any here.
Maybe you he wants to ask uh how how to do how to deal with that to deal with that, right?
Yeah.
So one thing that we would always be using as advice is visualize everything.
So visualize how what's your architecture?
Right, a rough architecture, where is the different bigger components where different people would be collaborating?
Like which people were collaborating, which parts of the system, and this is one thing, and then the other one, who is talking to whom?
Visualize that.
Answer questions like what are your stakeholders?
Are any of these stakeholders interested in only part of the work and which parts?
And uh where in the product development lifecycle are you?
This type of things need to be clear and put all into the table, like create a workshop together with the team where this stuff is visualized.
So if you would be creating any spaces where people collaborate, it was it is going to be almost emergent out of what you're visualized because they will say, Okay, here we are together.
Maybe it makes sense to have some conversations in this group and then come together and kind of exchange on what we've learned.
But it would need to come from them because it needs to make sense to them, because their work is gonna be their work.
Yeah.
Yeah, that touches an interesting and and uh good point that that I wanted to dive deeper into.
So um why is visualization?
I I took that also as a note when when when we prepared the the episode.
Why is visualization so important to you?
Maybe just a quick one, and I'll give you like one of those things, especially if you think about it.
We're talking about 20 plus people.
You remember this graph with all the communication lines?
Yes, yes, it's the same thing with the visualization, it's not just the communication which gets complicated, but visualizing all of the constellations over time of 20 plus people, it gets really hard for the for the head to comprehend.
So putting it into a actual visual space, it's uh helping to reason and see patterns that you cannot see if it's only in your head.
Okay.
Yeah.
And I I guess the team is also um have been mixed for so long.
So they uh you can imagine them like they're already like a salad, right?
Like you're mixing them and all that stuff.
So it will be hard for you to uh to what kind of split that you want as well, right?
Like what kind of split that the teams want.
Like we know that when we are practicing Scrum, why do we want to have a cross-functional team within the Scrum?
We know that, right?
So you want to be you want to have a part of salad every every but now goes back, it's goes back to your team in your context.
You know more than we do, and maybe one bowl it's mixing bit with uh the greens the the tomato, but without the cheese, for example, and the other bowl is with the cheese.
That's also can be an option.
That's still um it's still cross-functional, right?
In that sense.
Um it doesn't need to be completely uh everyone get the same in four different bowls, for example.
You can try to mix it out.
And the idea of cross-functional is that you want to be able to deliver within a short sprint.
And if you can't fulfill that, you know the context more than we do.
And one other thing we wanted to avoid often is to have people that need to switch between teams.
Like this problem can be very painful.
Like if you have to go to two sets of ceremonies and you have to collaborate within two different environments that drift apart, it gets very hard for the people who need to be shared.
So we wanted to avoid this situation of you have completely different split with different ceremonies, different contexts.
This was one guiding guiding principle.
Because we we have that like why Swedish mentioned that like maybe one of our teams is that we unwisely uh split them at the first place, and then it's resulted that uh half of the team is shared because they've been uh they've been mixed for so long and they're creating uh small subgroup within them.
Like it's 24 people, they're creating a subgroup within themselves, and apparently they're also creating a knowledge ivory tower where their subgroup knows this knowledge and the other subgroup doesn't know that.
Um they're very crucial in both parts of the system.
So then when it was split it into two different scrum teams, half of them needs to be shared because we need that people in the team because of the knowledge ivory tower it was not really wise decision at a point of time we thought that we involve several factors but apparently not so I think we also need to ensure that it doesn't happen in your context yeah and at the end of the day it's it's different settings and different uh people and different circumstances so I think yes that's that's a very good point and you're you're very good um you're illustrating how and not one size fits all but coming back to the to the visualization so um visualization of I think I I uh I understood team dynamics like these kinds of things that's what you're talking about collaboration communication patterns like who needs to talk to whom and how often people talk to each other um so you can see some groups grouping between different parts of the team.
Yeah so is there is um how how do you actually do that?
I mean, as a software architects, um we or as a software architect, I'm used to drawing boxes and and arrows between them.
But you know, I also understand that uh it's good to have some semantics and some some um clear ideas.
So is there like a standard for these things or is there any inspiration that I could take from sorts of things?
I think ours is pretty much made up what we basically developed just working and trying to answer these questions, like who is collaborating with whom.
So it's just a graph of people and asking people with whom they are collaborating, how often, and figuring out okay, there is like a lot of connections for this person, but a little less for this person, and they kind of belong together, and you can see it on the graph of how they are connected, so how strongly also.
So basically you would have like every box would be a person, then you put we would draw the the communication.
Yeah, we would have like the avatars out of the we would print out the avatars from MSTs and just we have the graph.
We have the people, and then like we ask the people uh interview one by one, like how do you collaborate with, and then after the graph ready, then tell them, hey, this is your communication map.
What do you want to do about it?
If we just play it like this, this person in the red dots gonna suffer.
Yeah, and then how do you want to make it works?
So you're actually doing that in one-on-one interviews.
So you talk to each person and then put that in a large diagram, and that would be the foundation of the decisions you're making.
Okay.
Yeah, that's that is visualizing for the people, people forces.
We also did uh several things from the architecture forces and from product forces.
So it was a lot of interviews to create those all those crafts to be happened before the workshop happened.
And we also, agile coach, need to do the homework for that.
And then on the day themselves, like this is what you are doing right now.
This is the situation right now.
What do you want to do about that?
Of course, they will ask, like, what is your opinion as an agile coach?
Yes, we can say that, of course, but at the end of the day, the split or the merge it and the adoption of it, it needs to come from the team if we want it to be successful.
Yeah.
Um that's the only graph that you're creating these communities communication growth?
Because you just said that there are actually quite a few visualizations that you're doing.
Quite a few, yeah.
Okay, so can you give some other examples about what you're doing?
For example, um, reasoning about who is working on which parts of the system.
This for this, you can use architecture diagrams and you can go as deep as you want on granularity.
Right.
As you need basically to visual to have a cohesive, interesting conversation, because you don't have to like mark every component and then you can just group them together and say this is like the domain of these people that are usually involved in this area of the work, so that they can see that and they can see that and contrast it with the communication map.
Is there like is there some difference or difference?
Between those two.
Do we see yeah, exactly differences, similarities?
Um also if you have a sorry, just as a follow-up.
So you're building you're creating an architecture diagram, and then you would add the people who are actually working on the individual parts of the system.
We wouldn't be creating the architectural diagram because we're not doing this part of the work, uh, but we would rely on any diagrams.
We would have conversations with either it's an architect, depending on if there is a role like that in the team or the tech lead or someone that's like really knows about how things are structured to figure out okay what's the components that are important and how people spread across these components currently.
Also, is there any vision to change this constellation in the future?
Then we contrast that with the stories and the backlog, which basically points towards the product vision.
So there would be some sort of product vision, there would be a technological parts of the product that would also have its own kind of vision and direction, and then there would be the people, how they collaborate and how they wish to collaborate.
Yes.
I'm sorry, no, I don't know.
There's also like from perspective, like we also can create the stakeholder maps because uh the stakeholders was also interesting to know, like um, like after doing all those uh visualizational stuff.
We also found out like in one of the group is that oh, apparently the stakeholders are behaving like a tree groups of stakeholders with three different intents with a team.
So it is also interesting to see.
And one of the decision to have like uh to okay, this is talking about the fluid team.
Okay, then for this specific team, three backlog is makes sense.
But for the other team, single backlog is makes sense.
Like yeah, it's really depends on the team.
It's yeah, because the three backlogs would represent those three um stakeholder groups, yeah.
So it's it it's actually you're you uh it seems that you're that this is uh going back to the three forces that you mentioned, right?
Uh architectural people and and product.
So that's great.
Um so I was yeah, so that's maybe a question because you're you're saying um that's the title of your talk, right?
Splitting without splitting.
So I are you even advocating people uh splitting because it seems to me that you're basically saying, okay, so there are these 25 people, which seems to be like the in the new magic number, not seven, but rather 25.
And then you build up some some structure around that uh to have them somehow collaborate.
So we actually love to have more data on uh this number because we only have experiences what what like four that we did that video a little bit more, but um we'd like to know if there is any anything to this.
But yeah, go ahead.
Go ahead.
This is splitting or not splitting, what should you do?
Um I guess there is a mixture of both, like you have to sometimes overcome the resistance to splitting some parts of the work into their own focus zones or zones where people can really deep work, because it still remains true that deep work is easier when you have less people involved, and you want to benefit from this insight.
So you still want to have the benefit of deep work within a small group of people, but then answer the question whether or not it really makes sense to separate them completely, like to have them separate and develop their own cultures over time, develop their own principles, decision making, logic, etc.
Does it make sense for this to happen, or does it make more sense for them to remain as a cohesive unit and only separate in the cases where it makes sense?
So this is the questions I guess needs to be answered.
Yeah, or if you want to split, yes, but uh please split it wisely because the people is gonna suffer if you split it unwisely.
So um one question is um that that comes from my mind is so let's imagine that we have some project where there are a hundred people.
So what do I do now?
Um or and and um there is a different question, or maybe that's even just rephrasing the question.
So is it that you don't have that in your company for some reason that there is like a unit of twenty-five people, and that is why why there is this magic number?
So you know what I'm what I'm trying to to ask is basically okay.
So if we have a hundred people and you have we we really have that magic number of twenty five, then it would be natural to like split it into four groups of twenty-five.
And that's why I'm wondering what you would do.
So maybe just a quick uh clarification that it's a little bit because of our context that we are these these big units, because a lot of the work involves different wor uh roles, like a little bit more roles than you would typically have in a development team.
And the complication with having a big corporation, having a lot of double hiring, having a lot of these uh things leads to this type of development.
Um different company, different scale can have a different constellation.
And if I'm not sure if I understand the question about the hundred people quite yet.
So if you have a hundred people, is it the best thing to just divide them in 25 in groups of 25?
Is that a little bit?
Let's just uh let's uh stick to the other point first.
So it seems what you're saying is the reason or that's that's rephrasing.
I'm not sure whether it's actually correct.
So what you seem to be saying is 25 is not a magic number.
It's just that our company for reasons like we have all these different roads has these units of 25 people and we somehow have to structure them this is what we came up with, which is different from what I understand about about Scrum and these these seven people where they argue that seven is like a natural number for a group of people to collaborate.
So that seems to be this is what why what I understood I'm just wondering whether I understood it correctly.
Well maybe this comes to the um question of what does this mean to collaborate effectively what are the preconditions you put this group in and as far as I understand it it's like a cross-functional team that you have a lot of full stack type of skills everyone can do anything.
So in this case basically everybody is involved in everything more or less in this smaller group.
So this would make really sense then because then everybody's communicating to everyone.
Your communication map would be like the theory communication map.
But when you grow like this, the communication map does not look like the worst case scenario of the communication map between 24 nodes.
It looks differently because people cannot sustain this.
That's not the case, right?
Because when we have 25, 20 people, even not 25, we have when we have 20 people, we know that we have to break.
That was the point.
And how can we still have connection with the other part of the group to uh to deliver something meaningful and not isolated with and of course um the magic numbers from Scrum is seven or 10, like plus minus 10, I guess now what's in the Scrum guide.
And um we want to make them small enough to collaborate within their groups, but we want them to still have a relationship with the other.
Because at the end of the day, these 25 people involve to support one product.
Which is actually uh was if we go back to history, uh, we have a lot of specialized roles, right?
Like like Fernandek and QA and blah blah blah.
And it's easily eight to nine person within a team.
And of course, you want to have a risk management to that.
Like you don't want to have one person, only one person.
People on leave, people get sick, people leaving the company.
So you want to have them in pair.
And that's already 16, easily 16.
And this is in our company context matter, because we are not only talking front end and back end.
We talk about front end, back end, QA, data science, MLE, ML ops, so on and so forth.
Sorry.
So there's so many specialized roles.
Of course, easiest part is to tackle the special role.
Like, why would you want to have a specialized roles at the first beginning with, right?
But to influence the specialized roles, that needs a bigger voice, especially in the enterprise context.
30,000 people, then you have HR involved, how to how to contracts and all stuff.
Probably it's easier for startup context when hundreds or two hundreds of people, but it's not so easy in the enterprise context.
Yeah, and that is why I thought that that the question with uh 100 people doesn't really make a lot of sense because what you have what you seem to be saying is the twenty-five is just what is given, and we we have to work with what is given, and this is our solution.
So, and I don't see any advice that says okay, twenty-five is the the new new number that we should aim for.
It's a it's an experiment that we do, and that we did with uh twenty-five people in a team.
This was the basically the position that we were we found.
Yeah.
And and of course, like uh if if it's the number is going up like hundreds when you saw it, then there's it's the same thing.
We want to understand how's the product behavior.
Obviously, if it's a product that's required a hundred person to do something, there will be a module inside the product, right?
Will that be max sense?
Of course, with a lot of graph like from people perspective, from stakeholders' perspective, from architecture perspective, will that be max sense to group them by module, for example?
Could be.
We need to have more context for that.
Yeah.
And I have another thought, like um when you are building a product, if you look at it from the outside, um, it's one product, like for the customers it's one product.
So but what happens in the inside is we know that we ship our org chart or our communication channels, whatever.
So do you really want your customers to experience the divide?
Or do you want the customers to experience a cohesiveness?
So, and if your teams are very split, you're very focused on this small teams, a lot of separation, then it's probably more likely that your customers will also experience this separation in the product experience.
Yeah.
Um, so there is one final question.
We are slightly over time already, but um I didn't want to drop this.
It's also by no name, and it's also one of the questions that I noted down, but I uh haven't asked yet.
So you mentioned team topologies in the abstract, not sure I missed it.
What was the connection with this?
I believe this was around the um communication map.
So basically figuring out who is collaborating with whom in the team.
Also, we did this experiment to collab um collaboration when we came across cross-team collaboration.
So it was not just internal collaboration, but we tracked a little bit.
There is their dependencies with other teams.
Does our delivery depend on the delivery of another team, or vice versa?
So we use these ideas from team topologies as well to help visualization.
When we talk about this with the teams, does it make sense now to split?
Um, or is anything gonna be more complicated if we split it?
Because this is how it's gonna look like so you're not using the streamlined team platform teams and these patterns exactly.
So we are cherry picking of things, which seem to be like at the core of team topology, so it's of thoughts.
So we would be using team topologies like ideas in other decision making, but exactly on this question, are we splitting or not?
We are using only the parts with the Conway law and the collaboration mapping.
So we we're solving for this problem, and for this to solve for this problem, we don't need like to think about stream.
Is it stream-aligned?
Is it complicated subsystem?
Or at least we didn't find this to be the useful part.
But the useful part was about the collaboration paths.
Okay.
Okay, so final comment by no name, and I would like to second that.
Thanks again and enjoy the conference.
Thank you.
Thank you.
Thank you so much.