Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Transition to feature teams - Gil Wasserman - Agile Israel 2013

•
•
AgileSparks
AgileSparks

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.

Related slideshows

Agile lean workshop for managers & exec leadership
Agile lean workshop for managers & exec leadershipAgile lean workshop for managers & exec leadership
Agile lean workshop for managers & exec leadership
 
A Very Large Enterprise Agile Transformation: Lessons Learned at Salesforce
A Very Large Enterprise Agile Transformation: Lessons Learned at SalesforceA Very Large Enterprise Agile Transformation: Lessons Learned at Salesforce
A Very Large Enterprise Agile Transformation: Lessons Learned at Salesforce
 
Approaches to scaling agile
Approaches to scaling agileApproaches to scaling agile
Approaches to scaling agile
 
1 of 25
Transition to Feature Teams – Options, Practices, Guidelines Gil Wasserman Coach, AgileSparks AgileIsrael 2013 7 May 2013
Transition to feature teams - Gil Wasserman - Agile Israel 2013
FT Benefits SPOC SW Maintainability System Wellness Drive Visibility Org Learning Speed Complexity Project Management Customer focus Creativity
Lecture Context • Team duration • Stable/Long Lived • Ad-hoc • Virtual • Team members location • Co-located • Distributed • Technical overlap between teams • Full • Minimal
1: Define the team Domain • Team Focus/Goal • Strategic goal • Line of business • Product • Super Team • Project/task
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
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
Transition to feature teams - Gil Wasserman - Agile Israel 2013
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
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
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 • . • .
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.
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)
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
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
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
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
Mid-Size Real Example - Spotify Henrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds”.
Mid-Size Real Example - Spotify Henrik Kniberg “Scaling Agile @ Spotify with Tribes, Squads, Chapters, and Guilds”.
Transition to feature teams - Gil Wasserman - Agile Israel 2013
Questions ?
Literature
0: Leadership, Believe ! No retreat ! No surrender ! PREPARE FOR GLORY !
Transition to feature teams - Gil Wasserman - Agile Israel 2013
Thank you gil@agilesparks.com

More Related Content

Transition to feature teams - Gil Wasserman - Agile Israel 2013

  • 1. Transition to Feature Teams – Options, Practices, Guidelines Gil Wasserman Coach, AgileSparks AgileIsrael 2013 7 May 2013
  • 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”.
  • 23. 0: Leadership, Believe ! No retreat ! No surrender ! PREPARE FOR GLORY !