Less Framework introduction

1. www.odd-e.com | steven@odd-e.com
More with LeSS

2. 2

3. Unused features
3
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%

4. 4

5. Interview your customers!
• Using Controlled Experiment to validate ideas and collect information.!
• Saying “No” supported by data and avoid creating useless features
5

6. Shipping desirable features!
6
Having a shippable
product increment
every iteration
forces changes in
practices
Timeframe is too short
for old practices

7. Principles behind practices
• Quick feedback!
• Do one thing!
• Full feedback!
• Quality saves time!
• Forest and trees!
• Automate
7

8. Technical Practices
Emergent
Design
Refactoring Pair-programming
Test-Driven
Development
8
Continuous
Integration
Discuss
in workshop
Develop
in concurrence
Deliver
for acceptance
Acceptance
Test-Driven
Development

9. 9 Product Backlog

10. Examples
10 Product Backlog

11. Examples Unit Tests
11 Product Backlog

12. Extending “done”
12
implement
unit test
goal:
expand
analysis
customer
test
customer
doc
performance
test
marketing
material
production
pricing
update
manufacturing
process
current Definition on Done needed to be potentially
shippable
done
undone
2 year
improvement
goal
10 year
improvement
goal
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.

13. What’s worse than having a mess?
13

14. LeSS Principles and Themes
14

15. Up to 8 teams
15

16. More teams
16

17. 17

18. Organizing around components?
18

19. More coordination effort
19

20. Falling back to waterfall
20

21. 21
Alternative: Feature teams

22. Scaling Continuous Integration
22

23. Migrating from Component Teams
23

24. Organizing work with
Requirement Area
24

25. Larman’s Laws Of
Organizational Behavior
1. Organizations are implicitly optimized to avoid changing the status quo:
middle- and first-level manager and “specialist” positions and 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”, and “needing pragmatic customization for local concerns” --
which deflects from addressing weaknesses and manager / specialist
status quo!
4. Culture follows structure
25

26. Growing software in short cycle
26

27. Summary
• Team work - long lived, self-organized, cross-functional, feature!
• Optimize the whole - avoid hand off!
• Quality saves you time, with lots of automation!
• Only validated demands go into product backlog!
• Culture follows structure
27