improving software development at scale - promise and pitfalls #llkd14
Post on 08-May-2015
978 Views
Preview:
DESCRIPTION
TRANSCRIPT
Improving Software Development at Scale: Promise and Pitfalls
Dr Andy CarmichaelHead of Agile Services, Clearvision-CM.com
@andycarmich - #LLKD14
Software development at scale is particularly hard
Scale changes the problem
Software is hard
Outline of this session…
Improving Software Development at Scale: Promise and Pitfalls
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
Improving Software Development at Scale: Promise and Pitfalls
What is Kanban?
An approach for managing and improving the
flow of value from knowledge work?
Process
WORKFLOWS(not all work does flow – but concentrate on the “work that flows”)
A short definition of Kanban needed in order to be scale-free
1. See work as flow2. Start from here and evolve3. 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
The Twitter Version
Essence of Kanban
see flow start here with visible work & policies validate improvements
Also see: "How to Adopt Kanban" @andycarmich
Improving Software Development at Scale: Promise and Pitfalls
2 scaling mechanisms
• Scaling by “not scaling”o use service-orientation concept to build a network of
independently operating but interdependent serviceso balance work flowing between different kanban systems
• Scale through “scale-free” understandingo same approach applied to different units of flow at
different time scales
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)
Decisio
n m
akin
g a
t diff
ere
nt le
vels h
ave
diff
erin
g sco
pe a
nd
purp
ose
Decision Flows between Scales
• Personal / small team
• Service delivery / workflow
• Product
• Portfolio
Decisio
n m
akin
g a
t diff
ere
nt le
vels h
ave
diff
erin
g sco
pe a
nd
purp
ose
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
Outline of this session…
Improving Software Development at Scale: Promise and Pitfalls
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
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
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
@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
Pitfall 4: Thinking dependencies in plans are
there to be managed
Most must be eliminated!
Pitfall 5: Thinking agility is a quality without a cost
Is it valued by the organisation?Is predictability valued more?
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)
RESPECTCONTINUOUS
IMPROVEMENT
Improving Software Development at Scale: Promise and Pitfalls
Dr Andy CarmichaelHead of Agile Services, Clearvision-CM.com
@andycarmich - #LLKD14http://xprocess.blogspot.co.uk/
http://www.slideshare.net/andycarmichaeluk/
top related