以敏捷方法進行團隊合作

當你的組織發展到需要多個團隊時，你的團隊擴展策略是什麼？哪些因素會影響你的決定呢？

我們從組織開始，討論組織結構如何影響需求的流動？如何影響系統的架構？透過系統思考分析團隊組建到底該採用 Component Team 還是 Feature Team？最後，從 Component Team 轉變成 Feature Team，可以怎麼做呢？

在這場分享會中，我們以敏捷方法，思考在大型組織下的團隊，如何有效的合作。

Transcript

1. Teamwork in Agile Way Derek Chen・Aug 2023
2. Who Am I 2 Derek Chen Agile Coach / TSID An agile practitioner who love to promote agile practices, and has rich experiences in Scrum, Kanban and Large Scale Scrum “Stay Hungry, Stay Foolish”
3. Agenda • Organization Structure • Team Structure • Challenges in Transitioning • Cross-Team Collaboration 3
4. Organization Structure 4
5. Scaling Questions 5 Source: https://www.slideshare.net/LelandNewsom/feb17-feature-vscomponentteams When your organization grows large enough to need multiple teams, what is your team scaling strategy? What criteria are you using to decide?
6. 6 The system that people work in and the interaction with people may account for 90 or 95 percent of performance. W. Edwards Deming
7. Conway’s Law “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” - Melvin E. Conway, April 1968 7 Source: https://www.slideshare.net/LelandNewsom/feb17-feature-vscomponentteams Evan though our value flows this way We manage and communicate this way
8. Team Structure 8 Component team vs. feature team
9. Component Team • A team focus on developing one or more components of a larger product • The components developed by the team can be reused by other teams to assemble customer-valuable solutions 9
10. Why Component Team? • Reuse in different business, codebases • Unique responsibilities like security, compliance • Provides logic and algorithm with deep technical expertise • Large data sets, intensive computation, critical non function requirements 10 Source: https://www.slideshare.net/AshwineeKalkura/ferature-team-composition-a-workshop?from_search=3
11. Feature Team • A cross-functional and cross-component team that completes end-to-end customer features • Team has the necessary knowledges and skills. If not, the team is expected to learn or acquire the needed knowledges and skills 11
12. Why Feature Team? • End-to-end responsibility • Faster feedback loops • Highly effective collaboration and communication • Reduced dependencies • Knowledge sharing and learning 12
13. 13 Source: https://blog.odd-e.com/yilv/2017/01/seeing-the-system-dynamic-component-team-vs-feature-team.html Multiple-component Multiple-function Skill gap + Quality – B1 R3 + Efficiency – + B2 Coordination complexity + External dependency – # roles of coordinator + Self-organizing capability – + Lead Time + Speed – + + R1 Learning + R2 + Value delivery +
14. Component Teams and Feature Teams 14
15. LeSS Recommendation 15 Source: https://less.works/less/structure/feature-teams A pure feature team organization is ideal from the value-delivery and organizational-flexibility perspective. … and many organizations therefore end up with a hybrid https://less.works/less/structure/feature-teams
16. SAFe Recommendation 16 Source: https://scaledagileframework.com/features-and-components/ To ensure high feature throughout, we often observe a mix of perhaps 75-80% feature teams and 20-25% component teams. https://scaledagileframework.com/features-and-components/
17. Evolution of Engineering Team 17 Product Feature Feature Feature Feature Feature Feature Infrastructure SRE, DB, K8S… Feature Feature Feature Infrastructure Presentation Web, Mobile… SRE, DB, K8S…
18. Challenges in Transitioning 18
19. Challenges in Transitioning to Feature Team • Conway’s Law • Organization silo • Availability of skill set 19 Source: https://less.works/less/structure/feature-teams
20. Learning • Continuous Integration • Community of Practices • Collective Code Ownership • Component Guardian • Slack 20
21. Community of Practice (CoP) 21 Source: https://www.mountaingoatsoftware.com/blog/cultivate-communities-of-practice
22. Collective Code Ownership We are members of a community that owns the code • Anyone can modify any code at any time • Team has a single style guide and coding standard • Original authorship is immaterial • Plentiful automated increase confidence and safety 22 Source: http://agileinaflash.blogspot.com/2009/02/collective-code-ownership.html
23. Component Guardian 23 Source: https://www.slideshare.net/LelandNewsom/feb17-feature-vscomponentteams I teach other people about component Ensure changes maintain or improve conceptual integrity Take a leadership role in promoting reuse I don’t “own” the component Feature teams make component changes Feature Team A Feature Team B Component Guardian
24. Cross-Team Collaboration 24
25. Autonomous Teams 25 Source: Spotify Engineering Culture - Part 1 Loosely coupled, tightly aligned teams Be autonomous, but don’t suboptimize
26. Alignment vs. Autonomy 26 Source: Spotify Engineering Culture - Part 1
27. Alignment and Autonomy 27 Source: Spotify Engineering Culture - Part 1
28. Scrum@Scale Recommendation 28 Source: https://www.microtool.de/en/knowledge-base/what-is-the-scrum-of-scrums/
29. LeSS Recommendation 29 Product Backlog Team A Team B Team C Team specific view of product backlog
30. Closure 30
31. Summary • Organizational structure largely determines team performance • Many organizations are a hybrid of component team and feature team • When transforming to feature team, we will meet lots of challenges • We want to build loosely coupled and tightly aligned teams 31
32. Reference • Leland Newsom. (2017). feature vs component teams. • Ashwinee Kalkura. (2018). Ferature team composition : A workshop. • Henrik Kniberg. (2019). Spotify Engineering Culture - Part 1 • Henrik Kniberg. (2019). Spotify Engineering Culture - Part 2 32
33. 33 Q A