LeSS Practitioner
More with LeSS
Craig Larman craiglarman.com & less.works
Please... Do not copy or share this material, or re-use for other education. Exceptions require prior written consent of the author.
Copyright © 2016 Craig Larman, All rights reserved. May not be reproduced without written consent of the author. v.44 1 1 2
Opening Topics Scaling?
3 3 4 first, a caution... One of the directors of SAGE was discussing why the programming had gotten out of hand. He was then asked, “If you had it to do all over again, what would you do differently?” …
5 6 5 6
His answer: after years working in “Find the ten best large people and write multisite
the entire thing offshore themselves.” development, [Horowitz74] our key advice? …
7 8 7 8 but groups still ‘scale’, large - don’t for reasons…
multisite - don’t compelling (“create LTE”)
offshore - don’t questionable (“low-cost sites”)
9 10 9 10
Descaling & so is LeSS for scaling? Simplifying
11 11 12 “How can we apply is this the right agile at scale in our big question? … complex organization?”
13 14 13 14
This is an Important Question…
traditional large groups are complicated — though not “How can we simplify because they need to be, but the unnecessarily big and because their organizational complex organizational designs create an illusion of unnecessary complexity design, and be agile rather than do agile?”
15 16 15 16 LeSS descales organizational complexity, dissolving unnecessary complex organizational solutions, and solving in More with LeSS simpler ways.
17 18 17 18
Some Big Keeping it Simple Ideas
19 19 20 not here just to explore own “LeSS system”, rather: vs how to think about systems in general rent
21 22 21 22
The IKEA Effect
why
23 24 23 24 don’t believe “It is difficult to get a man to anything i say understand something when his job depends on not fads & gurus -> insight understanding it.”
rent -> own — Upton Sinclair
25 26 25 26
Guide: Job Safety, but not Role Safety
Practicalities
27 27 28 Course PDF & Room Photos at less.works
29 30 29 30
9:00
18:00
31 32 31 32 #LeSSWorks @less_works
33 34 33 34
local meetups Your this week? Backgrounds
35 35 36 (optional) team re-organization Introductions > diversity at each table
37 38 37 38
coach background? course overview? team: standing: round-robin > briefly (30 seconds each), we’ll defer these warm-up introduce each other topics until later today > when team done, please sit why? so day-1 morning is more focused on learning 39 40 39 40 Where are We?
1. Opening Topics System Optimization 2. System Optimization, not Local not Optimization Local Optimization 3. Organizational Structure 4. LeSS Overview 5.
41 42 41 42
what are we Local about to learn? Optimization
43 43 44 in traditional large- scale organizational individual: design, the overarching > write a definition of what you and repeating theme is think is local optimization
coach: review local optimization
45 46 45 46 focus on moving the ball?
examples of local optimization…
or on player job title? 47 48 47 48 focus on delivering dishes? Local Optimization Cognitive Bias
“Everyone is busy and doing their best, efficiently on their task, yet the system is delivering slow and not delighting the user.” or on chopping onions? 50 49 50
Local Optimization Cognitive Bias Local Optimization Cognitive Bias
> (incorrect) belief: optimizing a part optimizes “It’s more efficient or the whole system > locally optimize, for a person or sub-group: productive when a >local efficiency person/group does >local performance >local output
one specialization.” >local activity
51 52 51 52 Local Optimizations… Local Optimizations… are justified as “good/best/efficient” … are not thought of as sloppy quick-fixes or hacks … but their consequence is system- level sub optimization of (e.g.) they are justified as customer value, customer cycle time, customer delight, company “good/best/efficient” robustness, company adaptiveness
53 54 53 54
Local Optimization Cognitive Bias individual > think of 1 example of local Q: “Why are you doing that?” optimization you’ve seen A: “Because it’s best & efficient.”
coach: review and yet, the system-level consequence is a sub-optimization > compare & contrast “quick fixes” with local optimization
55 56 55 56 local optimization is a Why Local cognitive bias Optimization? list of cognitive biases?
57 58 57 58
Reinforcing Loop Local Optimization is related to…
> sub- > measurement & optimization metrics belief in local org support for > > optimization local optimization management by performance objectives management
> resource > appraisals management
59 60 59 60 group > examples of metrics or System objectives or “resource management” that led to local Optimization optimization?
61 61 62 Systems Optimization “watch the ball, not the players” the One True system optimizing goal? “deliver the dish, not the onions”
63 64 63 64 Systems Optimization
> there are no ‘good’ or ‘bad’ organizational systems coach > counter-intuitive example of a > but if the observed behavior is inconsistent with its espoused local optimization inconsistent optimizing goal, it is unskillful with system optimization goal?
65 66 65 66
Local vs Systems Optimization the LeSS System Goals
> local optimization is a local “best” or > company-level system “efficient” that… optimization for > sub-optimizes system optimization goal > deliver highest customer > often generates the “lean wastes” value (first) > overproduction, inventory, handoff, waiting, not using people’s full > agility (“turn on a dime, for a potential, hidden defects, … dime”)
67 68 67 68 Systems Thinking
70 69 70
What is the SYSTEM? Scaling Lean & Agile Development
Thinking and Organizational Tools > at least… for Large-Scale Scrum
Craig Larman Bas Vodde > the entire company +
> customers/markets +
> supply chain
> (it isn’t a group within a company)
71 72 71 72 Systems Thinking Systems Thinking
> understand there is a > optimize the whole > see the whole SYSTEM > beware local-optimization > optimize the whole > learn to reason about cognitive bias ‘any’ system, not 1 system > focus on > think & talk about system > see the whole, over space dynamics by drawing interaction and time systems model diagrams effects, not on in groups separate parts > see how things influence one another and the interaction effects
73 74 73 74
pairs: standing individual: > with your graphics (but without > draw a graphic for each looking at course notes), one systems thinking idea person explain to partner the > when done, please stand systems thinking ideas > please sit when done
75 76 75 76 Systems Thinking Sketch a System Model
learn to reason about ‘any’ system not just 1 system
how? … AKA causal loop diagram
77 78 77 78
we model to have a conversation own vs the output is shared understanding, not a model rent
79 80 79 80 Common Elements
coach: > sketch a system model
81 82 81 82
team > sketch a system model, given this: > “We don’t have time to create clean code, because we are too busy going slow because of dirty code.” > start with these variables; write them verbatim 1.% clean code 2.# defects coach: debrief 3.time available to craft clean code 4.time dealing with defects 5.time living with dirty code & its consequences 6.velocity 7.pressure to “go faster”
83 84 83 84 we model to have a conversation own vs the output is shared understanding, not a model rent
85 86 85 86 group Local > in LeSS, when do systems modeling? Optimization > in what contexts or in Backlogs meetings can it help?
87 87 88 team > sketch a system model, given this: let’s start to apply > 1 product, many teams, each team has a Team “Product Backlog” prioritized by a Team “Product Owner” > start with these variables verbatim; do NOT try to link this to old variables in system modeling to prior exercises… until you have finished linking these first 1.# backlogs (e.g. 1 backlog per team, 1 backlog for 2 teams, 1 backlog for all teams) “scaling agile” 2.quality of overview at product level 3.% of total (product) items a team knows well (requirements & design) organizational design 4.agility of teams to change direction at the company level 5.% of items worked on each Sprint that are highest value from a company view choices… 6.likelihood that a single team will see they may be working on low-value items, from a company view 7.local team identity
89 90 89 90 coach > if system optimizing goals are “local > highest value & agility, at optimization company level > … how many backlogs? in backlogs” > … is the answer “good” or “bad”?
91 92 91 92 LeSS Rule(s)
therefore… 1 Product Backlog
93 94 93 94
1 Product Backlog … and no “redefining” by calling a set of team educate: why backlogs “part of 1 Product Backlog”
95 96 95 96 supporting secondary own goals or constraints
vs (e.g. “team local identity”)
rent without sub-optimizing the system goal 97 98 97 98
1 Product Backlog
Scrum Guide:
“[Multiple Teams] often work and therefore… together on the same product. One Product Backlog is used to describe the upcoming work on the product.”
99 100 99 100 LeSS Rule(s)
1 (and only 1) biased by Product Owner choice of variables?
101 102 101 102
team “driving variables” > update your system model with the “good enough” model refined during the debrief
103 104 103 104 1 Product Backlog team > update your system model with but still these variables; replace # backlogs with: implicit > # explicit backlogs team queues > (note: a backlog is a queue) > # implicit queues
105 106 105 106
coach team > if system optimizing goals are > update your system model: > highest value & agility, at > % time teams spend on company level broader learning of more items > … in general, how many items should a team learn about?
107 108 107 108 LeSS Rule(s)
Do multi-team PBR and/or overall PBR to therefore… increase shared understanding and broader learning.
109 110 109 110
Local Optimization Cognitive Bias Descaling with LeSS remove the move towards
Q: “Why does each team local optimization of backlogs… 1 Product Backlog have a team backlog?” and 1 Product Owner that comes from: A: “Because it’s best, team backlogs (and all their org and most efficient.” design elements)
111 112 111 112 team: standing: round robin Opening Topics > most noteworthy or interesting idea so far? (again) > please sit when team is done
113 114 113 114 now that we’ve done some non-trivial learning, let’s Course return to warm up topics: Overview course overview, …
115 115 116 Agenda, Structure
1. part-1 is structured, in sequence time & structure… 2. part-2 according to your priorities & interests
117 118 117 118
Where are We?
1. Opening Topics 2. System Optimization, not Local Optimization “16:30 pm” drinks? 3. Organizational Structure 4. LeSS Overview 5.
119 120 119 120 Related LeSS Courses
> LeSS for Executives (2 days)
> Less LeSS (1-day) related knowledge…
121 122 121 122
Prerequisites When I say…
> understand one-team Scrum > “This question is related to standard 1-team Scrum…” > completed any pre-readings > am not saying this to make people feel bad that they might not know basic Scrum, but to delineate LeSS rules from Scrum rules
123 124 123 124 where’s the Q&A wall?
Q&A…
initials on question cards
125 126 125 126
individual > write 1 must-be-answered question on a card please hold “related/variant” > add your initials questions until Q&A sessions > put it on the question wall but do ask when, “I don’t understand”
127 128 127 128 coach: my questions: > # of people with primary skill programmer in one-shippable- objectives… product group? > domains? > role?
129 130 129 130
Likely Objectives: You can…
> redesign org from local > know & coach LeSS optimizations to global Sprint (events, coach system optimizations coordination, …) > > define a product > explain LeSS & LeSS discuss mindmap format & why broadly Huge frameworks
> motivate & define LeSS > explain LeSS principles org design (structure, & make connections team: with notes roles, policies, …) > answer “why LeSS?” > > advise on LeSS mindmap objectives > explain roles adoption
131 132 131 132 team > update the mindmap with learnings so far
133 134 133 134
My i hope to learn, too Background
136 135 136 Craig Larman First Two LeSS books…
Scaling Lean & Agile co-creator of LeSS (with Bas Vodde) Development
Thinking and Organizational Tools for Large-Scale Scrum
Craig Larman Bas Vodde large + multisite + ‘offshore’ large-scale embedded systems large-scale financial systems large-scale telecom systems
137 138 137 138
3rd LeSS book… One of the first agile books…
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B online at your cale
less.works S
crum Large-Scale account, too! Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
139 140 139 140 Architecture, Patterns, OO Design, …
> served as chief scientist @ Valtech
> helped create “agile offshore” in LeSS
> lived in Bengaluru
141 142 141 142
LeSS consultant @
> UBS > CISCO (& Tandberg) > ION > JPMorgan > BAML > Xerox > Ericsson > bwin.party, … > lead coach of lean software > Nokia Networks development @ Xerox
143 144 143 144 less.works
Learning Resources
146 145 146
The Addison-Wesley Signature Series Scaling Lean & Agile “Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L Development
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B Thinking and Organizational Tools
cale for Large-Scale Scrum
S Craig Larman crum Large-Scale Scrum Bas Vodde
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
147 148 147 148 craiglarman.com
149 150 149 150
System Optimization not Local Local Optimization Optimization in (again) Product Definition
151 151 152 Where are We?
1. Opening Topics 2. System Optimization, not Local Optimization what are we 3. Organizational Structure about to learn? 4. LeSS Overview 5.
153 154 153 154
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum Guide: Getting Started Narrow vs Broad Product Definitions More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
0. Educate Everyone
1. Define product
2. Define ‘done’
3. Have appropriately-structured teams
4. Only the Product Owner provides work for teams
5. Keep project managers away from teams
155 156 155 156 group team > sketch a systems model, given this: > suppose we want to do system > “I wonder about the impact of narrow versus broad product definitions on the system?” modeling that includes analysis > start with these variables verbatim: of narrow vs broad product 1. breadth of product definition 2. # products definitions 3. # explicit backlogs 4. % of items worked on each Sprint that are highest value from a company view 5. agility of teams to change direction at the company > what is the variable? level
157 158 157 158
team > add these variables verbatim: coach 1. organizational complexity from company view (e.g. # positions, # groups, degree of duplicated > if system optimizing goals are functions, complexity of processes) > 2. duplication (e.g. requirements, solutions, tasks, highest value & agility, at roles, groups, data, code, features) company level 3. # of inter-team task dependencies (i.e. a team probably has to wait for another team to do > … broader or narrower product “their part”) definition? 4. complete end2end customer feature cycle time
159 160 159 160 coach coach & teams together > if system optimizing goal is > add & discuss: > low complete end2end customer feature cycle 1. delivery & learning cycle time time, if recently reorganized (e.g. going broader, going > … broader or narrower product narrower) definition?
161 162 161 162
LeSS Rule(s) The definition of product should be as broad and end- user/customer centric as is therefore… practical. Over time, the definition of product might expand. Broader definitions are preferred.
163 164 163 164 own
educate: why vs
rent
165 166 165 166
supporting “IO Channels” & Product Definition secondary goals or constraints
(e.g. “delivery & learning cycle Google Maps? time, if recently reorganized”) without sub-optimizing the system goal 167 168 167 168 A “Broad” Product & Implicit Queues team “Oh yes, we have only one > add & link the following variables: broad product, and… 1. cognitive “fullness” of one Team-IOS: IOS items Product Owner to have whole- product overview and prioritize Team-Android: Android items” 2. cognitive “fullness” of people in teams to know ‘N' items
169 170 169 170
What happens to the Product Owner and Developers as the product therefore… gets broader and broader?
171 172 171 172 2 Frameworks: LeSS & LeSS Huge
divide
173 174 173 174
LeSS Huge: Requirement Areas LeSS Huge: Area Product Owners
175 176 175 176 LeSS Huge framework team > LeSS Huge framework is NOT per se desirable; why? … > add & link following variables:
> dividing -> local optimization 1. breadth of Requirement Area > a “necessary evil” so Product Owner & Developer heads don’t 2. # teams in Requirement explode ;) Area
177 178 177 178 coach > if system optimizing goals are > highest value & agility, at therefore… company level > … bigger or smaller Requirement Areas?
179 180 179 180 LeSS Rule(s)
Each Requirement Area how to define has between a broader product? … “4-8” teams.
181 182 181 182
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum Guide: Define Your Product 1. Expand Product as Broad as Possible More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
> customer focus: What would the end customers answer if we ask them, “What is the applying the product?” What spans the customer journey? expanding & > family: Family of similar products? Do we have components that are shared or functionality restraining that is the same across our current products? > system: Our product is part of? What problem questions… does the product solve for end customers?
183 184 183 184 Example: Financial Trading 2. Restrain your Product as Practical
> commonality: What is the product vision? Who are the customers? What is the product’s customer domain?
> structural boundaries: What development is within our company? How much structural change is practical?
185 186 185 186
Expanding Product Definition internal broad > as explored, sometimes “as broad product definition as ideal” isn’t immediately possible > then, this becomes the driver for vs continuous improvement: –“What prevents expanding the narrower external product definition?” multi-products definitions
187 188 187 188 Good Product Definitions? team > find 1 person with “big & complicated stuff” — could currently be viewed > common platform? > library? (not as one or many products/systems/applications/projects/programs/ applications (not directly sold) directly sold) > if none, join another team person (approx 7 min) > service or APIs? > front-end? > for the “big & complicated stuff”, sketch & explain a “block architecture” (not directly sold) diagram of > back-end? > major software & hardware components > the broader context that “stuff” is within > “component” or > a ‘project’ for team (approx 7 min) “module” or > apply the expanding & restraining questions to create an initial product some features? definition in LeSS “as broad as practical” “application”? (not > show the results of expanding with color-X dotted lines; and the results directly sold) of restraining with color-Y dotted lines
189 190 189 190
Good Product Definitions?
> common platform? > library? (not (not directly sold) directly sold) > service or APIs? > front-end? portfolio (not directly sold) > back-end? management… > “component” or > a ‘project’ for “module” or some features? “application”? (not directly old)
191 192 191 192 team coach > sketch a systems model, given this: > > “We are scaling agile. Therefore we need portfolio … is there a relationship between narrow management.” products/programs/value-streams and > start with these variables: the apparent need for portfolio 1. organizational complexity at the company level 2. broadness of products/programs/value-streams management? 3. # of products/programs/value-streams > (note that we have already discovered 4. need for and activities of “portfolio management” 5. # people involved in “portfolio management” that narrow product definitions are 6. ease of first making & executing large-direction decisions inconsistent with global optimization of 7. ease of changing & executing large-direction decisions highest value and agility)
193 194 193 194
Self-inflicted Wound “Portfolio Management” So-called “Agile” Portfolio Management?
the apparent need for “program/value- > narrowly-defined products/ stream portfolio management” is a… programs/value-streams must be prioritized and funded self-inflicted wound consequence of the unnecessary complexity… > it’s big-batch requirements prioritization driven by the created by the narrow product/ program/value-stream definitions existence of these narrow products, programs, or value streams
195 196 195 196 necessary & real LeSS simplifies or portfolio management eliminates vs the need for self-inflicted-wound “portfolio management” by broader product definitions portfolio management
197 198 197 198
LeSS Rule(s) The definition of product should be as broad and end- user/customer centric as is therefore… practical. Over time, the definition of product might expand. Broader definitions are preferred.
199 200 199 200 Tips for “Real” Portfolio Management Local Optimization Cognitive Bias
Q: “Why do you have narrow products, programs, or value streams?” A: “Because it’s best, and most efficient.”
201 202 201 202
Descaling with LeSS The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L remove the move towards
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale local optimization in S
crum Large-Scale Scrum product, program, broader product portfolio management… definition More with LeSS that comes from: Craig Larman Bas Vodde narrow products, programs, value streams
with Illustrations by Sketch Post (& their org design elements)
203 204 203 204 Local Optimization in Programming
205 205 206
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Where are We? Scrum Guide: Getting Started More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
1. Opening Topics 0. Educate Everyone 2. System Optimization, not Local 1. Define product Optimization 2. Define ‘done’ 3. Organizational Structure 3. Have appropriately-structured teams 4. LeSS Overview 4. Only the Product Owner provides work for teams 5.
207 208 207 208 Component Teams component teams have some advantages, but let’s start with the issues…
209 210 209 210
“the group learns to scale agile therefore… and really changes!”
211 212 211 212 LeSS Rule(s)
The majority of the “…majority…” ? teams are customer-focused contexts for feature teams. component teams?
213 214 213 214
Local Optimization Cognitive Bias
Q: “Why do you have educate: why component teams?” A: “Because it’s best, and most efficient.”
215 216 215 216 analysis of component team “Conway’s Law” & Component Teams dynamics could have been done via system modeling…
rather than “tell a story” “Conway’s Law” doesn’t mean what some think… as a coach, you may want to practice doing it as a model
217 218 217 218
What did Conway Actually Say? (1968) Anyways, Justification by? …
Conclusion: sacred texts gurus companyX did it everyone’s doing it etc.
219 220 219 220 Anyways, Justification by? … want to see the explanation again?
sacred texts gurus companyX did it everyone’s doing it etc.
221 222 221 222
Descaling with LeSS The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L remove the move towards i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
local optimization of crum Large-Scale programming… feature teams Scrum coding cross- More with LeSS that comes from: components with Craig Larman component shared code Bas Vodde teams (a single- specialist group) with Illustrations by Sketch Post
223 224 223 224 Scaling Lean & Agile Development
Thinking and Organizational Tools for Large-Scale Scrum PBR & Craig Larman Bas Vodde Prioritization in LeSS
225 225 226
preparation: at end of section, you will be teaching “all” of its what are we ideas with others, without about to learn? referring to notes !
227 228 227 228 LeSS PRODUCT BACKLOG REFINEMENT S H OVERALL O R pairs : standing (without notes) PRODUCT OWNER T
PRODUCT -
TEAM OR TEAM OR I BACKLOG S REPRESENTATIVE(S) REPRESENTATIVE(S) H REFINEMENT > 1 person explain the activities PRODUCT BACKLOG
ITEMS SELECTED FOR REFINEMENT in Overall PBR 5 M B
A - U C
L K 1 T L I - 0 O T G E % >
A R other person explain the M
PRODUCT E S F I
N P P R
BACKLOG E R M O
TEAM USERS MIXED GROUP USERS MIXED GROUP I D E N REFINEMENT U
& STAKEHOLDERS FROM TEAMS & STAKEHOLDERS FROM TEAMS N
C activities in Multi-Team PBR T T T > please sit when finished
PRODUCT BACKLOG
229 230 229 230
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- C ike oh team: standing cates well, is easy to understand, and is a pleasure to n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B > ways that the one (and only cale S
crum Large-Scale one) Product Owner can learn Scrum more about existing items? More with LeSS
Craig Larman > ways that Teams can feedback Bas Vodde noteworthy discoveries to the with Illustrations by Sketch Post Product Owner?
231 232 231 232 Specification by Example
let’s take an introductory look at specification with examples (real case) clarification/ specification… … + 20 more examples
233 234 233 234
it’s Scrum, so any let’s take an technique is possible introductory look at prioritization… for example…
235 236 235 236 Weighted-Sum Relative-Point Prioritization Business-Value & Risk Estimation
237 238 237 238
Scaling Lean & Agile class/coach: Development Thinking and Organizational Tools for Large-Scale Scrum
Craig Larman > is it probable that a Product Bas Vodde Owner needs to know the “row 3, column J” value in the specification of an item, to prioritize and do visioning?
239 240 239 240 Where are We?
1. Opening Topics Local Optimization 2. System Optimization, not Local in Optimization 3. Organizational Structure Analysis & Design 4. LeSS Overview 5.
242 241 242
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum Guide: Getting Started More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
0. Educate Everyone
1. Define product
2. Define ‘done’
3. Have appropriately-structured teams
4. Only the Product Owner provides work for teams
5. Keep project managers away from teams
243 244 243 244 Lean Wastes in Product Development
1. Over-production—of 7. Defects & finding/ intermediate, WIP, or correcting—tasks to find & finished things; sooner, correct: test, inspect, faster, greater than demand review, modify 2. Inventory—intermediate, 8. Not using people’s full team: at wall/flipchart WIP, or finished things potential—working to title, not multi-skilling > 3. Over-processing—& extra write: what lean wastes are processes, rediscovery 9. Knowledge/information scatter/loss—& connection implied by the cartoon? 4. Handoff—& transport to handoff & inventory & 5. Task switching—& motion rediscovery; communication barriers: 6. Waiting—& delay indirection, 1-way flows
245 246 245 246
the story of stories team: sitting > connections between local- optimization & lean wastes? > connections between separate analysts or designers & lean wastes?
coach: review
247 248 247 248 p. 223
Ward wrote, “I chose that name [stories] because the story only suggested the need to the degree that the developers and customers could talk about it.”
249 250 249 250
we’re not lean & agile " then the group goes to intermediates talk to “Scrum” and “agile” users, create the artifacts, training, and learn… and hand them off to developers
251 252 251 252 now we’re “lean & agile”! now we’re “lean & agile”!
intermediates Product intermediates Product Owners talk to users, Owners talk to users, create the artifacts create the artifacts stories, and hand them stories, and hand them off to developers off to developers 253 254 253 254
1985: What was this Role Called? 1985: What was this Role Called?
Users & ???? Dev Team Users & Business Analyst Dev Team Customers Customers talks to users talks to users clarifies needs clarifies needs analyzes analyzes specifies specifies … … 255 256 255 256 Present Time: What’s Changed?
Users & “Product Owner” Dev Team Customers (Business Analyst) talks to users clarifies needs analyzes specifies … 257 258 257 258
Lean Wastes in Product Development
1. Over-production—of 7. Defects & finding/ intermediate, WIP, or correcting—tasks to find & finished things; sooner, correct: test, inspect, widespread faster, greater than demand review, modify 2. Inventory—intermediate, 8. Not using people’s full misunderstanding of WIP, or finished things potential—working to title, not multi-skilling 3. Over-processing—& extra the role of processes, rediscovery 9. Knowledge/information scatter/loss—& connection 4. Handoff—& transport to handoff & inventory & Product Owner?… 5. Task switching—& motion rediscovery; communication barriers: 6. Waiting—& delay indirection, 1-way flows
259 260 259 260 261 262
so-called do “Product Owner” real Product Managers = Business Analyst do specifications & for the Team analysis? …
263 264 263 264 Classic Product Manager
>“CEO of the product” so-called >vision >road mapping “Product Manager” >competitor analysis
>market & customer analysis = >pricing Business Analyst >channel development
265 266 265 266
team
> sketch a systems model, given this: > 1 product, 1 Product Backlog, many teams > 1 real Product Owner prioritizes the 1 Product Backlog (no team-level “product backlogs”) > each Team has a so-called “Product Owner”, who is not doing hands-on development > start with these variables 1. % of total (product) items a team knows well (requirements & design) 2. # so-called “Product Owners” 3. likelihood so-called “Product Owners” are doing lots of analysis & talking to users therefore… 4. likelihood so-called “Product Owners” create intermediate artifacts 5. % wastes (e.g. inventory, over production, handoff, info scatter, waiting …) 6. likelihood programmers are doing lots of analysis & talking to users 7. ability of programmers to communicate effectively with customers/users 8. degree that programmers have empathy and awareness of customers 9. degree that programmers understand the business domain 10. degree that so-called “Product Owners” are a bottleneck 11. degree that programmers can independently make informed item-level decisions
267 268 267 268 LeSS Rule(s) Clarification vs Prioritization
Prioritization goes through Product Owner, but clarification is as much as possible directly between the Teams and customer/ users & other stakeholders.
269 270 269 270
LeSS Rule(s)
1 (and only 1) educate: why Product Owner
271 272 271 272 coach > in changing to the Scrum organizational structure, where are people in these roles supposed to go? scaling Scrum… > Analysts > UX/UI Designers > analyst-“Product Managers” > analyst-“Product Owners”
273 274 273 274 naive Scrum scaled duplicates naive Scrum ‘scaled’: “PO”-per-team, multiple Scrum Teams unaware of the system dynamics: Large-Scale Scrum: multiple-Teams Scrum “PO”-per-team = analyst 275 276 275 276 Local Optimization Cognitive Bias
Q: “Why do you have team-level ‘Product Owners’?” Q: “Why do you have a dedicated the analyst manager person doing analysis & design?” A: “Because it’s best, and most efficient.”
277 278 277 278
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
279 280 279 280 Descaling with LeSS remove the move towards local optimization of team: standing: round robin analysis & design… feature teams > clarifying & most noteworthy or interesting that comes from: designing with users idea since last discussion? separate analysts > and designers please sit when done
281 282 281 282
Local Optimization in Planning: The Contract Game
283 283 284 Where are We? Business-R&D Collaboration Change
1. Opening Topics [Business] is used to “throwing the project over the wall” and holding 2. System Optimization, not Local engineering/development responsible Optimization for meeting needs. Scrum puts this 3. Organizational Structure responsibility back on the Product Owner and customers through the 4. LeSS Overview inspect and adapt and the Sprint Review. 5.
285 286 285 286
the Contract/Commitment Game
287 288 287 288 Scrum ends the Contract Game…
[Business] is used to “throwing the project over the wall” and holding engineering/development responsible for meeting needs. Scrum puts this responsibility back on the Product Owner and customers through the inspect and adapt and the Sprint Review.
-Ken Schwaber
289 290 289 290
who is the Product Owner in this case?…
291 291 292 team: standing > why does the “Contract/Commitment Game” appear to make things go faster in the short run, but also generates > lower transparency > more “fear” handling deadlines… > more local optimization > more Technical Debt > more Organizational Debt coach: review
293 294 293 294
Sprint Forecast, not “Commitment” team: standing > in Scrum, does the Team make Scrum Guide: a commitment to delivering “A, B, C, D” items in the Sprint? “Sprint Planning Topic One: What can be done this Sprint? The Development Team works to coach: review forecast the functionality”
295 296 295 296 team: standing > what is the relationship between the “Contract/Commitment Game” system dynamics (which assumed a many- why? … months duration) and the system dynamics of a Team making a scope commitment in a two-week Sprint?
coach: review
297 298 297 298
Types of Scope & Date Deadlines team: standing > artificial internal scope & date deadlines > in Scrum, does the Product > artificial external scope & date deadlines not bound by a commercial contract Owner have a scope & date deadline assigned to her from > internal scope and date deadlines to align with (e.g.) Marketing on a deployment someone else?
> external commercial scope & date deadlines coach: review
299 300 299 300 Powerful Product Owner + Customer Collaboration + Adaptive Planning
> artificial internal scope & date deadlines
> artificial external scope & date deadlines not bound by a commercial contract
> internal scope and date deadlines to align with (e.g.) Marketing on a deployment
> external commercial scope & date deadlines
302 301 302 team: standing the Contract Game is meant to > in Scrum, identify at least FIVE ways the end in basic Scrum Product Owner can adapt towards meeting “valid” scope & date deadlines, without pushing cascading i.e. we have been reviewing a basic commitments down to the Team each Scrum & Agile concept Sprint but… coach: review
303 304 303 304 projects … but the change implications are programs especially clear in large-scale… cascading commitments where organizational elements are “baked in” for the Contract/ PMO, Commitment Game… project & program managers managing projects/programs 305 306 305 306
Local Optimization Cognitive Bias
Q: “Why do you have the Contract/Commitment there is no blame Game in planning?” A: “Because it’s best.”
307 308 307 308 want to see the explanation again?
educate: why
309 310 309 310
Descaling with LeSS remove the move towards local optimization of planning… adaptive planning by Contract Game & a business-side that comes from: Product Owner Experts the Contract Game (and all its org design elements)
311 312 311 312 From Local to Systems Optimization
313 313 314
Descaling with LeSS
remove the move towards
local optimization in backlogs… 1 Product Backlog to summarize… and 1 Product Owner that comes from: team backlogs (and all their org design elements)
315 316 315 316 Descaling with LeSS Descaling with LeSS remove the move towards remove the move towards local optimization in local optimization in product definition… broader product programming… feature teams definition coding cross- that comes from: narrow products, that comes from: components with programs, value component shared code streams (& their org teams (a single- design elements) specialist group)
317 318 317 318
Descaling with LeSS Descaling with LeSS remove the move towards remove the move towards local optimization of local optimization in analysis & design… feature teams planning… adaptive planning by clarifying & a business-side that comes from: designing with users that comes from: Product Owner single-specialist the Contract Game analysts and (and all its org designers design elements)
319 320 319 320 descaling & Organizational simplifying with LeSS Structure
321 322 321 322
Where are We?
1. Opening Topics 2. System Optimization, not Local Organize by Optimization Customer Value: 3. Organizational Structure 4. LeSS Overview Feature Teams 5.
323 323 324 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum Guide: Getting Started More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
0. Educate Everyone what are we 1. Define product 2. Define ‘done’ about to learn? 3. Have appropriately-structured teams
4. Only the Product Owner provides work for teams
5. Keep project managers away from teams
325 326 325 326
Descaling with LeSS
replace local optimizations of defining single-specialist groups feature teams… with a majority of
feature teams
327 328 327 328 Learning, Multi-Learning People
Skills: code, test, Skills: analysis, Skills: code, analysis test, test, Skills: analysis document document, art
Skills: document, Skills: UI test design, Skills: test, art, analysis test
329 330 329 330
Generalization & Specialization: Generalization & Specialization: T-Shaped Worker T-Shaped Team, too!
HI design Regulatory Javascript
Stocks
Bond trading Swift Bonds 331 332 331 332 Feature Teams, Learning a Feature Team is full stack… works across all code/components in a “shared code” model
333 334 333 334
LeSS Rule(s) Structure the organization using real teams as organizational building block.
Each team is therefore… (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.
The majority of the teams are customer-focused feature teams.
335 336 335 336 analysts and/or mgr UX/UI designers
DBAs mgr a likely traditional architects mgr large-scale adopting organizational component-1 structure before feature teams… programmers mgr adopting Scrum component-2 mgr programmers
test/QA mgr group 337 338 337 338 analysts and/or analysts and/or mgr mgr UX/UI designers UX/UI designers
DBAs mgr DBAs mgr single-specialist groups are dissolved architects mgr a cross-functional architects mgr team in Scrum (and thus the component-1 component-1 mgr spans all functions mgr programmers programmers functional & component manager component-2 component-2 mgr mgr roles are eliminated) programmers programmers test/QA test/QA group mgr group mgr 339 340 339 340 Guide: Job Safety, but not Role Safety “It is difficult to get a man to understand something when Job safety his job depends on not understanding it.” & salary safety but not — Upton Sinclair role safety
341 342 341 342
Self-Designing Teams Workshop
“let me show you the org chart of my decision for the new feature teams”
343 344 343 344 (optional) connecting to connecting to Scrum Masters line managers
345 346 345 346
team: standing > new roles for > ex-functional-team managers > ex-component-team managers > ex-project & program managers > ex-team-leads, ex-tech-leads > ex-team-level “Product Owners” coach: discuss
347 347 348 Only Title: (Product) Developer
Scrum Guide:
“Scrum recognizes no titles for don’t wait for Development Team members other the org chart than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.”
349 350 349 350
Not a Team of Single-Specialists Managers/Leads Don’t Direct Workers
Scrum Guide: Scrum Guide: “...the Team isn’t allowed to act on “Team does not contain sub-teams what anyone else says [except the dedicated to particular domains Product Owner] … Teams are such as testing or analysis” self-organizing…” hence, no team/tech leads
351 352 351 352 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum Guide: Getting Started More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
0. Educate Everyone a
k
t
o u
o r e
-S B cale
1. Define product S crum Large-Scale Scrum 2. Define ‘done’ More with LeSS
3. Have appropriately-structured teams Craig Larman Bas Vodde 4. Only the Product Owner provides work for teams
with Illustrations by Sketch Post 5. Keep “project managers” away from teams
353 354 353 354
Scaling Lean & Agile Development
Thinking and Organizational Tools for Large-Scale Scrum
Craig Larman Bas Vodde team work
355 356 355 356 Larman’s Laws of Organizational Behavior
357 357 358
Larman’s 4 Laws of Organizational Behavior why so much?… 1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level Lean-but manager and “specialist” positions & power structures. 2. As a corollary to (1), any change initiative will be reduced to overloading or redefining the new Scrum-but terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be Kanban-but derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which DevOps-but deflects from addressing weaknesses and manager/ specialist status quo. AnyChangeIdea-but 4. Culture follows structure (or culture follows system)
359 360 359 360 Where are We?
1. Opening Topics 2. System Optimization, not Local LeSS Overview Optimization 3. Organizational Structure 4. LeSS Overview 5.
361 362 361 362
now that we’ve discovered LeSS for LeSS ourselves via “why”… Overview summarize what…
363 363 364 preparation: at end of section, you will be sketching and teaching “all” of its ideas with others, without referring to notes !
365 366 365 366
Principles 2 Frameworks: LeSS & LeSS Huge
367 368 367 368 (smaller) LeSS Framework
smaller LeSS framework…
369 370 369 370
1 Common Sprint, 1 Shippable Product
PRODUCT VISION PRODUCT CREATION & DIRECTION TEAMS & DELIVERY PRODUCT OWNER - CREATE PRODUCT - PROVIDE VISION AND DIRECTION - DELIVER PRODUCT INCREMENT - PRIORITIZE FEATURES - COORDINATE AND INTEGRATE - UNDERSTAND USERS AND MARKETS - IMPROVE PRODUCT CREATION - SUPPORT ORGANIZATIONAL - CLARIFY FEATURES STRATEGIC DIRECTION - UNDERSTAND USER AND DOMAIN,WORK WITH THEM
SCRUMMASTER - COACH ORGANIZATION - SUPPORT CONTINUOUS IMPROVEMENT
MANAGERS optional in LeSS, but - IMPROVE CAPABILITY OF DEVELOPMENT SYSTEM most organizations have - DECIDE STRUCTURE AND POLICIES
ORGANISATIONAL CAPABILITY IMPROVEMENT
371 372 371 372 Adoption team: standing > narrow & deep > why is there > not broad & shallow > (1) one common Sprint ending in (2) a shippable > (smaller LeSS FW) nice: “50” people, 1 product? product, 1 site, 6+ months > top-down & bottom up > volunteering; don’t push coach: review
373 374 373 374
pairs: standing: wall/flipchart > without referring to notes, one individual of the two people teach the > briefly review this module ideas in this section to your partner, by… talking and sketching the ideas
375 376 375 376 Why LeSS? (our biases)
> company-level systems optimization for
> deliver highest customer value why LeSS… > agility (“turn on a dime, for a dime”) > transparency
> whole-product focus
> empirical process control
377 378 377 378
Why LeSS? Occupational Psychology shu - ha - ri
my story with the RUP
owning versus renting
“barely sufficient”
-> more with less
379 380 379 380 Rules Prescription & Shu - Ha - Ri
one person per team > sketch and explain “prescriptiveness & LeSS rules” “barely sufficient methodology”
381 382 381 382
Why LeSS? (our biases)
We don’t want more roles, leads to less responsibility as that to the Teams.
We don’t want more artifacts, leads to a greater distance as that between Teams and customers. we want more with less leads to a greater distance We don’t want more dedicated between Teams and customers, analysts or designers, as that more handoff problems, and less engagement & empathy.
We don’t want more supplied leads to less learning & process & “best practices” & team ownership of process & “renting”, as that engaged improving.
383 384 383 384 pairs: standing > one person explain to another (without notes), why… > not more roles? > not more artifacts? LeSS Huge… > not more dedicated analysts & designers > not more supplied process & “best practices” & “renting” > reverse & repeat
385 386 385 386
LeSS Huge: Requirement Areas LeSS Huge: Area Product Owners
387 388 387 388 LeSS Huge Sprint: “Stack of LeSS”
389 390 389 390
Adoption First LeSS Adoption
391 391 392 Pre-Adoption: Building Interest
think & act like a politician, preparation: at end of section, not like an engineer you will be sharing “all” of its ideas with others, without referring to notes !
393 394 393 394
Pre-Adoption: Building Interest Pre-Adoption: Building Interest?
> give “LeSS 1 or 3” book to key people Scaling Lean & Agile Development > 1 “proof of concept” feature team, Thinking and Organizational Tools > book clubs for Large-Scale Scrum Craig Larman Bas Vodde working on major high-value end-to- > send LeSS video links to people
> find internal senior-manager champion end features, but still surrounded by
> find & grow allies the traditional organization for the > just talk directly with senior managers existing product > external expert talk—“you’re never a prophet in own land” > > hold & promote events to build interest: will this clearly & definitely build –LeSS Practitioner, LeSS for Executives, Less LeSS interest? …
395 396 395 396 team: standing > complications of introducing 1 feature team while surrounded by a large traditional organization? > e.g. 5 component teams with private code, misc single-function teams (BA, HI, Test, …) therefore… > per definition the 1 feature team is doing > shared/open code across entire product > all functional activities, e.g. analysis, HI design, integration, all testing
397 398 397 398
LeSS Rule(s)
For the product group, establish the complete all-at-once LeSS structure “at the “flip the system” start”; this is vital for a LeSS adoption.
399 400 399 400 system kaizen vs point kaizen educate: why examples where point kaizen creates more problems 401 402 401 402
Reminder: LeSS Guides Guide: Three Principles
> LeSS has guides –LeSS book-3
–this course The Addison-Wesley Signature Series “Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
403 404 403 404 1. Deep and narrow over Scope of First Adoption broad and shallow
don’t drown your organization, first learn to swim “50” team members
1 product
preferably 1 site
no fun! real learning! “6” months before another
405 406 405 406
2. Top-Down & 3. Use Volunteering Bottom-Up
Top Down: Provide needed Bottom-up: support understanding why, volunteering, energy versus of engagement
407 408 407 408 Dr. Kotter…
a sense of urgency or Dr. J. Kotter on existential crisis needs to be felt by the Resistance to Change senior management, to introduce meaningful change, else it unlikely to succeed
409 410 409 410
Guide: Getting Started Guide: Getting Started
0. Educate Everyone
1. Define product
2. Define ‘done’
3. Have appropriately-structured teams
4. Only the Product Owner provides work for teams
5. Keep managers away from teams
411 412 411 412 0. Educate Everyone
> focus on why, not what
> readings
> educate all together (not role)
> courses: Scrum, LeSS
413 414 413 414 prepare for shippable & shipping shipping awesomeness speaks louder by first Sprint than words why?…
415 416 415 416 Guide: Ship at Least Every Sprint
Ship at Least Supporting Change Every Sprint
417 418 417 418
pair or team: individual > teach back exercise > briefly review this module > please sit when done
419 420 419 420 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
421 422 421 422
LeSS Stories
424 423 424 reminder…
1 “50 person” group stories? not entire company
425 426 425 426
team: standing: round robin > one especially noteworthy or interesting idea since last discussion? > please sit when done
427 428 427 428 Guide: Feature Team Adoption Map
Feature Team Adoption Map
430 429 430
Incremental Feature Team Adoption so far, we have assumed the initial > extreme multi-site specializations > politics related to group structures
creation of “complete” > a full-stack feature involves ‘20’ feature teams components and therefore ‘20’ developers > initially-imperfect “done” due to constraints
> LeSS Huge (many of the above issues) but sometimes…
431 432 431 432 when feature-team adoption must be incremental, analyze with a Feature-Team Adoption Map …
433 433 434
group of products “solution”, “suite” coach whole product > demonstrate creating a feature-team
bigger code area adoption map, for an incremental “subsystem”, “layer” adoption case
small code area > mark where “potentially shippable” “component”, “module”, “application”, “block”, > current state? “service” Technology Scope Inside Team Technology > next state? code unit test . > improvement experiments? Activity Scope Inside Team 435 436 435 436 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum More with LeSS Why LeSS?
Craig Larman Bas Vodde
with Illustrations by Sketch Post
437 438 437 438
Agile & Scrum: Original Messages team > sketch a systems model, given this: > “large, detailed, framework for scaling, with many claimed best practices” is pushed onto a group by senior managers or consultants > start with these variables > what is the ‘driving’ variable in this scenario? > degree of feeling of ownership and engagement by hands-on people “barely sufficient” in their processes & structures, and in improving them > degree of acceptance of specious arguments (e.g. argument by “best practices”, “gurus”, “sacred texts”, “they do it”, …) > degree of fear if dissent “empirical process control” > degree of public dissent > degree of private dissent > degree of unnecessary or inappropriate processes & practices
439 440 439 440 Why LeSS? Occupational Psychology
team > sketch a systems model, given this: > “large, detailed, framework for scaling, with many claimed best practices” is pushed onto a group by senior managers or my story with the RUP consultants, and then the group is invited to tailor it down. > in addition to the prior variables, include at least > what is the ‘driving’ variable in this scenario? owning versus renting > degree of explicit or implicit goal to remain similar to status quo > expectation to “get our money’s worth” > expertise by the group to customize the framework -> more with less > similarity of the full framework to status quo > degree of desire to shift blame “to the framework”, when problems
441 442 441 442
More with less
Build your why not just advise framework up from a few simple core elements, based on “think & experiment”? from “why” don’t tailor it (i.e., zero prescription) down
443 444 443 444 shu - ha - ri Rules Prescription & Shu - Ha - Ri
“barely sufficient methodology”
445 446 445 446
Why “Rules”? Shu & Focus on Creating…
> global systems optimization for:
> highest value, agility one person per team
> transparency > sketch and explain “prescriptiveness & LeSS rules” > whole-product focus
> empirical process control
447 448 447 448 Why LeSS? (part 1, our biases)
> global systems optimization for
> deliver highest customer value
> agility (“turn on a dime, for a dime”)
> transparency More with LeSS … > whole-product focus
> empirical process control
449 450 449 450
Why LeSS? (part 2, our biases) Why LeSS? (part 3, our biases)
We don’t want more roles, leads to less responsibility We want more responsible Teams by having less roles. as that to the Teams.
We don’t want more artifacts, leads to a greater distance We want more customer-focused by having less artifacts. as that between Teams and customers. Teams building useful products
leads to a greater distance We want more customer-focused We don’t want more dedicated between Teams and customers, empathetic Teams that deeply by less dedicated analysts. analysts, as that more handoff problems, and less engagement & empathy. understand requirements
We don’t want more supplied leads to less learning & We want more Team ownership by having less supplied process & “best practices” & team ownership of process & of process & meaningful work processes & “best practices”. “renting”, as that engaged improving.
451 452 451 452 LeSS Sprint
453 454 453 454
(smaller) LeSS Framework
Preparation Meetings
455 455 456 Preparation Meetings Self-Designing Teams Workshop
> Educate everyone > Community kickoff meetings > Define Product > Initial Product > DoD meeting Backlog refinement > Feature-Team > Current-Architecture Adoption Analysis Learning Workshop (e.g., with a Map) > Agile Modeling > Self-Designing Design/Architecture Teams meeting Workshop
457 458 457 458
Community Kickoff meetings Guide: Initial Product Backlog Refinement
create shared understanding
useful activities?
459 460 459 460 Guide: Current-Architecture Workshop Guide: Multi-Team Design Workshop
Chapter 39: Documenting Architecture 461 462 461 462
coach: questions?
463 464 463 464 LeSS Product Backlog Refinement
466 465 466
LeSS PRODUCT BACKLOG REFINEMENT Guide: Multi-Team PBR S H OVERALL O PRODUCT OWNER R T
PRODUCT -
TEAM OR TEAM OR I BACKLOG S REPRESENTATIVE(S) REPRESENTATIVE(S) H REFINEMENT PRODUCT BACKLOG
ITEMS SELECTED FOR REFINEMENT 5 M B
A - U C
L K 1 T L I - 0 O T G E %
A R M
PRODUCT E S F I
N P P R
BACKLOG E R M O
TEAM USERS MIXED GROUP USERS MIXED GROUP I D E N REFINEMENT U
& STAKEHOLDERS FROM TEAMS & STAKEHOLDERS FROM TEAMS N C T T T
PRODUCT BACKLOG
467 468 467 468 Clarification vs Prioritization
Teams emphasize learning customer domains (not just tech domains)
469 470 469 470
PO or PO Team creating any specifications, documents, designs, mockups, wireframes, … and handing them off to teams
472 471 472 Types of PBR Estimation synchronization
473 474 473 474
Guide: Take a Bite Guide: Splitting
the major work different interfaces, Use cases I/O channel TRADITIONAL SPLITTING LeSS SPLITTING flows or use cases e.g., GUI or command OF BIG FEATURE OF BIG FEATURE line a specific sequence Scenario Data format XML, … TAKE A BITE of steps TO START subset of the data e.g., novice or power Data part Role or persona elements user
Varying types of e.g., moderate vs high Type Non-functional kinds of things throughput
integration between system operation, Integration existing (or non- Operation e.g., HTTP GET existing) elements varying working with a fake Configuration Stub ALL-AT-ONCE IN EQUAL PARTIAL SPLITTING configurations, e.g., first PIECES AT THE BEGINNING AND TAKING A BITE OS or browser
475 476 475 476 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde individual: with Illustrations by Sketch Post (optional) coach: > scan the section on splitting big > find a candidate giant item items > demonstrate splitting it
477 478 477 478
Vertical Slices, Not “Make Big Parts & Integrate” iterative & evolutionary, not “build components” The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
example from: Jeff Patton with Illustrations by Sketch Post
479 480 479 480 481 482 481 482
LeSS Sprint preparation: you will be creating a video soon, of Sprint Planning Planning
484 483 484 LeSS SPRINT PLANNING S E C L L E A C O T R F I
I O I SPRINT F T N PRODUCT OWNER I C E
PLANNING 1 A M TEAM OR TEAM OR & T
S F
REPRESENTATIVE(S) REPRESENTATIVE(S) I O I N N A
PRODUCT BACKLOG L
SELECTED ITEMS SELECTED ITEMS I N S I P T R M I I & N A U T
L L P
P T
SPRINT L L I D - A A T N E E
PLANNING 2 N A N S I M I N G G N
2
SPRINT BACKLOG SPRINT BACKLOG SPRINT BACKLOG
485 486 485 486
Guide: Sprint Planning One
class Scrum Master Product Owner > are there task dependencies representatives from each team between teams, in 1 product? Product Manager > in Sprint Planning, do people (& domain expert) need to analyze and plan for “dependency management”?
487 488 487 488 Task dependencies between teams? None exist in a LeSS group -> Sprint Planning Two shared work, opportunities to work together 489 490 489 490
team/class: > prepare post-Sprint Planning > improv! recap meeting > video it > silent movie. miming! props! > about a “2 minute” complete shot > one continuous movie shot
491 492 491 492 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
493 494 493 494
class Coordination > “It’s Tuesday 2pm. I see a coordination problem. The & Integration Scrum of Scrums meeting is tomorrow at 11 am.”
496 495 496 LeSS Rule(s) We Observe…
Prefer decentralized > the more formal coordination and informal methods in place, the less coordination over coordination is happening centralized coordination.
497 498 497 498
LeSS Rule(s)
Cross-team coordination is decided class: why? by the teams.
499 500 499 500 We Observe…
> coordination techniques need therefore, the to be especially situational and customizable in large most advanced groups coordination technique in LeSS?…
501 502 501 502
Guide: Just Talk (for Sprint delivery)
The problem with large- scale coordination isn’t what coordination technique to use, but knowing there’s a need to coordinate, and who
JUST TALK to talk with.
503 504 503 504 Guide: Communicate in Code use the code to tell you there’s a need to coordinate, and who to talk with the surprising “social coding” tools such as GitHub COMMUNICATE IN CODE or GitLab meaning of plugins that tell you who worked on the code, and initiates chats integrate continuously… continuous integration
505 506 505 506
continuous integration continuous integration
means to means to
integrate continuously have a build server
507 508 507 508 Guide: Integrate Continuously
> use the code to tell you barriers to integration there’s a need to coordinate, are and who to talk with barriers to coordination
509 510 509 510
Guide: Communities traditionally > people from different coordination supported teams participate for integration, a cross-team concern, e.g. Architecture but we can flip it to COMMUNITIES integration supports
coordination > (see next section)
511 512 511 512 Guide: Multi-Team Design Workshop
we model to have a conversation
the output is shared understanding, not a model … with agile modeling 513 514 513 514
Guide: Current-Architecture Workshop … Videos, …
Chapter 39: Documenting Architecture 515 516 515 516 Guide: Component Mentors
> regular feature- team member barriers to integration > does NOT approve are barriers to other’s code COMPONENT MENTOR coordination commits; is not a “committer gate”
517 518 517 518
Guide: Traveler Guide: Maybe Don’t do Scrum of Scrums
TRAVELER
519 520 519 520 Guide: Leading Team Rotate Infrastructure Tasks Across Feature Teams > start work on a big item (or family of items) > build system, etc. > start solo > slowly rotate > as more teams join, they educate them
item 1 item 2 > NB: no separate specialist item 3 infrastructure/tools groups …
521 522 521 522
Guides in LeSS: Coordination
1. Just Talk 7. Component Mentor 2. Communicate in Code 8. Travelers 3. Integrate 9. Maybe Don’t Do SoS teams or pairs Continuously 10.Leading Team 4. Communities > teach back exercise 11.Scouts 5. Multi-Team Design 12.Open Space > please sit when done Workshops 13.Cross-Team Meetings 6. Current-Architecture Workshops 14.Mix & Match
523 524 523 524 The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
525 526 525 526
meetings Communities
527 527 528 Communities (for Coordination) Communities? For…
> learning
> speculative solutions > cross-team agreements –they can’t make decisions for teams, but can make proposals that teams decide to adopt
529 530 529 530
Tips for Good Communities
> have a community > focus on concrete coordinator with problem-solving goal passion for the concern > has agreed how they and desire to cultivate a work and make decisions communities do not strong community; is an active hands-on > might have a Scrum do “the work” practitioner Master who helps it work > actively try to recruit participation from most > are strongly encouraged teams within the organization
531 532 531 532 How to Kill Communities
> there is no or bad > has members that community are not in feature coordinator teams beware fake > holds frequent > are considered meetings just for secondary and communities! the sake of it; blah participation is blah meetings downgraded because “we’re too busy to participate”
533 534 533 534
Minimal Recommended Communities? Community Activities & Outputs
> organizing > teaching education or > UX & HI > defining proposed coaching guidelines or > Architecture > learning & sharing standards between > creating members > Test speculative design > investigating in a design workshops
535 536 535 536 Variants
> cross-product communities
> site communities
537 538 537 538
Technical Excellence
540 539 540 Specification by Example
541 542 541 542
Specification by Example specification with examples (real case)
executable specifications “without change”, with automated validation
543 544 543 544 technical excellence
545 546 545 546
LeSS SPRINT REVIEW & RETROSPECTIVE
SPRINT REVIEW TEAM PRODUCT OWNER TEAM USERS LeSS & STAKEHOLDERS
TEAM RETROSPECTIVE Sprint Review TEAM TEAM
OVERALL RETROSPECTIVE MANAGER SCRUMMASTER PRODUCT OWNER SCRUMMASTER TEAM REP.
548 547 548 Guide: Sprint Review Bazaar
in-Sprint early item feedback
549 550 549 550
Sprint Review “Bazaar” Q&A
LeSS Sprint Retrospective
551 551 552 LeSS SPRINT REVIEW & RETROSPECTIVE Guide: Overall Retrospective (multisite)
SPRINT REVIEW TEAM PRODUCT OWNER TEAM USERS & STAKEHOLDERS
TEAM RETROSPECTIVE TEAM TEAM
OVERALL RETROSPECTIVE MANAGER SCRUMMASTER PRODUCT OWNER SCRUMMASTER TEAM REP.
553 554 553 554
Systems Modeling The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
555 556 555 556 Done & Undone
557 558 557 558
class Done > for one sample large-scale product, tasks to have a shippable product?
560 559 560 perfect DoD an imperfect DoD is = especially common in shippable DoD large-scale groups first = moving to LeSS potentially shippable
561 562 561 562
Improving DoD over Time
2 year2 month improvementimprovement 104 monthyear goal goal goal goal
goal: expand customer analysis marketing pricing implement doc material unit test update customer performance test production manufacturing test process done undone
needed to be potentially current Definition of Done shippable 563 564 563 564 Perfect DoD - Imperfect DoD
= Undone Work
565 566 565 566
Perfection Goal
Handling perfect DoD = shippable Undone Work? covered in next section no Undone Work
567 568 567 568 LeSS Rule(s) LeSS Adoption Tip
1 Definition of Done if possible, solve the problems so you can have a perfect DoD before Sprint 1 not for each team why? (teams can extend base version)
569 570 569 570
I WANT TO SHIP PRODUCT OWNER
R1-20 R21-40 R41-60 NOW Undone
UNDONE UNDONE
RISK AND LACK OF TRANSPARENCY DELAY AND LACK OF FLEXIBILITY
571 572 Release Sprint… by TEAMS Lean Wastes in Product Development
1. Over-production—of 7. Defects & finding/ I WANT intermediate, WIP, or correcting—tasks to find & TO SHIP PRODUCT finished things; sooner, correct: test, inspect, OWNER faster, greater than demand review, modify
R1-20 R21-40 R41-60 NOW 2. Inventory—intermediate, 8. Not using people’s full WIP, or finished things potential—working to title, not multi-skilling 3. Over-processing—& extra RELEASE processes, rediscovery Knowledge/information SPRINTS 9. scatter/loss—& connection 4. Handoff—& transport to handoff & inventory & 5. Task switching—& motion rediscovery; communication barriers: UNDONE UNDONE UNDONE 6. Waiting—& delay indirection, 1-way flows
573 574 573 574
and… you should NOT need a Release Sprint; but it to get to perfect DoD may be a temporary “necessary evil” during Teams learn by doing early transition to LeSS
575 576 575 576 Frequent “Semi-Release Sprints” Undone Work has: what if there were ‘7’ risk Sprints before the delay 1 2 3 4 5 6 7 8 9 10 Release Sprint?
ship semi- true it! (a bad idea; rather, ship every Sprint) Release somewhat Release weak Sprint improved Sprint perfect DoD DoD DoD
577 578 577 578
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale get to perfect DoD Scrum A S A P More with LeSS Craig Larman Bas Vodde
with Illustrations by Sketch Post
579 580 579 580 coach: DevOps > discuss questions
581 581 582
Realizing “DevOps” implies…
> extending the DoD to include since we’re exploring operations tasks shipping, what about > increasing the cross-functionality of DevOps? … the feature teams > dissolving and merging in the Operations group into feature teams
583 584 583 584 DevOps thought leaders on DevOps …
585 586 585 586
Larman’s 4 Laws of Organizational Behavior 1. Organizations are implicitly optimized to avoid why does changing the status quo middle- and first-level manager and “specialist” positions & power structures. “fake DevOps” 2. As a corollary to (1), any change initiative will be reduced to overloading or redefining the new arise? terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing “DevOps team”, pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/ “DevOps specialist” specialist status quo. 4. Culture follows structure (or culture follows system)
587 588 587 588 LeSS Huge LeSS Huge Framework
589 589 590
2 Frameworks: LeSS & LeSS Huge team > sketch a systems model, given: > one Product Owner, for a product with 20 teams > what are the noteworthy variables?
591 592 591 592 Requirement Areas
“8” is not a magic number
593 594 593 594
Requirement Areas are SLOWLY DYNAMIC coach > for some participant in a “huge” context, your possible requirement areas?
595 596 595 596 An Area can’t have only 1 Team
Market Onboarding Area Feature Teams team
Team Team Team > sketch a systems model, given: > Team Team Team many small (e.g. 1 or 2-team) Requirement Areas > reminder: each RA has an Area Exceptions? When Regulatory & Control Area Feature Teams Backlog, and teams are in 1 area starting to grow a new Team area, that is “sure” to > what are the noteworthy variables? become big. 597 598 597 598
LeSS Rule(s) “Area Backlog”
Each Requirement Area has between “4-8” teams. Avoid violating this range.
599 600 599 600 Area Backlogs via Views Area Backlogs via Separate Artifacts
a VIEW for one an ARTIFACT for one requirement area requirement area
it is NOT a it IS a separate separate artifact artifact
601 602 601 602
Area Backlogs via Separate Artifacts
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Area Backlogs as Scrum More with LeSS
Craig Larman Bas Vodde
views with Illustrations by Sketch Post vs Area Backlogs as separate artifacts
603 604 603 604 “Area Product Owners” “Product Owner Team” Market Onboarding Market Onboarding 1 “overall” Area Product Owner 1 “overall” Area Product Owner Product Product Owner Owner
Regulatory & Control Regulatory & Control Area Product Owner Area Product Owner
...... 605 606 605 606
PO Team with analysts, UX/UI designers, responsibilities of the architects, project Product Owner? managers
607 608 607 608 Guide: Product Owner Team Meeting “Area Feature Teams”
> issue: losing whole-product focus or alignment between areas in the choice of themes and items > each Area Product Owner shares their situation and upcoming goals, and they discuss opportunities to align
> Product Owner can provide high-level guidance
> discuss the results of the previous Sprint Review meetings in each Requirement Area, as input to planning > include some team reps for learning and feedback
> include 1 Scrum Master to support reflection and improvement
609 610 609 610
Huge Structure LeSS Huge: “Stack of LeSS” e.g. Product Management group
undesirable, but common in Huge contexts, especially early on 611 612 611 612 The Addison-Wesley Signature Series Scaling Lean & Agile “Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L Development
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B Thinking and Organizational Tools
cale for Large-Scale Scrum
S Craig Larman crum Large-Scale Scrum Bas Vodde
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
613 614 613 614
Rarely… Total All-at-Once
> maybe, if…
>relatively small (e.g. 12 teams, 2 Areas)
LeSS Huge >lifetime short
>single-specialization low Adoption >one site > warning! do NOT underestimate the massive amount of learning and coaching required
616 615 616 LeSS Rule(s)
LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach. but more common… Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor.
617 618 617 618
Guide: Evolutionary Incremental Adoption Guide: Parallel Organizations
> two alternatives: > focused deeper adoption at a part of the product group
> gradual incremental adoption over the whole product group
619 620 619 620 Guide: Parallel Organizations Guide: One Requirement Area at a Time
> focused deeper adoption at a part of the > focused deeper adoption at a part of the product group product group
> gradual, low-risk, well-suited for huge LeSS > “all at once” in only one Requirement Area Huge product groups > is there some high-benefit low-risk area? > key drawback? takes a long time > wicked problem: the new org model exists > must: abandon private code interacting closely with the old model
> don’t: allow branching > must: abandon private code
621 622 621 622
Guide: Transitioning to Feature Teams The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
> gradual incremental adoption over the whole product group n
a
k
t
o u
o r e
-S B > gradually expand component team responsibility cale S
crum Large-Scale > use feature-team adoption map Scrum > context: huge, multi-site, high learning across sites required More with LeSS > problems:
Craig Larman > drawbacks of both feature and component teams while Bas Vodde not giving the best benefits > hard to adopt customer-centric Requirement Areas with Illustrations by Sketch Post when the teams are still component teams
623 624 623 624 LeSS Rules
625 626 625 626
LeSS Rules
the LeSS rules define the 2 frameworks
628 627 628 Scaling Sweet Spot & Shu-Ha-Ri
“we don’t want rules”
so why do they exist? “barely sufficient methodology”
629 630 629 630
Why “Rules”? Shu & Focus on Creating…
> transparency individual > whole-product focus > scan the LeSS rules (+ Huge) > global systems optimization > (optional) record questions > empirical process control
631 632 631 632 coach: LeSS Principles > discuss questions
633 634 633 634
LeSS Principles
636 635 636 LeSS Principles LeSS Principles Large-Scale Scrum is Scrum—It is not “new and improved Scrum.” And it is Continuous improvement towards perfection—Create and deliver a product in no not “One-team Scrums at the bottom, and something different on top.” time, with no cost and no defects, that utterly delights customers, improves the Rather, LeSS is about figuring out how to apply the principles, elements, and environment, and makes lives better. Do humble and radical improvement purpose of Scrum in a large-scale context. experiments each Sprint towards that. Systems thinking—See, understand, and optimize the whole system (not parts), and Empirical process control—Inspect & adapt processes, organizational design, do causal-loop modeling to explore system dynamics. Avoid the local and sub- & practices to craft a contextually-appropriate organization based on Scrum, optimizations of focusing on the ‘efficiency’ of individuals and individual teams. rather than following a detailed script. Customers care about the overall concept-to-cash cycle time and flow, not individual steps. Transparency—Based on tangible ‘done’ items, short cycles, working together, common definitions, and driving out fear in the workplace. Lean thinking—Create an organizational system whose foundation is manager- teachers who apply and teach systems thinking and lean thinking, manage to Whole-product focus—One Product Backlog, one Product Owner, one improve, and who practice Go See and Help at gemba. Add the two pillars of Shippable Increment, one common Sprint—regardless if there are 3 or 33 respect for people and continuous improvement. All towards the goal of perfection. teams. Customers want the product, not a part. Queuing theory—Understand how systems with queues behave in the R&D Customer-centric—Identify value & waste in the eyes of paying customers. domain, and apply those insights to managing queue sizes, work- in-progress limits, Reduce cycle time from their perspective. Do user-centered design. Increase multitasking, work packages, and variability. feedback loops with real customers. More with LeSS—See prior section.
637 638 637 638
team: round robin > without notes… LeSS Roles > “charades” to communicate each principle
639 640 639 640 Why Learn 3 Types of Development?
Where is the > where is the Product Owner? Product Owner? > major “pattern” groupings? 3 Types of Development
642 641 642
(External) Product Development Internal (Product) Development
643 644 643 644 (Outsourced) Project (Product) Development The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum
More with LeSS
Craig Larman Bas Vodde
RECEIVER & USER OF PRODUCT OUTSOURCER with Illustrations by Sketch Post
645 646 645 646
PRODUCT VISION PRODUCT CREATION & DIRECTION TEAMS & DELIVERY PRODUCT OWNER - CREATE PRODUCT - PROVIDE VISION AND DIRECTION - DELIVER PRODUCT INCREMENT - PRIORITIZE FEATURES - COORDINATE AND INTEGRATE - UNDERSTAND USERS AND MARKETS - IMPROVE PRODUCT CREATION - SUPPORT ORGANIZATIONAL - CLARIFY FEATURES STRATEGIC DIRECTION - UNDERSTAND USER AND Product DOMAIN,WORK WITH THEM SCRUMMASTER - COACH ORGANIZATION - SUPPORT CONTINUOUS IMPROVEMENT
MANAGERS optional in LeSS, but Owner in LeSS - IMPROVE CAPABILITY OF DEVELOPMENT SYSTEM most organizations have - DECIDE STRUCTURE AND POLICIES
ORGANISATIONAL CAPABILITY IMPROVEMENT
648 647 648 LeSS Rule(s) Guides in LeSS: Product Owner
There is one Product Owner and one Product > Who Should be Product > Customer Backlog for the complete shippable product. Owner? Collaborations over...
The Product Owner shouldn’t work alone on > Who are those Users/ > Ship At Least Every Product Backlog refinement; it is mostly done by Customers? Sprint the multiple Teams working directly with > Prioritization over > Don’t Be Nice customers, users, and other stakeholders. Clarification > Let Go All prioritization (ordering) goes through the > Don’t Do It > Product Owner, but clarification is as much as Don’t Let Undone Work possible directly between the Teams and customer, > Helpers be Your Undoing users, and other stakeholders. > Five Relationships
649 650 649 650
5 relationships The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale
HIGHER S
crum Large-Scale MANAGEMENT SCRUM MASTER Scrum
More with LeSS PRODUCT OWNER Craig Larman Bas Vodde
with Illustrations by Sketch Post CUSTOMERS TEAMS /USERS
651 652 651 652 PRODUCT VISION PRODUCT CREATION & DIRECTION TEAMS & DELIVERY PRODUCT OWNER - CREATE PRODUCT - PROVIDE VISION AND DIRECTION - DELIVER PRODUCT INCREMENT - PRIORITIZE FEATURES - COORDINATE AND INTEGRATE - UNDERSTAND USERS AND MARKETS - IMPROVE PRODUCT CREATION - SUPPORT ORGANIZATIONAL - CLARIFY FEATURES STRATEGIC DIRECTION - UNDERSTAND USER AND Scrum Master DOMAIN,WORK WITH THEM SCRUMMASTER - COACH ORGANIZATION - SUPPORT CONTINUOUS IMPROVEMENT
MANAGERS optional in LeSS, but - IMPROVE CAPABILITY OF most organizations have in LeSS DEVELOPMENT SYSTEM - DECIDE STRUCTURE AND POLICIES
ORGANISATIONAL CAPABILITY IMPROVEMENT
654 653 654
LeSS Rule(s)
Scrum Masters are responsible for a well- team: standing working LeSS adoption. Their focus is > towards the Teams, Product Owner, What may happen if the big organization, and development practices. group is moving to LeSS and…
A Scrum Master doesn’t only focus on a team > “a Scrum Master is only but on the overall organizational system. allowed to serve 1 Team”
A Scrum Master is a dedicated full-time role. > or, “a Scrum Master can serve 6 One ScrumMaster can serve 1-3 teams. Teams”
655 656 655 656 Guides in LeSS: Scrum Masters The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh > > cates well, is easy to understand, and is a pleasure to i n M read.” S Scrum Master Focus Scrum Master L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r
e
Surviving Guide -S B > Five Scrum Master cale S
crum Large-Scale Tools > Scrum Master Scrum Reading List > Large-Group More with LeSS Facilitation > Especially Pay Craig Larman Attention To... Bas Vodde > Promote Learning & > Multiple Skills Avoid Requirement with Illustrations by Sketch Post Area Silos > Community Work
657 658 657 658
teams > traditional activities/ Managers in responsibilities of managers (program, project, functional, LeSS component, resource, team, …)
coach: discuss
660 659 660 Manager Responsibilities
> the “other” column tasks
> corporate admin tasks, etc. “where are my teams?”
661 662 661 662
Manager Responsibilities
PRODUCT VISION PRODUCT CREATION & DIRECTION TEAMS & DELIVERY PRODUCT OWNER - CREATE PRODUCT - PROVIDE VISION AND DIRECTION - DELIVER PRODUCT INCREMENT - PRIORITIZE FEATURES - COORDINATE AND INTEGRATE - UNDERSTAND USERS AND MARKETS - IMPROVE PRODUCT CREATION - SUPPORT ORGANIZATIONAL > corporate admin tasks, etc. - CLARIFY FEATURES STRATEGIC DIRECTION - UNDERSTAND USER AND DOMAIN,WORK WITH THEM > customer-value-delivery SCRUMMASTER - COACH ORGANIZATION - SUPPORT CONTINUOUS IMPROVEMENT capability of org system
MANAGERS optional in LeSS, but - IMPROVE CAPABILITY OF DEVELOPMENT SYSTEM most organizations have - DECIDE STRUCTURE AND POLICIES
ORGANISATIONAL CAPABILITY IMPROVEMENT
663 664 663 664 do you recall? … Manager Responsibilities
> corporate admin tasks, etc. imperfect > customer-value-delivery product definition capability of org system > expanding product definition imperfect > expanding feature teams feature teams 665 666 665 666
Focus of Different Roles LeSS Rule(s) In LeSS, managers are optional, but if managers do exist their role is likely to change. Their MANAGERS PRODUCT OWNER focus shifts from managing the ORGANIZATIONAL PRODUCT FOCUS SCRUM MASTER TEAMS FOCUS day-to-day product work to improving the value-delivering capability of the product development system.
667 668 667 668 LeSS Rule(s) Guide: Go See at Gemba
Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance”.
669 670 669 670
Guide: Theory (of mind) Y Management teams > make 2 lists: Agile Principle 5: …Give them > Theory-of-mind X assumptions & the environment and support behaviors they need, and trust them to > Theory-of-mind Y assumptions & get the job done. behaviors coach: discuss
671 672 671 672 Guide: LeSS Metrics with Less Targets class > scenario: > who > some manager says, “let’s > metrics created by the Teams measure each team’s velocity” themselves, or Product Owner > the result is, “TeamRed has a > purpose higher velocity than TeamBlue” > to learn & improve > what dysfunctions arise?
673 674 673 674
LeSS Metrics: Don’t… Metaphor: Host (… manager)
> …let anyone other than team members or the Product Owner create metrics
> …measure for comparing teams or people
675 676 675 676 The Addison-Wesley Signature Series Scaling Lean & Agile “Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L Development
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B Thinking and Organizational Tools
cale for Large-Scale Scrum
S Craig Larman crum Large-Scale Scrum Bas Vodde
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
677 678 677 678
Part 1 -> Part 2
679 680 679 680 Sample Topics in the Course Material
> Adoption > Sprint Review
> Feature-Team Adoption Maps > Retrospectives (especially relevant in incremental > Done & Undone pair/triplet LeSS Huge adoptions) > DevOps > Why LeSS? > LeSS Huge > read following slides for ideas, > Preparing for Sprint 1 > LeSS Rules > Product Backlog Refinement & write new topics/questions, 1 > LeSS Principles > Sprint Planning > Product Owner per paper > Coordination & Integration (architecture, sharing tasks, > Managers communities, learning, …) > Scrum Masters > Technical Excellence
681 682 681 682
The Addison-Wesley Signature Series Scaling Lean & Agile “Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L Development
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B Thinking and Organizational Tools
cale for Large-Scale Scrum
S Craig Larman crum Large-Scale Scrum Bas Vodde
More with LeSS
Craig Larman Bas Vodde
with Illustrations by Sketch Post
683 684 683 684 coach > organize the topic/questions priorities with the group
685 686 685 686
Likely Objectives: You can…
> redesign org from local > know & coach LeSS optimizations to global Sprint (events, system optimizations coordination, …)
> define a product > explain LeSS & LeSS Closing broadly Huge frameworks > motivate & define LeSS > explain LeSS principles org design (structure, & make connections roles, policies, …) > answer “why LeSS?” > advise on LeSS > explain roles adoption
687 688 687 688 Certified LeSS Practitioner Your Account @ less.works
The Addison-Wesley Signature Series
“Kent is a master at creating code that communi- ke Coh cates well, is easy to understand, and is a pleasure to i n M read.” S L
i A
arge — Erich Gamma, IBM Distinguished Engineer g
n
a
k
t
o u
o r e
-S B cale S
crum Large-Scale Scrum –the LeSS books More with LeSS > Craig Larman i will register you at Bas Vodde less.works – course with Illustrations by Sketch Post –flipchart/whiteboard/wall photos –course notes pdf > you can change your email –contacts address at any time –certificate
689 690 689 690
Connections
LeSS Site: http://less.works
LinkedIn Group: LeSS - Large-Scale Scrum
LinkedIn Group: Certified LeSS Practitioner
Slack: https://less-works.slack.com/
LeSS Discussion Group: https://groups.google.com/forum/#!forum/largescalescrum #LeSSWorks LeSS Twitter: #LeSSWorks @less_works LeSS on Facebook https://www.facebook.com/less.works
691 692 691 692 share blog team: round-robin: standing tweet > “how do i feel?…” spread the word > please sit when team is done
693 694 693 694
class: photo
695 695