Improving Software Development at Scale: Promise and Pitfalls

Dr Andy Carmichael

Head of Agile Services, Clearvision-CM.com

@andycarmich - #LLKD14

Software development at scaleis 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 IMPROVEMENTmethod 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

WORK FLOWS

(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 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

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 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

Outline of this session…

Improving Software

Development at Scale:

Promise and Pitfalls

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 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 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/