2013 01 15 feature vs. component teams -...
TRANSCRIPT
1 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Feature vs. Component Teams January 15, 2013
Raleigh, North Carolina by Kenny Rubin
2 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Background of Kenny Rubin
Author Trainer/Coach Trained more than 18,000 people in Agile/Scrum, SW dev and PM Provide Agile/Scrum coaching to developers and executives
Experience
My first Scrum project was in 2000 for bioinformatics
Former Managing Director
Executive
3
Simple Agile Has One Product Backlog and One Team
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
4 Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
Characteristics of a Single Development Team
5
Scaling Question #1
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
As the scope of work gets larger and one team is no longer sufficient, what is your scaling strategy?
6 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Team Patterns When Scaling Up
7
Discipline Teams
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
8
Location Teams
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
US India
US India Deliberately Distributed
Teams Team 2
Team 1
Team 1 Team 2 Coordinating Collocated
Teams
9
Architectural Layer Teams
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
DB
Middle Tier
GUI
10
Component Teams
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
11
Feature Teams
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
12
Scaling Question #2
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
So, which approach do you prefer?
What criteria are you using to decide?
13 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Economically Sensible Scaling
14
Don’t Scale Based on Dogma!
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Do you honestly think there is a single answer to scaling that universally applies to all situations (sizes and types of organizations)?
Everyone knows feature teams are better!
Nuts! Component teams promote
conceptual integrity & reuse!
15
Scale Based on Economic Tradeoffs
Scaling should be based on economic factors
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
16
Scale to Maximize Lifecycle Profits
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Based on Reinertsen 2009.
Scale in a way that achieves superior flow resulting in maximum lifecycle profits
Lifecycle profits
Work needs to flow though “system” (collection of teams) in an economically sensible way
17
Waste
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Waste 1 Waste 2 Waste 3 Waste 4 Multiple forms
of waste
Waste 1 Waste 2 Waste 3 Waste 4 Can’t eliminate
them all
Waste 1 Waste 2 Waste 3 Waste 4
$ $$$$ $$ $$$
Determine which cause most
economic damage
18
Recognize Inventory (WIP) Waste
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
Manufacturing inventory is both physically and financially visible
Product-development inventory are knowledge assets that aren’t visible in the same way as physical parts
19
Focus on Idle Work Not Idle Workers
Watch the Baton Not the Runners
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
20
Cycle Time (Lead Time)
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
or
Idea or problem Solution
Workflow / Value Stream with a given team scaling pattern
Cycle time
21
Example Workflow / Value Stream
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Groom feature
Dev 1
Dev 2
Dev 3
Art
Dev 1
Dev 2
Dev 3
Integrate& Test
2d 2wk
1wk
6wk 1wk 4wk
1wk 2wk 1wk 2h 1wk
5wk Waste
Value
Deploy
3wk 3wk 3wk 2wk 4wk
6 wk value-adding time
39.4 wk cycle time = 15%
Process cycle efficiency
Improve team efficiency 10% yields 1.5% improvement
Eliminate 10% waste
yields 8.5% improvement
22
Cost of Delay
Copyright © 2007 - 2012, Innolution LLC. All Rights Reserved.
If you have to wait 6 weeks for the Art team to draw your art, and that delay could be eliminated by having artists on your team, what would be the cost of the Art-team delay (in lifecycle profits)?
Cycle time Variability
Money Cycle time
23
Team Structure Can Effect Predictability
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
What if we organized our teams in a way that made the product-development process inherently more predictable?
24
Validate Important Assumption with Fast Feedback
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
25
Eliminate Unnecessary Ceremony
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
26
Value-centric Deliverables
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
27
Team Pattern Should Balance Predictive and Adaptive work
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
28 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Analysis of Component Teams
29 Copyright © 2007-2011, Innolution, LLC or Mountain Goat Software, Inc. All Rights Reserved.
Component Teams (Single Source)
30 Copyright © 2007-2011, Innolution, LLC or Mountain Goat Software, Inc. All Rights Reserved.
Component Teams (Multiple Sources)
31
Issue – Blocked Work
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
High
Low
Cost of delay
Process efficiency
32
Issue – Prioritization
Localized prioritization decisions based on things like:
Technical priorities of component Whatever is fun or easy
Feature prioritization can be driven by component team availability
NPF (Nosiest Person First) can dominate work order
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
33
Issue – Coordination Cost
Requires significant and on-going planning, handoffs, and dependency management
At scale dependency management becomes economically intractable
Favors low-bandwidth means of communication (e.g., interaction by contracts)
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
API Doc
API Doc
34
Issue – Slower Feedback
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
External feedback is slower
Predictive Adaptive
Internal feedback is slower
35
Issue – Limits Learning
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
I love specializing I feel
stuck!
Risky: specialty knowledge in only a few heads
36
Issue – Harder to See the Whole
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Best components ever! But still a poor product
Alignment trumps local excellence
37
Desirable Property – Conceptual Integrity Knowledgeable and trusted people work in the code
Ensure conceptual integrity Low technical debt
Conceptual integrity provides: Congruity; consistency; logical interconnectivity, overall cohesive and understandable
Want conceptual integrity both at the component and the full system/product level
NOTE: conceptual integrity at the component level doesn’t guarantee conceptual integrity at the product level
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
38
Desirable Property – Asset Reuse
Build it once, use it often
Avoid building the same capability in multiple, potentially inconsistent ways
Would otherwise appear in many places in the codebase, complicating maintenance and testability
Economically a sensible concept, but need to consider the full cost of reuse
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
39 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Analysis of Feature Teams
40
Issue – Lack of Conceptual Integrity
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Incompatible changes Shared design
Who owns it?
41
Issue – Technical Practices
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Manage concurrent access
Continuously integrate work
Sprint 1 Sprint 2 Sprint 3
Sprint 1 Sprint 2 Sprint 3
Sprint 1 Sprint 2 Sprint 3
42
Issue – Lack of Knowledge
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Need to understand large system
Need deep domain skills
Need deep technical skills
43
Issue – Non-functional Requirements
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
As a customer, I want to be one of 10,000 customers who can use the system during peak usage periods.
As a user, I want the site to be available 99.999% of the time I try to access it.
As the CTO, I want the new system to conform to our established security policies.
As a user, I want an interface in English, a Romance language and a complex language.
Who ensures the non-functional requirements?
44
Issue – Team Longevity
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Product 1 PB 1 Feature Team A
Product 2 PB 2 Feature Team A
?
45
Issue – Organizational Resistance
Interferes with fiefdoms
Too hard to reorganize into feature teams
A general belief that feature teams will lead to significant technical debt
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
46 Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Blended Team Examples
47 Copyright © 2007-2011, Innolution, LLC or Mountain Goat Software, Inc. All Rights Reserved.
Combined Feature & Component Teams
48
Teams with Fully Connected Communication Channels
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
49
Teams for Collaboration Clusters
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
50
Component Stewards/Guardians
One or more people that teach others about the component
Ensures changes maintain or improve conceptual integrity
Not the owner of the component; feature teams make the changes
Can also take a leadership role in promoting reuse
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
51
Create a Community of Practice from Feature Team Members
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
52
Deal with Problems/Opportunities that Age Poorly
Structure teams so we can attack problems that escalate fast or opportunities that disappear quickly
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
Problems Opportunities
53
Scaled Agile Framework Recommendation
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
54
Top Down System Level Approach
Copyright © 2007-2013, Innolution, LLC. All Rights Reserved.
What are your products?
What are your product backlogs?
What teams do you need to deliver on your goals?
55
Visual AGILExicon™
Slides in this presentation contain items from the Visual AGILExicon™, which is a trademark of Innolution, LLC and Kenneth S. Rubin.
The Visual AGILExicon is used and described in the book: Essential Scrum: A Practical Guide to the Most Popular Agile Process.
You can learn more about the Visual AGILExicon and permitted uses at: http://innolution.com/resources/val-home-page
56
www.essentialscrum.com
Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
57 Copyright © 2007 - 2012, Innolution, LLC. All Rights Reserved.
Contact Info for Kenny Rubin
Email: [email protected] Website: www.innolution.com Phone: (303) 827-3333 LinkedIn: www.linkedin.com/in/kennethrubin Twitter: www.twitter.com/krubinagile Essential Scrum: A Practical Guide to the Most Popular Agile Process
www.essentialscrum.com
Comparative Agility Website www.comparativeagility.com