Transition to feature teams - Gil Wasserman - Agile Israel 2013

1,607 views
1,473 views

Published on

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.

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,607
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transition to feature teams - Gil Wasserman - Agile Israel 2013

  1. 1. Transition to Feature Teams –Options, Practices, GuidelinesGil WassermanCoach, AgileSparksAgileIsrael 20137 May 2013
  2. 2. FT BenefitsSPOCSWMaintainabilitySystemWellnessDriveVisibilityOrgLearningSpeedComplexityProjectManagementCustomerfocusCreativity
  3. 3. Lecture Context• Team duration• Stable/Long Lived• Ad-hoc• Virtual• Team members location• Co-located• Distributed• Technical overlap between teams• Full• Minimal
  4. 4. 1: Define the team Domain• Team Focus/Goal• Strategic goal• Line of business• Product• Super Team• Project/task
  5. 5. 2: Maximize Autonomy• Maximize the ability of the team to achieveresults autonomously• Structure• Processes• Tools and Infrastructure• Environments• Architecture• Coding methods (e.g. feature toggle)• Balance teams (in the long term)• Seniority• Experts• Bonding• Load
  6. 6. 3: Ownership• With autonomy comes ownership• Educate for end to end responsibility (Done-Done !)• Success and failures are part of the teamperformance• Team should build short improvement cyclesover their results and culture
  7. 7. 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 termhealth• Production – e.g. Scalability, Performance, Stability• Quality – e.g. Architecture, Coding standard, Coverage• Process - Automation
  8. 8. 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 thecritical delivery chain• Establish Tech Owners Forums andPlatforms for collaboration• Tech Owners should allocate 5%-20% oftheir time to the above
  9. 9. 5: Build the matrix• Yes, we push for autonomy of the team.• But, Success requires a matrix of collaborationthat crosses teams’ boundaries• Cross Teams Collaboration• PMs• Team leaders• Architects/Tech Owners/Experts• QA Engineers and QA programmers• Delivery Engineers• Scrum Masters• .• .
  10. 10. 6: Think Architecture• Full force ahead towards Biz success should becombined with healthy architecture thinking• System Architects should be involved in majordevelopment efforts.• Architects should enable, educate, review andpromote system well being.• Make sure Architects have free communicationchannels to PMs.
  11. 11. 7: Delivery Automation Included• Push for autonomy of the team includingdelivery to production• Delivery automation preferably be part of theteam skills• Support and enhance the team if needed byexternal specific team (e.g. QA automation,Deployment automation)• (Regulations issues are solvable)
  12. 12. 8: System Support and Stability• New features and products rollout is part ofthe 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 largerit is - choose the latter
  13. 13. 9: Dev-Ops Collaboration Culture• Feature teams boost the power of each team tomake decisions. These might affect systemstability….• Be aware of this. Establish open communicationand improvements cycles between dev and ops• Educate for collaboration• Dev-Ops Collaboration• Automation• Monitoring• Support
  14. 14. 10: Transition to Feature Teams• The strength of feature teams structurecomes from the focus of the org as a wholeto Biz orientation• Its better to have the transition in a singlestep rather than gradual/pilot way• Be prepared though for a few months withlower efficiency:• Make all the right preparations (Policies, roles,environments etc)• Conduct the change• Stabilize and adapt
  15. 15. 10+1: Inspect and Adapt• The above guidelines are just what they are• Inspect and adapt continuously in order toreach the balance and the DNA that is bestfor your organization
  16. 16. Mid-Size Real Example - SpotifyHenrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, andGuilds”.
  17. 17. Mid-Size Real Example - SpotifyHenrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, andGuilds”.
  18. 18. Questions ?
  19. 19. Literature
  20. 20. 0: Leadership, Believe !No retreat !No surrender !PREPARE FOR GLORY !
  21. 21. Thank yougil@agilesparks.com

×