Thinking Tools	for solving three
Agile	adoption problems
Markus	Gärtner
@mgaertne @itagile
Introductions
Form	pairs,	ideally	with	strangers,	and	answer	
the	following	questions:
• What	big	challenges	do	you	bring	to	this	
workshop?
• What	do	you	hope	to	get	from	this	workshop?
Each	person	goes	1	minute,	then	switch,	3	
rounds
WHOLE	PRODUCT	FOCUS
Customer-centric
Customers	don’t	buy	a	part	of	the	product,	but	
the	whole	product
Customer-centric
Important	Guidelines
• Parts	of	software	that	are	not	integrated	into	
the	whole	product	have	no	value	yet.
• Teams	who	finished	their	part	are	not	done	
until	it	is	integrated.
• Whenever	there	is	a	choice	to	optimize	a	team	
output	or	the	whole	product,	we	always	chose	
the	whole	product.
Customer-centric
Eliminate	Waste
1. Over-production
2. Inventory
3. Over-processing	(includes	
extra	processes),	relearning
4. Hand-offs
5. Task-switching,	motion	
between	tasks,	interrupt-
driven	multi-tasking
6. Waiting	and	Delays
7. Defects,	testing/inspection	
and	correction	at	the	end
8. Not	using	people’s	full	
potential:	“working	to	job	
title”,	no	multi-skill,	no	
multi-learning,	no	kaizen,	…
9. Knowledge	and information
scatter or loss
Customer-centric
In	your	table	groups,	pick	a	product.
2 minutes
Customer-centric
Expand	the	product	definition
• What	would	the	end	customers	answer	if	we	
ask	them,	“What	is	our	product?”
• Do	we	have	components	that	are	shared	or	
functionality	that	is	the	same	across	our	
current	products?
• Our	product	is	part	of?	What	problem	does	
the	product	solve	for	end	customers?
10	minutes
FEATURE	TEAMS
Feature	Teams
Feature	Teams Component	Teams
Optimized	for	delivering	the	maximum	
customer	value
Optimized	for	delivering	the	maximum	
number	of lines	of	code
Focus	on	high-value	features	and	system	
productivity (value	throughput)
Focus	on	increased	individual	productivity	
by	implementing	‘easy’	lower-value	
features
Responsible for	complete	customer-
centric	feature(s)
Responsible	for	only	part	of	a	customer-
centric	feature(s)
‘modern’	way	of	organizing teams	–
avoids	Conway’s	Law
Traditional	way	of	organizing	teams	–
follows	Conway’s	Law
Leads	to	customer	focus, visibility,	and	
smaller	organizations
Leads	to	‘invented’	work	and	a	forever-
growing	organization
Minimized	dependencies between	teams	
to	increase	flexibility
Dependencies	between	teams	lead	to	
additional	planning
Source: http://www.featureteams.org/
Feature	Teams
Feature	Teams Component	Teams
Focus	on	multiple	specializations Focus	on	single	specialization
Share	product	code	ownership Individual/team	code	ownership
Shared	team	responsibilities Clear	individual	responsibilities
Supports	iterative	development Results	in	‘waterfall’	development
Exploits	flexibility: continuous	and	broad	
learning
Exploits	existing	expertise:	lower	level	of	
learning	new	skills
Requires	skilled	engineering	practices	–
effects	are broadly	visible
Works	with	sloppy	engineering	practices	–
effects	are	localized
Provides	a	motivation	to	make	code	easy	
to	maintain	and	test
Contrary	to	belief,	often	leads	to	low-
quality	code	in	component
Seemingly	difficult	to	implement Seemingly	easy	to	implement
Source: http://www.featureteams.org/
Feature	Teams
Restrain	the	product	definition
• What	is	the	product	vision?	Who	are	the	
customers?	What	is	the	product’s	customer	
domain?
• What	development	is	within	our	company?	
How	much	structural	change	is	practical?
10	minutes
Feature	Team	Adoption	Map
CONTRACT	GAME
Contract	Games
Identify	Contract	Games	and	Secret	Toolboxes	in	
your	table	group.
What	would	be	a	first	step	to	change	the	
dynamic?
10	minutes
Debrief
Share	in	your	table	groups	your	core	take-aways
7 minutes
Summary
• Customer-centric	Whole	Product	Focus
• Feature	Teams
• Contract	Games
Remember	Larman’s Laws
1. Organizations	are	implicitly	optimized	to	avoid	changing	the	status	quo	
middle- and	first-level	manager	and	“specialist”	positions	&	power	
structures.
2. As	a	corollary	to	(1),	any	change	initiative	will	be	reduced	to	redefining	
or	overloading	the	new	terminology	to	mean	basically	the	same	as	status	
quo.
3. As	a	corollary	to	(1),	any	change	initiative	will	be	derided	as	“purist”,	
“theoretical”,	“revolutionary”,	“religion”,	and	“needing	pragmatic	
customization	for	local	concerns”	– which	deflects	from	addressing	
weaknesses	and	manager/specialist	status	quo.
4. Culture	follows	structure.
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Or
ganizational_Behavior
References
http://less.works
Thinking tools for solving three Agile adoption problems

Thinking tools for solving three Agile adoption problems