agile component versus agile feature teams

Download Agile Component versus Agile Feature Teams

Post on 20-Aug-2015




2 download

Embed Size (px)


  1. 1. Component versus Feature Teams1 Wednesday, March 17, 2010
  2. 2. Agenda Conways LawComponent Team IssuesFeature Teams Instead2 Wednesday, March 17, 2010
  3. 3. Conways Law: ...organizations which design systems...areconstrained to produce designs which are copiesof the communication structures of theseorganizations. Melvin E. Conway, April 1968And the corollary of Conways Law Organizations unwilling to re-organize to generate an optimal design, can end up producing sub-standard design reflecting the pre-existing organization.3 Wednesday, March 17, 2010
  4. 4. What is a component team Using this example: 1 Product Owner Multiple Teams One team is responsible for one part of the system (component). Components A, B andC could representnetwork elements in aProduct Backlog complex telecom ProductenvironmentA BacklogB (for C Components A, B and C components could also represent a A, B and C,Call Processing, comprising the Maintenance and system)Messaging subsystems 4 Wednesday, March 17, 2010
  5. 5. Whats wrong with component teams: Backlog gets built by dependency analysis of components versus by evaluating customer value of features A single requirement doesnt map to a single component team (work is unbalanced) and could span multiple components Dependencies are handled between components Difficult to demonstrate completed requirements across components - takes a long time! New work is discovered as components are integrated Product Backlog ProductA Components A, B and CBacklogB (for C components A, B and C, comprising the re-architecture &design added to thesystem)backlog from inter-component analysis5 Wednesday, March 17, 2010
  6. 6. Whats wrong with component teams: Large backlog items are split into component backlog items lacking customer visible value Defining these component-based backlog items splits = Architecture (which happens before the iteration starts) Resulting in final system test (of all components) after iteration ends (finding problems late in the cycle)!System Test Architecture Develop the the integratedComponentscomponentsProduct BacklogProduct AComponents A, B and CBacklog B(forCcomponentsA, B and C,comprising there-architecturesystem) & designback to thebacklog6 Wednesday, March 17, 2010
  7. 7. Some attempts to deal with this:Issues are managed by a role-type, aka projectmanager, across component teamsThis leads to resource and/or priority spatshandling unbalanced feature needs betweenvarious component teamsProject ManagersProduct for A, B and CBacklog PMA A Product Backlog B (forPMBC components PM A, B and C, C comprising the system)Added Project Managersneeded for coordinating thework across component teams 7 Wednesday, March 17, 2010
  8. 8. Instead, try feature teams:Structure the teams so that their expertisespans the architecture - cutting across allcomponentsfeature teams where all dependenciesbetween components are managed within eachteam.X Z Y Product Backlog A(for components A,B and C beginningwith highest valued BfeaturesX, Y and Z C8 Wednesday, March 17, 2010
  9. 9. Case Study: Single product featureteamsStructure the teams so that their expertise spansthe architecture - cutting across all CallP,Maintenance and Messaging components.Feature teams X, Y, Z manage thedependencies between within each team.X Y Z Product Backlog (for Database,Call Processing Business Logic & Web UI components) Maintenance beginning with highest valued features X, Y and Z Messaging9 Wednesday, March 17, 2010
  10. 10. Case Study: Multiple NEs (LCS)Feature 1: Position of Abbreviations:LCS Client (user!)Product backlog of UMTS -Universal Mobile Telecommunication System3GPP LocationGSM -Global System for MobileServices spanningCommunications MS - Mobile Station in GSMmultiple products. UE - User Equipment in UMTS HLR - Home Location Register First feature - locateGMLC -Gateway Mobile Location Centerthe Location Services (LCS) Client POLCS - Location Services MSC Mobileservices Switching Center SMLC -Serving Mobile Location Center BSS - Base Station Subsystem RNC - Radio Network Controller NE - Network Element ...and PO = Product Owner ABA B CMS/UEBSS/RNC Teams (A,B,C) withC skills ranging multiple xMLCproductsMSCThe call flows for the External LCS Client to get the position of the User from 1-10, detailed in 3GPP Rel-99.HLR Example of a suggested feature work breakout from call flow diagram for teams A, B, C 10 Wednesday, March 17, 2010
  11. 11. What is a Feature Team? Ideally co-located: if you cant, you need to plan, play and execute well together- doing whatever it takes. Cross-functional: The team has all the skills (representing all components) to get the job done. Members of the team work across all disciplines, across all components, on the highest value customer features. There are specialists and generalists on the team (test, architecture, developers, customer documentation: everything it takes.) The teams are generally very long lived and high performing: they get better with time.11 Wednesday, March 17, 2010
  12. 12. What happens to the dependencies? With feature teams the dependency handling (thatwe saw between components), now has moved todependency management between feature teams.This dependency is mitigated with Strict source version control system - this does not mean the latest version is on my thumb drive Well run continuous integration system Automated build and test Dependency issues discussed/handled in daily Scrum of Scrums12 Wednesday, March 17, 2010
  13. 13. Transitioning to feature teams: Restructure Product Backlog so that it is grouped byCustomer Centric feature requirement groupings (call itwhatever you want to call it - Customer RequirementGroup - CRG)Every CRG has one Product Owner (PO)Every CRG has a set of feature teams specializing in thatarea.Every PO is responsible for one customer centric domain.Chief PO is responsible for moving teams betweenprioritized CRGs as needed.Make avid use of Architects and Test for planning, definingbacklog acceptance criteria, and dependency analysisbetween product components. (last slides) 13 Wednesday, March 17, 2010
  14. 14. Abbreviations: Scaling (Example LCS CRG) MS - Mobile Station in GSM UE - User Equipment in UMTS HLR - Home Location Register LCS - Location Services LCS User Stories.... MSC Mobileservices Switching Center MLC -Mobile Location Center BSS - Base Station Subsystem RNC - Radio Network Controller ...and PO = Product OwnerChief Product Owner of LCS CRG Coordinated in Scrum of ScrumsPO PO PO A B CA B CA B C MS/UEMS/UEMS/UE BSS/RNCBSS/RNCBSS/RNC xMLC xMLC xMLC MSCMSCMSC HLRHLRHLR 14 Wednesday, March 17, 2010
  15. 15. Transitioning to feature teams: Architect team Not a good model for transitioning to feature teams. Why? - Creates a hand-off between architecture and teams doing the workHLR MS/UE MSC xMLC BSS/RNC - Architecture accountability not built into org structure Component Teams - Test information not built in early - Architecture teams become the bottle neck with no improvement feedback loops built in. - Prone to mis-interpretation of user story acceptance 15 Wednesday, March 17, 2010
  16. 16. Transitioning to feature teams: Include anArchitecture & Test Feature Team(example below of an LCS feature team)Transition model builds in architectural improvement & story acceptance feedback, while also allowing the feature team to realize (and improve) the cycle time from Architecture Ready to Done! Component Teams LCS HLR MS/UE MSC xMLC BSS/RNC FeatureTeam Arrows indicate Story Acceptance Criteria beingpassed to component teams.In this example, the story will be accepted when HLRanswers, after having verified that the requesting GMLC isauthorized to obtain the location of the subscriber.LSC Feature team inclusive of User Acceptance Test + Architecture responsible for - Defining the User Story Acceptance Criteria for stories spanning multiple components. - Verifying acceptance after story complete - Test built into org structure 16 Wednesday, March 17, 2010
  17. 17. If you cant get there...Second slide deck coming soon on tools to help with plumbing. If you cant get there and need help, call me! Catherine Louis email: Tel +1.919.244.1888 Material licensed under Creative Commons: This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License17 Wednesday, March 17, 2010