How to organize teams in an optimal way is a common question in Agile organizations. A question you should always discuss and answer together with the people in the actual teams. This post, written by Daniel Burm, provides you with an overview of 5 possibilities for organizing teams and the main factors to take into account.
Do you feel like your teams could be organized better? How to organize teams in an optimal way is a common question in Agile organizations. A question you should always discuss and answer together with the people in the actual teams.
This post provides you with an overview of 5 possibilities for organizing teams and the main factors to take into account. Your main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Depending on your specific context one will suit your situation better than the other, or maybe you will come to the conclusion you are so Agile you can leave the concept of team all together!
- Component based teams:
Component based teams focus on specific components in the product, that do not deliver customer value in itself. They are also sometimes called focus teams for that reason. The focus is usually necessary because of the use of very specific or exotic techniques. Learning the skills and expertise to work in these teams takes years so it’s more logical to put experts together. You can compare this kind of teams with functionally specialized teams.
- Feature based teams:
Feature based teams focus on a specific customer feature or feature areas within a product. For example: search optimization in a webshop, or payments and conversion. Feature teams are necessary if the product is too large for a single team to optimize or when a single larger base product is differentiated into various market segments in retrospect. For instance, the same webshop product can be differentiated for selling kitchen appliances, or tailored for selling TV sets.
- Product based teams:
Product teams carry responsibility for the entire product or product/market combination. This means all of the skills and expertise necessary to develop and run the product reside within the team. Product teams are therefor suited for smaller products with a relatively small feature set. That’s why you often see these types of teams in start-up settings. When developing your new product, you don’t want it to be complex and you will have a limited feature set if not a single one you want to validate first. Once the product matures, team orientation eventually changes towards feature teams to excel in feature performance and fulfilling customer needs.
Other factors to take into account
There are a number of other things to take into account when discussing team organization with the teams. These are: responsibility, coordination and sustainability.
Responsibility does not decrease or increase given you work on a component or product as a whole. The person working on the component probably wants to do a good job just as well as the person working on ordering functionality. But the thing is, it is just more easy to feel responsible for an end-result. The other question is, if you only have component teams, who feels responsible for the end-result?
Coordination is also something to take into account. The need for coordination increases from product towards component teams. Just think about all the planning, hand-overs and dependencies before a group of component teams manages to deliver the final product.
The final thing is sustainability. What if technology becomes end-of -life? Are you going to fire the entire component team? Do you want to split them up over other teams? Could they adopt a totally new technology, and wouldn’t this undermine the whole reason for forming the component team in the first place? Technological advance is moving faster than ever. You know that new tech will come and go, so better stay as flexible as possible.
One good conclusion so far can thus be to avoid component teams as much as possible and move from product to feature teams when product scope and/or maturity increases. Now let’s take a look at the new kid on the block: customer journey teams.
- Customer journey teams:
Customer journeys are becoming more and more important in differentiating your digital product or services from the competition. It’s not just the core product that matters, but more and more how customers can experience added value from that digital offering; from problem recognition, to orientation, to acquiring, to aftercare, to discarding or switching to a new offering. Teams aimed towards optimizing the customer journey, can therefore be very effective. Pretty much the same goes for a customer journey teams than for product teams though; if complexity increases you can have multiple teams, but eventually you’ll need team specialized in certain parts of the journey, specific actors, or channels to differentiate further.
No teams
But wait, there is more! Yes, people, because real Agility would be to self-organize in shapes and forms that simply work. Shouldn’t we let go of the whole concept of “team”? Shouldn’t we trust people to form groups that just tackle the challenges at hand, no matter what form or shape? Like a swarm of bees or a flock of birds. I sure hope to see this sometime! I would expect to see it in an organization operating in a highly volatile and competitive market where constant change is necessary to keep up.
I hope this post helps in getting an overview of the various options for team organization and to get some direction in deciding what would work in your situation. To recap, your main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Do you want to push the boundary towards customer journey teams or maybe even dare to let go of teams? Whatever you decide, decide it together.