One of the first steps in an Agile adoption is the formation and organization of agile teams. Using agile with one team and one product backlog is straightforward. But, how do we scale to support larger products/projects that involve more people than can reasonably fit on a single team? Most agile practitioners recommend scaling with feature teams--cross-functional and cross-component teams that can pull end-customer features from the product backlog and complete them. Most large organizations prefer scaling with component teams--teams that focus on the development of a component or subsystem that can be used to create only part of an end-customer feature. Join us in a discussion on what works, what doesn't and what scaling frameworks such as LeSS And SAFe recommend.

1. Feature Teams vs.
Component Teams
By: Leland Newsom

2. About Me
• Leland Newsom - Agile Coach, CapTech Ventures
• lnewsom@captechconsulting.com
• @LelandNewsom
• Past roles include: Developer, Manager, Managing Director, Technical Director
• First started learning Agile/Lean in 2005
• CSM since 2007
• Started leading & coaching agile teams in 2007

3. Agenda
• Conway’s Law
• Definitions
• Team Scaling Patterns
• Issues
• Comparison
• LeSS Recommendation
• SAFe Recommendation
• Hybrid Recommendation
• Transitioning
• I discovered that the best
innovation is sometimes the
company, the way you organize
a company. --Steve Jobs
• “Steve Jobs” by Walter Isaacson p.334

4. Scaling Questions
When you organization grows large enough to
need multiple teams, what is your team
scaling strategy? Why?
What criteria are you using to decide?

6. Conway’s Law
“...organizations which design
systems...are constrained to
produce designs which are
copies of the communication
structures of these
organizations.”
- Melvin E. Conway, April 1968
We manage and communicate this way.
Even though our value flows this way.

7. Feature Team Definition
Features are those behaviors of the system that directly fulfill some user need.
Feature team - Is a long-lived, cross-functional, cross-component team that completes
many end-to-end customer features.

8. Component Team Definition
Component Team:
1. A team that focuses on the creation of
one or more components of a larger
product that a customer would
purchase.
2. Component teams create assets or
components that are then reused by
other teams to assemble customer-
valuable solutions.
3. Team that is cross-functional (multi-
disciplinary), single component
focused.
Components are distinguishable system parts that provide and encapsulate common
functions needed to implement features.

9. Common Team Scaling Patterns
Discipline Teams Location Teams
Architectural Layer
Teams
• Hybrid
• Feature Teams

10. Component Teams (Single Backlog)
Copyright © 2007-2011, Innolution, LLC. All Rights Reserved.
Component Team #1
Component
Area #1
Component Team #2
Component
Area #2
Component Team #3
Component
Area #3
Product Backlog

11. Component Teams
(Multiple Backlogs)
Copyright © 2007-2011, Innolution, LLC. All Rights Reserved.
Component Team #1
Component
Area #1
Component Team #2
Component
Area #2
Component Team #3
Component
Area #3
FA #1 PB FA #2 PB FA #3 PB
Product Backlog #2
Product Backlog #1

12. Component Team Issue - Prioritization

13. Component Team Issue - Non-functional Requirements
As a customer, I want to be
one of 10,000 customers who
can use the system during
peak usage periods.
As a user, I want the site to
be available 99.999% of the
time I try to access it.
As the CTO, I want the new
system to conform to our
established security policies.

14. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

15. Feature Team Issue – Lack of Knowledge

16. Feature Team Issue – Organizational Resistance

17. *Agile Velocity

18. *Agile Velocity

19. Component Teams and Feature Teams

20. Comparison (from LeSS)
component team feature team
optimized for delivering the maximum number of lines of code optimized for delivering the maximum customer value
focus on increased individual productivity by implementing ‘easy’
lower-value features
focus on high-value features and system productivity (value
throughput)
responsible for only part of a customer-centric feature responsible for complete customer-centric feature
traditional way of organizing teams — follows Conway’s law ‘modern’ way of organizing teams — avoids Conway’s law
leads to ‘invented’ work and a forever-growing organization leads to customer focus, visibility, and smaller organizations
dependencies between teams leads to additional planning minimizes dependencies between teams to increase flexibility
focus on single specialization focus on multiple specializations
individual/team code ownership shared product code ownership
clear individual responsibilities shared team responsibilities
results in ‘waterfall’ development supports iterative development
exploits existing expertise; lower level of learning new skills exploits flexibility; continuous and broad learning
works with sloppy engineering practices—effects are localized requires skilled engineering practices—effects are broadly visible
contrary to belief, often leads to low-quality code in component provides a motivation to make code easy to maintain and test
seemingly easy to implement seemingly difficult to implement

21. LeSS Recommendation
From https://less.works/less/structure/feature-teams.html
“A pure feature team organization is ideal…”

22. SAFe Recommendations
To ensure highest feature throughput, SAFe generally recommends a mix of perhaps 75-80% feature teams and
20-25% component teams.
http://www.scaledagileframework.com/features-and-components/

23. Build Knowledge – Community of Practice
*Ken Rubin / Innolution

24. Build Knowledge – Component Steward
*Ken Rubin / Innolution

25. Transitioning to Feature Teams

26. Repeat - Scaling Questions
When you organization grows large enough to
need multiple teams, what is your team
scaling strategy? Why?
What criteria are you using to decide?

27. Learn More
• https://less.works/less/structure/feature-teams.html
• http://www.featureteamprimer.com/
• http://www.scaledagileframework.com/features-and-components/
• http://www.innolution.com/resources/presentations/agile-2013-scaling-with-feature-vs-
component-teams
• http://www.agilevelocity.com/blog/3-ws-building-agile-team/
• https://gosei.fi/coordinationchaos/
• https://vimeo.com/195033705
• https://dzone.com/articles/rethinking-component-teams-for-flow

28. Appendix
Coordination Chaos

29. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

30. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

31. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

32. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

33. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

34. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

35. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

36. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1

37. Clipped from: http://www.slideshare.net/gosei/actionable-fearless-leadership?qid=3889255d-2c08-4c97-ae46-7915fce4dc0a&v=&b=&from_search=1