Agile Component versus Agile Feature Teams

Component versus Feature Teams 1 Wednesday, March 17, 2010

Agenda Conway’s Law Component Team Issues Feature Teams Instead 2 Wednesday, March 17, 2010

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 And the corollary of Conway’s 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

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 and C could represent network elements in a Product Backlog complex telecom Product environment A Backlog B (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

What’s wrong with component teams: Backlog gets built by dependency analysis of components versus by evaluating customer value of features A single requirement doesn’t 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 Product A Components A, B and C Backlog B (for C components A, B and C, comprising the re-architecture & design added to the “system”) backlog from inter- component analysis 5 Wednesday, March 17, 2010

What’s 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 integrated Components components Product Backlog Product A Components A, B and C Backlog B (for C components A, B and C, comprising the re- architecture “system”) & design back to the backlog 6 Wednesday, March 17, 2010

Some attempts to deal with this: Issues are managed by a role-type, aka “project manager”, across component teams This leads to resource and/or priority spats handling unbalanced feature needs between various component teams Project Managers Product for A, B and C Backlog PM A A Product Backlog B (for PM B C components PM A, B and C, C comprising the “system”) Added Project Managers needed for coordinating the work across component teams 7 Wednesday, March 17, 2010

Instead, try feature teams: Structure the teams so that their expertise spans the architecture - cutting across all components “feature teams” where all dependencies between components are managed within each team. X Z Y Product Backlog A (for components A, B and C beginning with highest valued B features X, Y and Z C 8 Wednesday, March 17, 2010

Case Study: Single product feature teams Structure the teams so that their expertise spans the architecture - cutting across all CallP, Maintenance and Messaging components. “Feature teams” X, Y, Z manage the dependencies 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 Messaging 9 Wednesday, March 17, 2010

Case Study: Multiple NEs (LCS) Feature 1: Position of Abbreviations: LCS Client (user!) Product backlog of UMTS -Universal Mobile Telecommunication System 3GPP Location GSM -Global System for Mobile Services spanning Communications MS - Mobile Station in GSM multiple products. UE - User Equipment in UMTS HLR - Home Location Register First feature - locate GMLC -Gateway Mobile Location Center the Location Services (LCS) Client PO LCS - 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 A B A B C MS/UE BSS/RNC Teams (A,B,C) with C skills ranging multiple xMLC products MSC The 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

What is a Feature Team? Ideally co-located: if you can’t, 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

What happens to the dependencies? With feature teams the dependency handling (that we saw between components), now has moved to dependency 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 Scrums 12 Wednesday, March 17, 2010

Transitioning to feature teams: Restructure Product Backlog so that it is grouped by Customer Centric feature requirement groupings (call it whatever you want to call it - Customer Requirement Group - CRG) Every CRG has one Product Owner (PO) Every CRG has a set of feature teams specializing in that area. Every PO is responsible for one customer centric domain. Chief PO is responsible for moving teams between prioritized CRGs as needed. Make avid use of Architects and Test for planning, defining backlog acceptance criteria, and dependency analysis between product components. (last slides) 13 Wednesday, March 17, 2010

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 Owner Chief Product Owner of LCS CRG Coordinated in Scrum of Scrums PO PO PO A B C A B C A B C MS/UE MS/UE MS/UE BSS/RNC BSS/RNC BSS/RNC xMLC xMLC xMLC MSC MSC MSC HLR HLR HLR 14 Wednesday, March 17, 2010

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 work HLR 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

Transitioning to feature teams: Include an Architecture & 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 Feature Team Arrows indicate Story Acceptance Criteria being passed to component teams. In this example, the story will be accepted when HLR answers, after having verified that the requesting GMLC is authorized 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

If you can’t get there... Second slide deck coming soon on tools to help with plumbing. If you can’t get there and need help, call me! Catherine Louis email: cll@cll-group.com 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 License 17 Wednesday, March 17, 2010

Agile Component versus Agile Feature Teams

by CLL Group, LLC on Mar 17, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 15

Statistics

Agile Component versus Agile Feature Teams — Presentation Transcript

http://www.slideshare.net	14
http://twittertim.es	1