How to do complex product development using Agile feature teams across multiple network elements.

1. Component versus Feature Teams
1
Wednesday, March 17, 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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