Feature teams structure is a well known good-engineering-practice, especially for agile, busniess driven organizations. However, transferring an organization from component to feature teams is always a challange. Most organization actually keep their component driven structure and way of operation. This lecture is intended for those who have already been convinced about the benefits and value of feature teams, but are still hesitant to make the change. In this lecture we shall discuss optional migration paths and share practical considerations and tips to help make the transition effective and worth doing.

1. Transition to Feature Teams –
Options, Practices, Guidelines
Gil Wasserman
Coach, AgileSparks
AgileIsrael 2013
7 May 2013

3. FT Benefits
SPOC
SW
Maintainability
System
Wellness
Drive
Visibility
Org
Learning
Speed
Complexity
Project
Management
Customer
focus
Creativity

4. Lecture Context
• Team duration
• Stable/Long Lived
• Ad-hoc
• Virtual
• Team members location
• Co-located
• Distributed
• Technical overlap between teams
• Full
• Minimal

5. 1: Define the team Domain
• Team Focus/Goal
• Strategic goal
• Line of business
• Product
• Super Team
• Project/task

6. 2: Maximize Autonomy
• Maximize the ability of the team to achieve
results autonomously
• Structure
• Processes
• Tools and Infrastructure
• Environments
• Architecture
• Coding methods (e.g. feature toggle)
• Balance teams (in the long term)
• Seniority
• Experts
• Bonding
• Load

7. 3: Ownership
• With autonomy comes ownership
• Educate for end to end responsibility (Done-
Done !)
• Success and failures are part of the team
performance
• Team should build short improvement cycles
over their results and culture

9. 4: Invest in the Technical Landscape
• Identify the domains that require expertise:
• Component
• Sub-system
• Knowledge domain
• Assign tech owner to lead it
• Tech Owner should be:
• Responsible of the domain well being, long term
health
• Production – e.g. Scalability, Performance, Stability
• Quality – e.g. Architecture, Coding standard, Coverage
• Process - Automation

10. 4: Invest in the Technical Landscape
• Tech Owners should be:
• Enablers of good design and coding
• Spreading the knowledge
• Rarely (if any) selected participation in the
critical delivery chain
• Establish Tech Owners Forums and
Platforms for collaboration
• Tech Owners should allocate 5%-20% of
their time to the above

11. 5: Build the matrix
• Yes, we push for autonomy of the team.
• But, Success requires a matrix of collaboration
that crosses teams’ boundaries
• Cross Teams Collaboration
• PMs
• Team leaders
• Architects/Tech Owners/Experts
• QA Engineers and QA programmers
• Delivery Engineers
• Scrum Masters
• .
• .

12. 6: Think Architecture
• Full force ahead towards Biz success should be
combined with healthy architecture thinking
• System Architects should be involved in major
development efforts.
• Architects should enable, educate, review and
promote system well being.
• Make sure Architects have free communication
channels to PMs.

13. 7: Delivery Automation Included
• Push for autonomy of the team including
delivery to production
• Delivery automation preferably be part of the
team skills
• Support and enhance the team if needed by
external specific team (e.g. QA automation,
Deployment automation)
• (Regulations issues are solvable)

14. 8: System Support and Stability
• New features and products rollout is part of
the end to end responsibility of the team(s)
• System support on the other hand:
• Dedicated team
• Rotation between teams
• The more mature is the system or the larger
it is - choose the latter

15. 9: Dev-Ops Collaboration Culture
• Feature teams boost the power of each team to
make decisions. These might affect system
stability….
• Be aware of this. Establish open communication
and improvements cycles between dev and ops
• Educate for collaboration
• Dev-Ops Collaboration
• Automation
• Monitoring
• Support

16. 10: Transition to Feature Teams
• The strength of feature teams structure
comes from the focus of the org as a whole
to Biz orientation
• Its better to have the transition in a single
step rather than gradual/pilot way
• Be prepared though for a few months with
lower efficiency:
• Make all the right preparations (Policies, roles,
environments etc)
• Conduct the change
• Stabilize and adapt

17. 10+1: Inspect and Adapt
• The above guidelines are just what they are
• Inspect and adapt continuously in order to
reach the balance and the DNA that is best
for your organization

18. Mid-Size Real Example - Spotify
Henrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, and
Guilds”.

19. Mid-Size Real Example - Spotify
Henrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, and
Guilds”.

21. Questions ?

22. Literature

23. 0: Leadership, Believe !
No retreat !
No surrender !
PREPARE FOR GLORY !

25. Thank you
gil@agilesparks.com