How should I arrange my team in my organisation?

Recently I had attended Bas Vodde’s training on Large Scale Scrum (LeSS) and I have to admit that there is always something to pick up in his course, regardless how many times I had joined. We spent quite period of times in discussing how organization could structure their teams and what difference it could make. What are the common ways in industry, and what are the counter intuitive ways from his point of views, etc. This post will be highlighting difference of component teams and feature teams. If you are interested to know how much difference it could make, it might be worthy to spend next few minutes on this post.

Component Teams

Biggest characteristic of this arrangement is grouping developer into a team which is specialized in modifying specific component of the system. Team is expected to work with few other component teams in delivering a feature based on their “specialization”. A very common example would be collaboration of database team, backend team and front end team to complete a feature.

This common way of arrangement invites several questions from our discussion. (Refer to image for the context)

• If feature A require changes from team A and team B, and feature B require changes from team B and team C, which feature should team B work on first?
• Should Team C starts working on Feature B while Team B work on Feature A?
• If Team C starts working on Feature C, does that mean my organization is not delivering most valuable item at the time?
• If Team C starts working on Feature B, should the team C continue to Feature C when their implementation is completed? What will be the effect if they did and what will it be if they don’t?
• When will be the good integration time for Feature B between both teams?
• Will it expensive on Team C for switching context between Feature B and Feature C?

Feature Teams

Developers are grouped into a team which is specialized on certain business development areas. Each team is expected to have enough capacity to complete a business feature that fall into their area. Example of this would be business report team, inventory team, payment team. We found that there is much better flexibility in terms of delivery works with this arrangement. Since each team will be completely responsible in developing a feature, there is less dependency between teams when delivering a feature. However, this arrangement does not come easy as well. These are popular questions about this arrangement:

• Wouldn’t that be too much thing need to be learnt by team, since they need to work on most of the features? Training costs are too high!
• If there are so many teams modifying the component, will that be messy and prone to errors?
• What if there is component which involving risk of business sensitivity? How do we tackle those?
• Does that mean there is no database team? Who will be in charge of those then?

How do we handle dependencies then?

Since both ways of arrangement will create certain level of dependencies, how should we handle them then? One of insights that I get from the training was, “If you can’t eliminate dependencies, make sure it happens at the same time over all teams”. How would that help? When dependency happened at the same time, teams will talk about it and resolve it one go, and then move on. There is less interruption on coming back to previous works and making adjustment while working on new item. Those interruptions are costly.

After all, I don’t think there is a single solution that solves all type of problems. Thus, depending on context that you had, adaptation on either component teams or feature teams would be required in any of the organization. Who knows a mixed would be good option for you?