This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
Okay, so welcome to another episode of Software-Architektur im Stream from the AgileMeets 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 Tsvetelina and Pricillia 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 Pricillia Gunawan, so I’m an Agile coach together with Tsvetelina in NIQ.
So I’m also an Agile coach in NIQ.
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 2-3,000 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 science and different types of roles in our company.
Yeah, we have a lot of specialized roles, not only 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 personnel, and so on and so forth.
So we are very diverse.
I think one interesting point why do we have that much is because a lot of people that are working in data science as a data scientist role in our company is coming from mathematics and statistics background, and then they learn how to code on the go.
And then we have people that are very strong at technology backgrounds working in front-end, back-end, and also QA.
And of course, within our company themselves, there are many cases where they’re cross-moving across different titles or moving and being open as well to take up a new challenge, even if their roles, data scientists, for example, and then, oh, I can fix the front-end box, and why not?
Just do it.
So we also have that kind of situation happens, but generally, this is what happens in our company.
A lot of complexity within the role, yes.
And so from the conversation that we had before, I understood that your company is actually not aiming for full-stack developers, so it’s sort of intentional that you have these different roles like back-end and front-end engineers?
Yes, and somewhat.
You can say that we are kind of aiming there, but you cannot just do it in one go.
You need to give people opportunities to learn, to grow, etc.
So it’s very much encouraged, but there are also some things in the way that you need to overcome in order to get there.
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 operate in a certain way towards a more cross-functional, com-shaped type of a company.
Yeah, I found that just interesting because there is this move towards full-stack developers.
Yes, there is a move, yes.
And you 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 it seems that sort of the go-to solution to that would be to take one data scientist or multiple and assign them to each team and then you have a cross-functional team and then you’re done.
So you’re doing something different.
So what are you doing different and why?
I want to take that one.
So in our company case, the data scientists are very much involved in not only business and operations support system.
Yes, they are kind of embedded within the team for that, but they’re also doing a lot in research within the data scientists themselves.
And that research is, if we refer back to the Double Diamond, they’re much more involved in problem space and then they become the stakeholders of the engineers in the solution space.
Somewhat, yeah.
And 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.
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, but sometimes it’s more novel stuff.
How do you bring this in this Double Diamond structure?
So what did you find works best for you to 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.
And in the industry, there is this obvious solution to a bigger team that has a lot of different roles.
And this has grown beyond, let’s say, 20.
The obvious solution is, hey, split this team.
Why not just split them?
They will be more effective.
They will have bigger calls.
They will have nicer discussions.
And this is somewhat true.
But then on the other side, you have to really consider, is this situation you are in, is this team really able to split in a way that’s going to 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 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.
So what is the size of the team that you’re talking about?
So is it this magic Scrum number of seven, or is it something different?
No, we start with, probably we were starting it with seven or 10 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 we should work together, or what will be the best ways of working for us, whether we split, but if we want to split, let’s split wisely.
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, four different cultures as well.
And how every single team is probably creating the same pattern, you can say so, but the approach is different.
Their ways of working approach is different.
So can you give a concrete example?
I think in the conversation that we had before, you gave that example about those three backlogs that were shared across all the people.
Oh, that was a fluid thing.
Yeah.
So for this team, we have a team that’s doing a shop management for that.
And then this, oh no, for Wolfie, this team is doing auto matching.
So they don’t have front end.
They’re having only data scientists within them.
And they have three different backlogs for that, because they need to be involved in three different streams.
The business operations support system streams, and then the data science streams that is much more related to research.
And then the other one is the engineering streams.
Our engineering practice will also have certain standards that we all team have to fulfill as one company, right?
Security, for example, functioning, for example, and so on and so forth.
And they have three different backlogs, and depending on the priority of its backlog items, they will re-team themselves against and against every single sprint.
So I think this is a very provoking idea for these 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 sprint one, we need certain items ready for BOS.
There is 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, oh, we need more people on his side, and then 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 tackle the engineering backlog while the others are still maintaining others.
Or also in other cases, is that maybe sprint three, that data science that’s doing the research, oh, I think this is important for us to do these things, and let’s implement it this way.
And other data scientists, how we need more help, you are the only one who has that knowledge.
Okay, then I will do it together with you, with this knowledge sharing and all that stuff.
Then he pulled back from the data science streams, go to the BOS.
That also could potentially happen.
And they keep reteaming every single sprint, we could say that, because they have touchpoints.
They have many touchpoints in the refinement, in the dailies, and so on.
So they can sense what is coming, they have these refinements, because, of course, they need to figure out what the work is going to be.
So they can already sense where it’s going to be more need, where it’s going to 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 going to be this situation.
And then we do the sprint planning according what we learned during the refinement.
Okay, so if I understand correctly, it means that every sprint, 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.
I mean, one of the reasons, so at the end of the day, we are in a stream that also talks about software architecture.
And one of the reasons why 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 it probably means that everyone needs to understand everything.
So there is 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.
What we’ve seen is that not every team is interested in understanding everything.
For example, we had a team where they were not interested in the how of the other sub team, like 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 activities that are very narrow and very focused.
They were more interested into the what than the how.
But then they would still have some common guidelines, like some of the how would be common, like coding standards, 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’re 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.
Probably yes, probably no.
It’s like in the middle.
Exactly.
And it’s also not working for every team.
That’s why we have three other examples for three other different teams.
But in terms of the complexity, whether you’re 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 going to be dependencies.
It’s one system.
We want to try to decouple as much as we want.
But at some point, if you’re working on one system, you have dependencies.
Otherwise, it’s like meaningless.
Anything that doesn’t have dependencies is kind of a little bit too simple.
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 these kinds of things.
Now, who sets them in place?
Because you’re saying that the teams are basically self-organizing a lot, so people would flock together to the backlog items that are the most important ones.
So, how do you deal with this definition of none and these other things that somehow need to be decided?
Want to 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, every team has their own agreement.
And we, as a scrum master, as agile coaches, we are facilitating that agreement to happen.
And also, involving people to say like, what do you think about this?
Are you agree?
Are you really agree?
Because when it’s already written down…
Does it make sense in our context?
What the company is suggesting or recommending, does that make sense in our context?
Is our context in any case different?
So, we let people make some intelligent decisions based on their own context.
And it’s also like…
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…
This is this balance between how much 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 ball.
And within this cohesiveness, we have some rules that might be different than the rules that the other cohesive ball 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 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 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 in order to come to these conclusions, to set up these rules, it’s influenced by architecture.
But you said that you are agile cultures, right?
So, would you consider that truly the domain of an agile culture or is that something that you rather feel is something that a software architecture would do?
Or does that distinction not make any sense?
So, you mean the setting of standards like coding standards?
Yeah.
What you just described or what I understood from what you’re saying is that you have to look at the cohesive stuff, which is some part of the software architecture, and that influences 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 cultures, while the other part, like the cohesive stuff that you were talking about, you could argue it should be hidden from you because you’re not a software architect, right?
You’re agile cultures.
So, I’m wondering about 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, it’s going to 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 when a team, for example, wants to make a decision on how we collaborate.
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 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?
And on the third force, which is 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 scope are also incredibly important.
And for us 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.
And I have to admit, what I liked about what you’re saying concerning these three forces, when we had the conversation before, is that you’re having people as a first-class citizen in there, like on the same level as architecture 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 have to listen to them and make sure that they’re comfortable with that.
So, I think that’s great.
Now I lost track.
So, that’s the general concept that you would abstract away from that, right?
Yeah.
Okay, and that you could also use in other environments.
Yes.
So, we already spoke about fluid teams concerning that concept where you said that there is like a team that flocks together at certain parts of the backlog.
I understand that there is also 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 is it and what problem does it try to solve?
So, it’s a lightweight way of working.
Okay.
And it is very easy to implement, and it is very easy when you scale or descale from scrum without adopting a lot of many things.
Because it is basically 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 make sense for our team perspective to implement.
We like that so much.
So, we have a team that consists of 21 people and doing applied detection.
So, in this team, beside the business operations support system, of course, they have like a framework and QA for the business operations support system part.
And they have a lot of the brain, the data, and also the AI model was created inside that by the data scientists as well.
And we have another thing, and this is architectural, like we have something that’s called in the middle, we call it the glue.
It is gluing everything, also including gluing this system into an external system.
So, we have a lot of people, various there.
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 a question, 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 asked around and like, how do you like things will be?
And they said like, we don’t want scale.
We don’t want to, we hesitate to split because we don’t want to scale.
We hate it.
Dogma.
It was like from the team themselves, they say that.
So, all right.
So, we need to find something else that’s lightweight, that’s easier.
Then we came out some elements of it.
And let’s see what we have right now.
Okay, which one that is even in the events that is pain you so much.
And then they point out, oh, sprint planning pains us so much.
Refinement pains us so much.
Retrospective is superficial.
All right.
And if that’s the case, we can have that in two, like sprint planning one, sprint planning two.
The what together.
And then we choose who’s going to do that, like the teams that are going to do that.
And then the how part.
You decide your own.
Of course, we do have backgrounds that I told you like data scientists coming from mathematics and scientists of statistics backgrounds.
There’s also the one engineers that is much more familiar with the BOS system.
So, there are certain things, the items that naturally, ah, we will take this and so on and so forth.
But then they, ah, they work in a sense of like 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 a overall retrospective once per quarter.
And after that, they are very happy with it.
And we gain like plus 63 points of their satisfaction survey.
We have satisfaction survey for that.
And it works for this team.
May not works for other team that’s purposely say we like scale, for example.
So, it really depends on the team.
So, then let’s also go back to the forces that Tsvetelina was talking about.
Like the people is in the same status with product and also architecture.
But it’s also interesting that basically all of our teams don’t like SAFe.
And we ended up still with some lot difference.
I mean, it’s true.
Our teams don’t like the bureaucracy.
And I think you can ask any team and they would be like this bureaucracy is too much.
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 way that it fits it.
So, we end up with four different solutions, actually.
Even though you could say, oh, they all hate SAFe and then let them do something else.
So, under the hood, it’s always like this.
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 really different ways, cherry picking of different frameworks or schools of thoughts on how to manage and organize work in software development and then craft their own solutions.
Yes.
So, if I understand correctly, what you’re saying is that this is a framework like SAFe to scale agile processes.
And you took some inspiration from that, like this two-faced ceremony that you were talking about.
And then you cherry picked the stuff.
And the other thought that I got is that from a management level, you’re sort of doing SAFe while in fact you’re doing something different.
And I thought that was quite interesting when you talked about that beforehand because I can totally see how management is satisfied with that kind of abstraction, where they basically say, okay, it’s SAFe, so we are SAFe, while in fact there is something different happening.
And it’s also interesting, I think, because it correlates with my experience that 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 things would be to ask people who are doing SAFe what they are actually really doing.
Yes, that’s right.
So, there are some questions in the chat.
Let’s see.
So, there is a very long one.
I’m not sure whether I want to check that right away.
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.
Different.
Yes.
Some was very quickly, others were taking over a year to actually have some improvement.
I can speak about one team where it was a bit of a different situation where we had two teams that were working in different products and then there was a decision to merge them because it did make some sense on to 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 merge just 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.
Which basically means that it varies a lot.
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 still improving so you haven’t arrived at the right model and you probably never will.
Okay, so there is another one by the same person.
No name is the name.
No name dash some random characters.
Did you have to argue with management for the efforts and time it took to get it right?
Why did you give that to me?
So, the answer seems to be no.
Yes and no.
No, in the same time.
Because we have four teams that we’re going to talk about.
It really depends on which teams.
Some teams, when we have a very open-minded manager, have very open-minded leadership that you could…
Can we let the team…
Can we include the team to be involved in the solution?
And the leadership was like, yes, so we can have these experiments.
And the team was also very on board, very involved.
Then no, of course, right?
We don’t have that.
So, the pitching and 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 is the data after.
I’m talking about the survey data.
And all is good.
Normally, if it’s emerged from the team themselves, it will be a very fast experiment and it will always be good.
That is the best.
But if it’s driven by other forces, then it was not a very happy experiment.
And then we also have the data.
That’s when we have to pitch.
And then gave this as a reality to the leadership themselves.
Like, hey, look, this was before.
This was after our experiments.
Here, what do you want to do about it?
Do you still want us to follow your way?
Or you want to include the team inside this experiment?
And it also varies depending on this leadership answer.
Yeah, depending on the person and how open they are.
So, it seems that these surveys and their satisfaction surveys, right?
That’s what you said, seem to be crucial.
So, can you say a few more words about that?
Is it just like how happy are you at work or is it more complex?
It’s a little bit, yeah.
So, we used this DX survey 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 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 surveys with the team, which requires a lot of trust and a lot of open-mindedness as well.
And apart from that, if we are talking about the metrics that we have, we also have agile practice metrics, the agile maturity metrics.
We only rolled out recently, but we see the potential on that.
How to say that, like how is the practices?
Are you happy with these practices and all?
There’s much more people and process-oriented.
Okay.
So, you were talking about, I think, DX surveys.
So, that’s a standard for these kinds of… Developer experience.
Oh, I see.
Okay.
And that’s like a standard, like you would find it on the web or… It’s 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, it’s been rolling for about a couple of, two or three years, I believe, already.
And it’s like your decision or is it something that has been introduced 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, what we were also thinking.
Like, we are happy that it’s based on Dora, which is great, very progressive ways of measuring things.
And it’s focused on the experience of the developers rather than on vanity metrics.
Yes.
Yeah.
Okay.
I’m just wondering because it seems that 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.
It’s a different, yeah.
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 people’s lives harder, then you’re not going to get a fair measurement.
So, you can’t use them.
You still have to do it in the retro.
Yeah.
And obviously, you can cheat any metrics.
Yeah.
Yes.
So, sorry.
The response by NoName 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.
Yeah, we can try, maybe see what comes out of that.
All right.
So, it’s by Muhammad Yusuf, and he says, consider this 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.
How many in total was that?
Yeah, I was just wondering.
So, it’s six, 12, 18, 20, 23.
Okay.
Okay.
At least.
All working as one scrum team because the application architecture is microservices-based, where some services are common and others are based on different functionalities.
The technical manager is taking technical decisions for all related functionalities.
Combined planning, combined scrum, combined retros, and three reviews take place.
So, there is no question.
I think that’s, at least I don’t see any here.
Maybe he wants to ask how to deal with that.
How to deal with that, right.
Yeah.
So, one thing that we would always be using as advice is visualize everything.
So, visualize what’s your architecture, like a rough architecture, where is the different bigger components, where different people would be collaborating.
Which people are 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 where in the product development lifecycle are you?
These 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 is going to be almost emergent out of what you visualize.
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 going to be their work.
Yeah.
And that touches an interesting and a good point that I wanted to dive deeper into.
So, why is visualization – I took that also as a note when we prepared 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 are talking about 20 plus people.
You remember this graph with all the communication lines?
Yes, yes.
So, 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 head to comprehend.
So, putting it into an actual visual graph. space.
It’s helping to reason and see patterns that you cannot see if it’s only in your head.
Yeah, and I guess the team is also have been mixed for so long.
So you can imagine them like they’re already like a salad, right?
So it will be hard for you 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 have a part of salad.
But now it goes back to your team, in your context, you know more than we do.
And maybe one bowl, it’s mixing between the greens, the tomato, but without the cheese, for example, and the other bowl is with the cheese.
That also can be an option.
It’s still cross-functional, right?
In that sense.
It doesn’t need to be completely, 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 fulfill that, you know the context more than we do.
One other thing we wanted to avoid often is to have people that need to switch between teams.
This problem can be very painful.
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 principle, as much as possible, avoid.
Because we have that, like why Svet mentioned that, like maybe one of our teams is that we unwisely split them in the first place.
And then it’s resulted that half of the team is shared because they’ve been mixed for so long and they’re creating a small subgroup within them.
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.
So they’re very crucial in both parts of the system.
So then when it was split 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 different settings and different people and different circumstances.
So I think that’s a very good point and you’re illustrating how not one size fits all.
But coming back to the visualization.
So visualization of, I think 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.
So you can see some groups grouping between different parts of the team.
Yeah.
So how do you actually do that?
I mean, as a software architect, I’m used to drawing boxes and arrows between them.
But I also understand that it’s good to have some semantics and some clear ideas.
So is there like a standard for these things or is there any inspiration that I could take from sorts?
I think ours is pretty much made up of what we’ve 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’s 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 strongly also.
So basically you would have like every box would be a person, then you would draw the communication.
Yeah.
We would print out the avatars from MS Teams and just have a graph.
We have the people and then we ask these people, interview one by one, like how do you collaborate and then after the graph is 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 is going to suffer.
And then how do you want to make it work?
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.
We also did several things from the architecture forces and it’s from product forces.
So it was a lot of interviews to create all those graphs to be happened before the workshop happened.
And we also had 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 and the adoption of it, it needs to come from the team if we want it to be successful.
And that’s the only graph that you’re creating, this communication graph, 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 would use?
For example, reasoning about who is working on which parts of the system.
For this, you can use architectural diagrams and you can go as deep as you want on granularity as you need, basically, 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 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 some difference between those two?
Do we see exactly differences, similarities?
And also, if you have a…
Sorry, just as a follow-up, so 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, 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 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 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.
Correct.
I’m sorry.
There’s also, from perspective, we also can create the stakeholder maps, because the stakeholder source is also interesting to know.
After doing all this visualization and stuff, we also found in one of the groups is that, oh, apparently the stakeholders are behaving like three groups of stakeholders with three different intents with a team.
So it is also interesting to see.
And one of the decisions to have like, okay, this is talking about the fluid team.
Okay, then for this specific team, three backlogs make sense.
But for the other team, single backlog makes sense.
It really depends on the team.
Yeah, because the three backlogs would represent those three stakeholder groups.
Yeah.
So it’s actually, it seems that this is going back to the three forces that you mentioned, right?
Asexual people and product.
So that’s great.
Yeah.
So that’s maybe a question because you’re saying that’s the title of your talk, right?
Splitting without splitting.
So are you even advocating splitting?
Because it seems to me that you’re basically saying, okay, so there are these 25 people, which seems to be like the the new magic number, not seven, but rather 25.
And then you build up some structure around that to have them somehow collaborate.
So we actually love to have more data on this number, because we only have experiences with like four that we did a little bit more, but we’d like to know if there is anything to this.
But yeah, go ahead.
Go ahead.
So are we splitting or not splitting?
What should we do?
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 question I guess needs to be answered.
Yeah.
Or if you want to split, yes.
But please split it wisely because the people are going to suffer if you split it unwisely.
So one question that comes to my mind is, so let’s imagine that we have some project where there are 100 people.
So what do I do now?
And 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 25 people and that is why there’s this magic number?
So you know what I’m trying to ask is basically, okay, so if we have 100 people and we really have that magic number of 25, then it would be natural to split it into four groups of 25.
And that’s why I’m wondering what you would do.
So maybe just a quick clarification that it’s a little bit because of our context that we are these big units because a lot of the work involves different 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 things leads to this type of development.
Different company, different scale can have a different constellation.
And I’m not sure if I understand the question about the 100 people quite yet.
So if you have 100 people, is it the best thing to just divide them in 25, in groups of 25?
Is that a little bit?
Let’s stick to the other point first.
So it seems what you’re saying is the reason, or 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 roles, has these units of 25 people and we somehow have to restructure them.
This is what we came up with, which is different from what I understand about Scrum and 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 I understood.
I’m just wondering whether I understood it correctly.
Well, maybe this comes to the 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.
It is.
I think we don’t want to advocate one team 25.
That was so wrong.
That’s not the case, right?
Because when we have 20 people, even not 25, when we have 20 people, we know that we have to break.
That was the point.
But how can we split it wisely?
And how can we still have connection with the other part of the group to deliver something meaningful and not isolated with?
And of course, the magic numbers from Scrum is 7 or 10, like plus, minus 10, I guess now, was in the Scrum guide.
And 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 involved to support one product, which is actually, if we go back to history, we have a lot of specialized roles, right?
Like Frenambic 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.
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 it 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, MLOps, so on and so forth.
So there’s so many specialized roles.
Of course, easiest part is to tackle the specialized 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 force, especially in the enterprise context, 30,000 people, then you have HR involved, how to, how to contracts and stuff.
Probably it’s easier for startup context when hundreds people, but it’s not so easy in the enterprise context.
And that is why I thought that the question with 100 people doesn’t really make a lot of sense, because what you seem to be saying is, the 25 is just what is given.
And we have to work with what is given.
And this is our solution.
So and I don’t see any advice that says, okay, 25 is the new number that we should aim for.
No, no.
It’s an experiment that we do.
And that we did with 25 people in a team.
This was the, basically the position that we found.
Yeah.
And, and of course, like, if, if it’s the number is going up, like hundreds, when you say, 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 require 100 person to do something, there will be a module inside the product, right?
Will that be make sense?
Of course, with a lot of graph, like from people perspective, from stakeholders perspective, from architecture perspective, will that be make sense to group them by module, for example, could be, right?
We need to have more context for that.
Yeah.
And I have another thought, like, when you are building a product, if you look at it from the outside, 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.
So there is one final question, we are slightly over time already, but I didn’t want to drop this.
It’s also by no name.
And so it’s one of the questions that I noted down, but I 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 communication map.
So basically figuring out who is collaborating with whom in the team.
Also, we did this experiment to 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, visualize collaboration paths, and then lets us do Conway law and all of these consideration when we talk about this with the teams, does it make sense now to split?
Or is anything going to be more complicated if we split it because this is how it’s going to look like?
So you’re not using the streamlined team platform teams and these kinds of things which seem to be like at the core of team topologies.
So we’re not using these patterns exactly.
So we are cherry picking of different ideas of different schools 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 are solving for this problem.
And to solve for this problem, we don’t need to think about is it streamlined?
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.
So final comment by Nonim and I would like to second that.
Thanks again and enjoy the conference.
Thank you.
Thank you.
Thank you so much.