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

Transcript

1. Decoding Paradoxes Why are many good ideas in Software Delivery counterintuitive? Hibri Marzook (he/him)
2. Hibri Marzook Likes to help software teams deliver fast and enjoy doing it @hibri www.hibri.net https://techhub.social/@hibri Principal Engineer
3. Software Delivery is complex
5. I just want to build cool stuff
6. ‘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)
7. 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
8. Software delivery is full of counterintuitive ideas if it hurts, do it often slack time improves flow releasing more often improves quality
9. 'The simplest thing you can do to improve quality is to deploy more frequently' Nicole Forsgren
10. But how does that work?
11. We need better models to understand and explain counterintuitive ideas
12. When I try to explain how to improve software delivery
13. Lets tell the story with causal loop diagrams
14. 'All models are wrong some models are useful' George Box
15. Why use causal loop diagrams? B + A + A influences/increases/affects B
16. size of a release
17. failed changes in a release size of a release +
19. change failure rate failed changes in a release size of a release + +
20. change failure rate failed changes in a release time to restore service size of a release + + +
21. 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 + ||
22. 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 + || +
24. Seeing the system
25. 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 + || +
26. Let's change things
27. 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 + || +
28. 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
29. 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
31. 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
32. 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
33. 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 + || +
34. Making lasting change
35. Seeing the iceberg
36. 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 + || +
37. 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 + || +
38. 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 + || +
39. + 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 + || + +
40. 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
41. Collaborative Modelling
42. 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
43. 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?
44. Non-​ linear strategy
45. 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
46. Listen to the wisdom of the system Donella Meadows
47. The system exists because it works
48. Understanding the dynamics of your system leads to a better strategy
49. Continuously improving our mental models, collaboratively of the system leads to a better strategy
50. '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
51. Dance with the system Donella Meadows
52. "Believe in the fundamental interconnectedness of all things" Dirk Gently Holistic Detective
53. Thank you
54. https://www.open.edu/openlearn/science-​ maths-​ technology/engineering-​ technology/systems-​ thinking-​ free-​ courses
55. Questions? @hibri www.hibri.net https://techhub.social/@hibri
56. 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 -