Slidedeck from a workshop during Agile Testing Days 2016 in Potsdam on solving organizational problem for adopting agile.

1. Thinking Tools for solving three
Agile adoption problems
Markus Gärtner
@mgaertne @itagile

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

3. WHOLE PRODUCT FOCUS

4. Customer-centric
Customers don’t buy a part of the product, but
the whole product

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

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

7. Customer-centric
In your table groups, pick a product.
2 minutes

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

9. FEATURE TEAMS

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

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

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

13. Feature Team Adoption Map

14. CONTRACT GAME

29. Contract Games
Identify Contract Games and Secret Toolboxes in
your table group.
What would be a first step to change the
dynamic?
10 minutes

30. Debrief
Share in your table groups your core take-aways
7 minutes

31. Summary
• Customer-centric Whole Product Focus
• Feature Teams
• Contract Games

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

33. References
http://less.works