improving software development at scale llkd14
Post on 13-Jul-2015
325 Views
Preview:
TRANSCRIPT
Improving Software Development at Scale: Promise and Pitfalls
Dr Andy Carmichael
Head of Agile Services, Clearvision-CM.com
@andycarmich - #LLKD14
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 IMPROVEMENTmethod based on the Lean flow paradigm
What is Kanban?
An approach for managing and improving the
flow of value from knowledge work?
Process
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
The Twitter Version
Essence of Kanban
see flow
start here
with visible work & policies
validate improvements
Also see: "How to Adopt Kanban" @andycarmich
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
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)
Decis
ion m
akin
g a
t
diffe
rent le
vels
have
diffe
ring s
cope a
nd
purp
ose
Decision Flows between Scales
• Personal / small team
• Service delivery / workflow
• Product
• Portfolio
Decis
ion m
akin
g a
t
diffe
rent le
vels
have
diffe
ring s
cope 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
Pitfalls: Mild insults & non-
communication
• keep the „chickens‟ silent while the „pigs‟ speakSubtext: 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 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 notto have done (Instruction Giving)
• We have left undone those interventions weought to have done (System Thinking)
RESPECTCONTINUOUS
IMPROVEMENT
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/
top related