Agile Component versus Agile Feature Teams

Component versus Feature Teams

1Wednesday, March 17, 2010

Agenda

Conway’s LawComponent Team IssuesFeature Teams Instead


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.”


What is a “component” team

Using this example:1 Product OwnerMultiple TeamsOne team is responsible for one part of the system (component).

4

AB

C

Product Backlog (for components A, B and C, comprising the “system”)

Product Backlog

“Components” A, B and C could also represent a Call Processing, Maintenance and Messaging subsystems

“Components” A, B and C could represent network elements in a complex telecom environment

Wednesday, March 17, 2010

What’s wrong with component teams:

Backlog gets built by dependency analysis of components versus by evaluating customer value of featuresA single requirement doesn’t map to a single component team (work is unbalanced) and could span multiple componentsDependencies are handled between componentsDifficult to demonstrate completed requirements across components - takes a long time!New work is discovered as components are integrated

5

AB

C


re-architecture & design added to the backlog from inter-component analysis

Product Backlog

Components A, B and C


What’s wrong with component teams:Large backlog items are split into component backlog items lacking customer visible valueDefining 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)!

6

AB

C

re-architecture & design back to the backlog


Architecture Develop the Components

System Test the integrated components

Product Backlog

Components A, B and C


Some attempts to deal with this:Issues are managed by a role-type, aka “project manager”, across component teamsThis leads to resource and/or priority spats handling unbalanced feature needs between various component teams

7

AB

C


Product Backlog

Project Managers for A, B and C

Added Project Managers needed for coordinating the work across component teams

PM A

PMC

PM B


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.

8

A

B

C

Product Backlog (for components A, B and C beginning with highest valued features X, Y and Z

X Y Z


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.

9

Call Processing

Messaging

Maintenance

Product Backlog (for Database, Business Logic & Web UI components) beginning with highest valued features X, Y and Z

X Y Z


C

A B

Case Study: Multiple NEs (LCS)

10

MS/UE

BSS/RNC

MSC

Feature 1: Position of LCS Client (user!)

Abbreviations:

UMTS -Universal Mobile Telecommunication SystemGSM -Global System for Mobile CommunicationsMS - Mobile Station in GSMUE - User Equipment in UMTSHLR - Home Location RegisterGMLC -Gateway Mobile Location CenterLCS - Location ServicesMSC Mobileservices Switching Center SMLC -Serving Mobile Location CenterBSS - Base Station SubsystemRNC - Radio Network ControllerNE - Network Element...and PO = Product Owner

The call flows for the External LCS Client to get the position of the User from 1-10, detailed in 3GPP Rel-99.

Example of a suggested feature work breakout from call flow diagram for teams A, B, C

xMLC

Product backlog of 3GPP Location

Services spanning multiple products.

First feature - locate the Location Services

(LCS) Client

HLR

CBA

Teams (A,B,C) with skills ranging multiple

products

PO


What is a Feature Team?

11

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.


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 testDependency issues discussed/handled in daily Scrum of Scrums


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)


Scaling (Example LCS CRG)

14

LCS User Stories....

MS/UE

BSS/RNC

MSC

xMLC

HLR

CBA

PO

MS/UE

BSS/RNC

MSC

xMLC

HLR

CBA

PO

MS/UE

BSS/RNC

MSC

xMLC

HLR

CBA

PO

Chief Product Owner of LCS CRG

Coordinated in Scrum of Scrums

Abbreviations:MS - Mobile Station in GSMUE - User Equipment in UMTSHLR - Home Location RegisterLCS - Location ServicesMSC Mobileservices Switching Center MLC -Mobile Location CenterBSS - Base Station SubsystemRNC - Radio Network Controller...and PO = Product Owner


Transitioning to feature teams:

15

MS/UE BSS/RNCMSC xMLCHLR

Architect team

Component Teams

Not a good model for transitioning to feature teams. Why?- Creates a hand-off between architecture and teams doing the work - Architecture accountability not built into org structure- 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


Transitioning to feature teams: Include an Architecture & Test “Feature” Team (example below of an LCS feature team)

16

MS/UE BSS/RNCMSC xMLCHLRLCS Feature Team

Component Teams

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

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.

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!”


If you can’t get there...

17

Second slide deck coming soon on tools to help with plumbing.If you can’t get there and need help, call me!

Catherine Louisemail: [email protected] 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


mailto:[email protected]

mailto:[email protected]

http://creativecommons.org/licenses/by-nc-sa/3.0/







Agile Component versus Agile Feature Teams

Technology

Transcript of Agile Component versus Agile Feature Teams