1. Improving Software
Development at Scale:
Promise and Pitfalls
Dr Andy Carmichael
Head of Agile Services, Clearvision-CM.com
@andycarmich - #LLKD14

2. Software development at scale
is particularly hard
Scale changes the problem
Software is hard

3. Outline of this session…
Improving Software
Development at Scale:
Promise and Pitfalls

4. Improvement
• Improvements suffer the
J-Curve syndrome
• Small step improvements
(Kaizen) may alleviate deep dips
in performance
• Radical change might also be
needed (Kaikaku) but may not
“stick”
• Kanban is an IMPROVEMENT
method based on the
Lean flow paradigm

5. Improving Software
Development at Scale:
Promise and Pitfalls

6. What is Kanban?
An approach for managing and improving the
flow of value from knowledge work?
Process

7. WORK FLOWS
(not all work does flow – but concentrate on the “work that flows”)

8. A short definition of Kanban needed
in order to be scale-free
1. See work as flow
2. Start from here and evolve
3. Make work and policies visible;
Make validated improvements
See also: “The Shortest Possible Definition of Kanban and why it matters for scaling”
#KLRAT13 and #LKUK13 – Slideshare: http://slidesha.re/1mbvNsb
Lean Flow
Paradigm
Foundational
Principles
Core
Practices

9. The Twitter Version
Essence of Kanban
see flow
start here
with visible work & policies
validate improvements
Also see: "How to Adopt Kanban" @andycarmich

10. Improving Software
Development at Scale:
Promise and Pitfalls

11. 2 scaling mechanisms
• Scaling by “not scaling”
o use service-orientation concept to build a network of
independently operating but interdependent services
o balance work flowing between different kanban systems
• Scale through “scale-free” understanding
o same approach applied to different units of flow at different time
scales

12. 3 (or 4) Scales of Kanban
• Personal / small team
• unit of flow: Task
• time scale: hours
• Service delivery / workflow
• unit of flow: Work item e.g. User Story
• time scale: days
• Product
• unit of flow: Project, Epic, MVP or MMF
• time scale: months
• Portfolio
• unit of flow: “Product Holding”
• time scale: months/year(s)
Decisionmakingat
differentlevelshave
differingscopeand
purpose

13. Decision Flows between Scales
• Personal / small team
• Service delivery / workflow
• Product
• Portfolio
Decisionmakingat
differentlevelshave
differingscopeand
purpose
 Personal forecasts and blockages – Daily Stand-up
 Team goals and priorities
 Cost-Schedule forecasts and blockages – Operations Meeting
 Product goals and priorities
 Cost-Benefit-Schedule forecasts (“P/E ratios”)
 Investment goals and priorities
Implementation
options
Product
options
Investment
options

14. Outline of this session…
Improving Software
Development at Scale:
Promise and Pitfalls

15. Pitfalls: Mild insults & non-
communication
• keep the „chickens‟ silent while the „pigs‟ speak
Subtext: management is not committed
• keep the „geeks‟ away from the „suits‟
Subtext: the technical concerns are for lower-level discussions

16. Pitfall 1: Adopting Agile
Frameworks without the Values or
Enabling Practices
• Frequent integration and/or delivery without
automated testing
• “Agile planning”… fixed scope and schedule
• Water-scrum-fall
• Hierarchical management/communication

17. Pitfall 2: Ignoring
dis-economies of scale
• Inside every large project there are small
ones trying to get out
• Inside impossibly-massive projects (just say
no!) there may be feasibly-large ones

18. @MartinBurnsSV
Architecture
• Components and acyclic
dependency graph
• Policies to facilitate non-
functional requirements
compliance
• Processes to improve time to
quality
• Architecture is not “arm-waving”
• It‟s not “non-technical”
• It‟s not disconnected from
organisation structures
(Conway‟s Law)
Pitfall 3: Thinking architecture is
primarily about function…
or that it‟s optional

19. Pitfall 4: Thinking dependencies in
plans are there to be managed
Most must be eliminated!

20. Pitfall 5: Thinking agility is a
quality without a cost
Is it valued by the organisation?
Is predictability valued more?

21. Pitfalls 6 & 7: Interventions…
• We have done those things that we ought not
to have done (Instruction Giving)
• We have left undone those interventions we
ought to have done (System Thinking)
RESPECT
CONTINUOUS
IMPROVEMENT

22. Improving Software
Development at Scale:
Promise and Pitfalls
Dr Andy Carmichael
Head of Agile Services, Clearvision-CM.com
@andycarmich - #LLKD14
http://xprocess.blogspot.co.uk/
http://www.slideshare.net/andycarmichaeluk/