Thinking tools for solving three Agile adoption problems
1 like1,059 views
Slidedeck from a workshop during Agile Testing Days 2016 in Potsdam on solving organizational problem for adopting agile.
More Related Content
What's hot (20)
Viewers also liked (11)
Similar to Thinking tools for solving three Agile adoption problems (20)
More from Markus Gärtner (17)
Recently uploaded (20)
Thinking tools for solving three Agile adoption problems
- 1. Thinking Tools for solving three Agile adoption problems Markus Gärtner @mgaertne @itagile
- 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
- 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
- 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/
- 14. CONTRACT GAME
- 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