Split scrum teams feature based

Theoretically, the dev team is to decide how to split, not to adapt a decision made for them. However, it doesn't mean nobody should guide them
I'd recommend asking the dev team questions, like "if I ask you to split the backlog items by complexity/technology/hierarchy/etc. how many groups would you define?" or "what are the dependency you see with implemention of these backlog items?"

If all the tasks are really independent from each other, I'd recommend having larger teams rather than smaller.

And, BTW, where did you read 5-6 is an ideal? Scrum guideline recommends 3-9.

P.S.: Here're a relevant topic you might like to read: https://www.scrum.org/Forums/aft/680

Regardless of how the teams are put together, they will need to collaborate on delivering an integrated release-quality increment each and every Sprint. With anything more than 2 teams a Nexus is likely to be needed to co-ordinate the associated dependencies.

So, if a Nexus was to be implemented in your situation, how would it want those integration dependencies to be resolved? How would Development Teams be assembled in order to make the integration challenge easier to manage?

Hi Ejej,

I understand that there is limitation on how much you can explain online and how much I can visualize. Let me explain my experience about similar situation which might help you.

If there are multiple items of similar type of technical work, try to group them in feature/epic such that there is minimum interdependence. In order to create cross functional team, check what are the skill required to complete each work item. Based on timeline available and resources in hand, you can decide how many cross functional teams can be formed. It looks like you have full stack developers who would like to finish work item completely on their own. To increase level and need of collaboration, suggest team to swarming so that when one developer is coding other will create test cases or test data. If required, use pair programming or pair review so that knowledge is available with team rather than any individual.

Thank you three for your input. It definitely helps. What I learned so far is that the team should try to find itself by identifying how they think is the most efficient way of finishing work. That is what we will try tomorrow. I also like the input that not every developer needs to do all tasks of one story. They kind of know that but not to the full extend.

And I will give myself and the teams more time to prepare the split to be fully prepared.

I will let you know how it developed.
Thanks again.

Please update with the actual outcome after your next sprint

Hey everyone,

I owe you an update on the transition.

We are in our second sprint after the transition. We now have one components team for base development, which is currently mainly doing bug fixes, because it is the bottleneck for the other teams. This teams consists of seven team members.

Then we have three feature teams with four members each.

The result is: overall I am happy with this current state. It worked out pretty well. The teams do work together, don't block each other and talk to each other. And today it happened that the team members started to identify issues themselves (one was taking note of the things that hold him back from his actual tasks yesterday. I was able to talk to him about those issues and worked out solutions to solve those.)

There is still one person who is blocking and tries to "argue" against all this. It it very tough to make him a real part of a team and I fear that his behaviour is slowing his team down. But at least the other members don't listen too much to him and try to push scrum instead.

So overall I feel like we are going in the right direction, although I know it would have been better to get a coach in the first place. If this big project is over, I definitely plan to do this.

Try to find out why that person is against the new arrangement. What are his apprehensions or motivation? Ask for Scrum adoption impediments during the Sprint Retrospective meeting and how can the team or Scrum Master resolve them.

I recently attended a great meetup that was about working with difficult people. There were many great takeaways, but one that really stuck with me is as follows:

It is extremely rare to come across someone who just likes being a jerk. In almost every instance where someone is being combative, or difficult, or poisonous to the team, the key is to realize that their behavior is a means to an end. What is their motivation? What are they hoping to achieve through the behavior? What is their end-game?

Once you gain that insight, you're much better equipped to address that behavior (and that person) going forward.

Good luck.

I talked to him personally. He mainly says that he thinks "all this story writing and those meetings are a waste of time", but he immediately admitted that he does not have a better solution.

I personally feel that he does not like the changes of roles. He is still the team leader of most of the guys of the feature teams. Due to the small self organising teams, his role does not have that much of an impact anymore.
And I feel like he fears that he is not able to keep pace with all the new changes. I tried to work on this topic by helping him on specific topics. But on the other hand, I don't want to treat him like a special case who is the only one who needs assistance.

I don't feel like I can solve this on my own or at all. My hopes rely in all the other teams and team members. When he sees that 17 out of 18 have improved on productivity and quality, he might start to reevaluate his role and behaviour.