improving software development at scale - promise and pitfalls #llkd14
DESCRIPTION
Software (as frequently observed) is hard. And software development at scale is particularly hard. Evidence suggests a strong inverse relationship between the likelihood of a software project delivering its planned benefits (within budgeted costs) and the project's size. While this is nothing new, we should ask why has there been so little improvement over the years. Agile methods undoubtedly contributed much over their first two decades to the effectiveness of software teams - particularly "coffee-pot-sized" teams developing new products. Agile methods were primarily designed with this sized team in mind, and agile process frameworks are still defined almost entirely with reference to this scale. In their third decade however, the question of how these methods scale can no longer be avoided. This presentation, rather than focusing on the new frameworks that are now emerging, reviews anecdotal evidence as well as theoretical ideas on what improves (or degrades) performance of large initiatives… in particular the management behaviours that have proved helpful or counter-productive in real projects. Large scale does not invalidate strategies that work at small scale, however it does introduce management problems that are new - problems that are not overcome by simply "keeping the geeks away from the suits" (or keeping the "chickens" silent while the "pigs" speak)!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/