Decoding Paradoxes: Why are many good ideas in Software Delivery counter-intuitive

Slide 1

Slide 1 text

Decoding Paradoxes Why are many good ideas in Software Delivery counterintuitive? Hibri Marzook (he/him)

Slide 2

Slide 2 text

Hibri Marzook Likes to help software teams deliver fast and enjoy doing it @hibri www.hibri.net https://techhub.social/@hibri Principal Engineer

Slide 3

Slide 3 text

Software Delivery is complex

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

I just want to build cool stuff

Slide 6

Slide 6 text

‘ill- defined, ambitious and associated with strong moral, political and professional issues. Since they are strongly stakeholder dependent, there is often little consensus about what the problem is, let alone how to resolve it. Furthermore, wicked problems won’t keep still: they are sets of complex, interacting issues evolving in a dynamic social context. Often, new forms of wicked problems emerge as a result of trying to understand and solve one of them.’ Is it a Wicked Problem? ‘Dilemmas in a General Theory of Planning’ (Rittel and Webber, 1973)

Slide 7

Slide 7 text

Involves changing people's behaviour Involves changing the relationships between individuals and teams Involves seeing other perspectives Involves changing the nature of relationships between individuals and teams Involves seeing the whole

Slide 8

Slide 8 text

Software delivery is full of counterintuitive ideas if it hurts, do it often slack time improves flow releasing more often improves quality

Slide 9

Slide 9 text

'The simplest thing you can do to improve quality is to deploy more frequently' Nicole Forsgren

Slide 10

Slide 10 text

But how does that work?

Slide 11

Slide 11 text

We need better models to understand and explain counterintuitive ideas

Slide 12

Slide 12 text

When I try to explain how to improve software delivery

Slide 13

Slide 13 text

Lets tell the story with causal loop diagrams

Slide 14

Slide 14 text

'All models are wrong some models are useful' George Box

Slide 15

Slide 15 text

Why use causal loop diagrams? B + A + A influences/increases/affects B

Slide 16

Slide 16 text

size of a release

Slide 17

Slide 17 text

failed changes in a release size of a release +

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

change failure rate failed changes in a release size of a release + +

Slide 20

Slide 20 text

change failure rate failed changes in a release time to restore service size of a release + + +

Slide 21

Slide 21 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + number of new changes + ||

Slide 22

Slide 22 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ number of new changes + || +

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

Seeing the system

Slide 25

Slide 25 text

The system engine change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 number of new changes + || +

Slide 26

Slide 26 text

Let's change things

Slide 27

Slide 27 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 number of new changes + || +

Slide 28

Slide 28 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + || + \\ R1 time to test a release - manual regression tests + number of new changes + More time to test

Slide 29

Slide 29 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + manual regression tests + number of new changes + || + More time to test

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual regression tests + number of new changes + || + Impact of a release freeze

Slide 32

Slide 32 text

Slide 33

Slide 33 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - number of new changes + || +

Slide 34

Slide 34 text

Making lasting change

Slide 35

Slide 35 text

Seeing the iceberg

Slide 36

Slide 36 text

Events change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - number of new changes + || +

Slide 37

Slide 37 text

Patterns of behaviour time failed changes in a release change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - number of new changes + || +

Slide 38

Slide 38 text

Systems Structure change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - number of new changes + || +

Slide 39

Slide 39 text

+ Mental Models change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment manual regression tests + deployment frequency - - automated deployment + number of new changes + || + +

Slide 40

Slide 40 text

Ask questions change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - automated deployment + number of new changes + || + is there enough time to learn? wip limit - are devs incentivised to focus on their sprints? what inhibits learning? do we have the right tools? start finishing stop starting

Slide 41

Slide 41 text

Collaborative Modelling

Slide 42

Slide 42 text

if it hurts, do it often slack time improves flow releasing more often improves quality stop starting, start finishing Counterintuitive ideas shape our mental models

Slide 43

Slide 43 text

hero culture devs need to be busy all the time releasing once a month keeps us safe devs and testers in different teams What mental models shape our current system?

Slide 44

Slide 44 text

Non- linear strategy

Slide 45

Slide 45 text

Expand boundaries change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - automated deployment + number of new changes + || + learning diversity and culture learning software delivery attitudes to collaboration

Slide 46

Slide 46 text

Listen to the wisdom of the system Donella Meadows

Slide 47

Slide 47 text

The system exists because it works

Slide 48

Slide 48 text

Understanding the dynamics of your system leads to a better strategy

Slide 49

Slide 49 text

Continuously improving our mental models, collaboratively of the system leads to a better strategy

Slide 50

Slide 50 text

'Models are conversations. There is no right way to converse. Modelling is framing questions and exploring answers. Establishing a vibrant, healthy and impactful modelling process is far more important than which tools you use' Diana Montalion

Slide 51

Slide 51 text

Dance with the system Donella Meadows

Slide 52

Slide 52 text

"Believe in the fundamental interconnectedness of all things" Dirk Gently Holistic Detective

Slide 53

Slide 53 text

Thank you

Slide 54

Slide 54 text

https://www.open.edu/openlearn/science- maths- technology/engineering- technology/systems- thinking- free- courses

Slide 55

Slide 55 text

Questions? @hibri www.hibri.net https://techhub.social/@hibri

Slide 56

Slide 56 text

change failure rate failed changes in a release time to restore service delay to the next release size of a release + + + + size of a future release + \\ R1 time to test a release - + duration of a release freeze + manual deployment + manual regression tests + deployment frequency - - automated deployment + number of new changes + || + wip limit -