Download to read offline
Uploaded byAgile Austria Conference
AAC2026_Batusek_Beyond the Bus Factor: Build your teams for for the future.pdf
Ever tried managing a software project with dozens, even hundreds, of developers? But how do you structure your teams to tackle the sheer complexity of modern software? The old „7+-2 members“ rule we learned from the theory isn’t the whole story. This talk will cut through the theory and give you practical tips for deciding further team characteristics. Essentially, you have three basic options: First, you can have component teams (the whole team is specialized into a technology, part of product or process step. Second, you can use temporary ad-hoc teams (sometimes called mission-aligned teams or project teams) that are formed around each new requirement. Last but not least, there are Feature Teams, long-term end-to-end teams consisting of multi-skilled people. All of these options are legitimate and each of them has consequences – they will affect feature throughput, lead time and business resilience. The talk will discuss all three options in detail and reveal their real-world impact on your product. Learn which team structure is right for your product and how to avoid common pitfalls.
More Related Content
Similar to AAC2026_Batusek_Beyond the Bus Factor: Build your teams for for the future.pdf
AAC2026_Batusek_Beyond the Bus Factor: Build your teams for for the future.pdf
- 1. Beyond the BusFactor: Build your teams for the future Agile Austria 2026
- 2.
- 3. We don’t know,what’s ahead of us
- 4. Resilience “The capacity towithstand or to recover quickly from difficulties” Oxford English dictionaries “The quality of being able to return quickly to a previous good condition after problems” Cambridge Dictionary “The ability of a system to withstand changes in its environment and still function” Wikipedia
- 5.
- 6. What do individualsdo to prepare for uncertainty
- 7. All of thesemeasures decrease comfort or well-being now in order to increase the chances of success in the future
- 8. What do companiesdo to prepare for uncertainty?
- 9. All of thesemeasures decrease profitability now in order to keep the company profitable in the future
- 10. What measures doyou or your company use to increase resilience? https://www.menti.com/almdxpc6jtt8
- 11. What measures doyou or your company use to increase resilience? https://sli.do #4537443
- 12. Context - Large-ScaleProduct Development
- 13. Using team structureto build resilience ?
- 14.
- 15. Agility leads toResilience Agility Resilience Ability to change direction quickly
- 16. Common practice foragile development 7 ± 2 Cross-functional Bus factor > 1
- 17. Scaling options stable teams end-to-endteams level of multi-learning team size yes / no 1 .. n 3 .. 20 yes / no
- 18. Scaling with ComponentTeams Database (SQL) Core system (Java) Integrations (python) Web FE (react) Mobile app (Kotlin)
- 19. Component teams stable teams end-to-endteams level of multi-learning team size Component team examples ● Architectural elements - image processing, protocol handler, installer ● Architectural layers - database, frontend, backend ● Technology silos - C++, Java, php, Go, python ● Functional silos - DBA, UX designer, business analyst, integration tester yes no 1 7
- 20. Component teams consequences(1) Consequences ● High utilization ● Single specialization ● Private code ownership ● Dependencies between teams Benefits ● Easy to find replacements ● Fast onboarding ● Substitutability ● Team spirit
- 21. Component teams consequences(2) Drawbacks ● Need for extra coordination ● Planning complexity ● Not able to follow priorities ● Extremely high waiting times
- 22. Not able tofollow business priorities Product backlog Nobody can work in item #3 The violet team can only work on low value items
- 23. Scaling with temporaryteams Product backlog
- 24. Temporary teams stable teams end-to-endteams level of multi-learning team size Temporary teams ● synonyms - ad-hoc teams, mission teams ● built around short-term goals ● from 3 days (FAST Agile) to 1 months ● sometimes combined with stable teams, especially in times of crises (“tiger” teams) yes no 1 3-10
- 25. Temporary teams consequences Consequences ●Optimized for the delivery now ● How to deal with leftovers? ● When to do reteaming? Drawbacks ● lack of “team jellying” ● long-term code readability may suffer ● no motivation for learning Benefits ● Excellent collaboration and low cycle time on the highest priority item ● No waiting for other teams ● High developer motivation, especially if self-selection is used 73% of the incidents in airplanes happens on the first day of the crew working together
- 26.
- 27. Feature teams stable teams end-to-endteams level of multi-learning team size Feature teams ● Deliver the whole feature end-to-end even if they don’t know all the technical details at the beginning ● Typically, some amount of learning happens as part of delivery yes yes 3 7
- 28. Feature teams consequences(1) Consequences ● Leads to collective code ownership and dependencies when contributing to common code ● Optimized for learning (learn first, then deliver) Benefits ● Excellent collaboration and low cycle time on the highest priority items ● No waiting for other teams ● The teams adapt to new requirements as they go ● No need for extra coordination ● Business priorities are always followed ● There are no leftovers
- 29. Feature teams consequences(2) Drawbacks ● Requires multi-skilled people ● Requires technical practices for working with shared code ● Requires coordination for shared design decision ● Recommended to complement with Communities of Practice to support deep primary skill development
- 30. Which team typesdo you primarily use? https://sli.do #4537443
- 31. Comparison of teamtypes Feature Teams Assumption: It pays off to learn new skills together with doing the job Component Teams Assumption: The work in the future will look exactly like the work in the past Temporary teams Assumption: We have all the skill to do the job now, we do not need to learn
- 32. 5 Practical Tipsfor Building Resilient Teams
- 33. Don’t be nice Sortthe product backlog strictly according to business priorities Ignore the current people skills Why does it increase resilience? ● It forces people to learn new skills out of their primary specialization ● Teams of multi-skilled people are more resilient - able to handle unexpected situations $$$$$$$$ $ $$$$
- 34. Multi-team Product BacklogRefinement
- 35. Increase quality ofinternal documentation Clean your documentation data sources Why does it increase resilience: ● it speeds up onboarding of new hires ● it decreases switching costs of your teams Side effect: it increases the productivity gain from AI usage.* *Source: DORA report 2025
- 36. Collective code ownership Everyperson can change any part of code without any barrier Pro-tip: decrease the number of repositories Why does it increase resilience: ● it increases product understanding ● it increases code readability (because it is under a constant review) ● it makes future changes easier
- 37. Communities of Practice Asafe space to connect people from multiple teams with the same interest Develop people in certain skills Why does it increase resilience? ● Overcomes functional or organizational silos ● Creates informal connection that can become important under stress
- 38. Conclusion Team structure isan often overlooked lever that affects resilience in large-scale product development Feature Teams are the most resilient team type