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?

Component Team

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?

Feature team

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?

6 thoughts on “How should I arrange my team in my organisation?

  1. I tend to use Feature Teams (see https://agilesetchu.wordpress.com/agile-roles-in-setchu/), but not quite as you describe. Instead, my feature teams are cross-functional and only persist for the duration of the feature.

    Outside of a feature (project), they all exist within their specialisations from an organisation structure perspective. So there’s no additional training costs required.

    If anything, this single feature, multi-skill approach has the effect of providing exposure to different concerns, whilst allowing people to focus on their specialisation.

    Like

    • Thanks for sharing your thought Michael! I am curious to know more about “feature teams are cross functional and only persist for the duration of the feature”. Did you mean that your teams are assembled based on needs of certain features? How long will they normally last?

      Like

      • They’re usually assembled for any feature taking more than 2 weeks to produce. If the feature would involve 20% database, 40% back-end, 20% front-end and 20% testing effort, we’d ideally match that distribution in the make-up of the team (maybe 1 DBA, 2 Java developers, 1 web developer and a dedicated tester) along with the business feature (product) owner.
        Obviously in the real world things never line up so neatly, but that’s typically a good thing. If one area requires slightly more resource than what’s available, some cross-skilling occurs. So, by the end of the feature, your tester may have picked up some basic database skills etc.
        Once the feature is complete and delivered, each resource returns to their “pool”, ready to be assembled for a new feature team.

        Like

      • Do you see the time and efforts it take for new team to build their dynamic costly? FYI, We were trying to keep our team long lived here to minimize the cost it takes for new team to blend. We notice that a team perform differently after blended for few weeks. Does it happen to yours too?

        Like

      • That’s always a possibility (initially), but after a period of time it actually socialises the wider team, allowing collaboration beyond single teams.
        Hopefully preventing “them and us” environments where hand-offs and conflicts of interest can be much more costly longer-term with silos.

        Like

      • It’s true that having wider perspective when collaborate with members from different teams would do them good too. Great thought!

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s