Anti Patterns of Software Delivery

Introduction

This short(?) text is an experiment. It’s an attempt to expose common issues in organisations engaged in software engineering projects in a way that is relatable and accessible so as to support change.

The obvious audience would be those directly involved in software delivery but if change is to be made, this needs to attract wider attention.

Equal Priorities

Also known as: Divided focus

Problem: A collection of items are all deemed to be essential leading to excessive WIP and poor results across the board.

Symptoms: Incidents, reduced ROI, bugs, delays

Solution:

1. Limit WIP

2. Apply cost of delay

Strict Priority

Problem: All work is classified against a hierarchy of importance leading to excessive effort in one area to the detriment of all others - security and production stability are often addressed this way. There’s always more that can be done but is it the most valuable?

Symptoms: Delays, reduced ROI

Solution:

See Equal Priorities

Learning Is On The Job

Problem: When all learning is done during the work, it leads to re-work as we realise the gaps in our thinking and the consequences.

Symptoms: Delays, incidents, inefficiency.

Solution:

1. Cultivate and maintain a curriculum

2. Ring-fence time consistently to allow study and practice

3. Encourage and support self-reflection

You’re Hired, You’re Ready

Problem: Engineers and their organisation assume they are already at adequate baseline and the focus is on moving up as opposed to gaining necessary breadth of skill. Similar applies in other disciplines.

Engineering Example: Expecting to be an architect when there are significant gaps in methods for quality, delivery economics, cost to run, operational adequacy (reliability, observability), security, performance and scale etc.

Symptoms: Delays, incidents, inefficiency

Solution:

See Learning Is On The Job

Engineers Are Fungible

Problem: Engineers can be rotated or replaced without consequence. This leads to over-estimation of capacity to produce outcomes.

Symptoms: Delays and inefficiency

Solution:

1. Reduce the variance (it’ll never be zero) as per Learning Is On The Job

2. Understand and socialise the loss - this can be estimated from variance in velocity or pairing behaviour (who’s leading?) and many others

Refactoring Is Tradable

Problem: Failing to apply the Boy Scout Rule

Symptoms: Bugs, incidents, delays and inefficiency

Solution:

1. Refactoring is done on the spot and treated as an inseparable part of engineering

Refactoring Is Rearchitecting

Problem: Architectural updates are conflated with basic code hygiene resulting in putting off necessary day-to-day maintenance and/or unexpected increases in workload

Symptoms: Delays, inefficiency, bugs, incidents

Solution:

1. See Refactoring Is Tradable

2. Follow an ADR Process

3. Run regular architecture reviews to address issues identified whilst re-factoring or otherwise

4. Prioritise changes in architecture via cost of delay

5. Track the amount of un-addressed change

Management By Objectives

Problem: Those furthest from the work define a set of goals absent of sufficient information to judge viability. As these objectives typically influence performance reviews and fiscal rewards, ineffective behaviours emerge.

Symptoms: Poor quality, blame shipping, resistance to change, reduced collaboration, incidents, bugs, missed milestones.

Solution:

1. OKRs and other incremental methods.

There’s Always A Way

Problem: An objective continues to be chased in spite of growing signals that it is not achievable leading to wasteful expenditure of effort that might be used to exploit more readily available and valuable opportunities.

Symptoms: Analysis paralysis, unresolvable trade-offs, delays and lost opportunity

Related: Management By Objectives

Solution:

1. Incremental methods

2. Riskiest assumption tests

We Should Be Improving

Problem: In spite of much effort, continuous improvement fails to emerge in an organisation.

Symptoms: Incidents, bugs, apparent inefficiency, reduced ROI

Solution:

1. Avoid 100% utilisation

2. Create forums for discussion of issues and the development of potential solutions

3. Prioritise improvements based on cost of delay

4. Recognise the power of compounding - as improvement is made, more space will be made for it and other things

Guerrilla Adoption Leads to Organisational Adoption

Problem: Teams or individuals apply better practices in isolation hoping that it will take across the organisation. Success is rare by virtue of wider organisational behaviours and/or expectations being in opposition thus limiting capacity for change.

Symptoms: Stalled improvement, attrition, reduced ROI.

Solution:

It’s an open problem - see the introduction ;)