Technical debt is a systemic problem - not a personal failing
•Download as PPTX, PDF•
10 likes•1,328 views
This is a presentation Chris Chapman I delivered at the Toronto Agile Conference 2017. We take a 'systems thinking' view of technical debt. The premise is that mounting technical debt is a not a problem ... it's a system problem. We depict system problems using causal loop diagrams and propose steps, via balancing loops, to shift the system to a healthier state. We use the term 'technical health' to describe this systems view of technical debt.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Technical debt is a systemic problem - not a personal failing
Similar to Technical debt is a systemic problem - not a personal failing (20)
More from Declan Whelan
More from Declan Whelan (17)
Recently uploaded
Recently uploaded (20)
Technical debt is a systemic problem - not a personal failing
- 1. Technical debt is a systemic problem … not a personal failing Declan Whelan - Leanintuit Chris Chapman - Derailleur Consulting
- 2. Introductions Declan Whelan Agile Coach / Consultant, Leanintuit Founder, Agile Coach Camp Canada, Agile/Lean Meetup (KW) @dwhelan declan@leanintuit.com Chris R. Chapman Owner / Agile Coach, Derailleur Consulting, Inc. Founder, #SystemsThinkingTO Meetup @DerailleurAgile chris.chapman@derailleurconsulting.com
- 3. Shape of the talk... ● What is technical debt? ● Systems thinking overview ● What is technical health? ● Systems views involving technical debt ● Systems thinking
- 4. Are you in favour of quality? Y:____ N:____ A product or service possesses quality if it helps somebody and enjoys a good and sustainable market. - W.E. Deming
- 5. Where our story begins... + +
- 6. What is Technical Debt? Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring … The danger occurs when the debt is not repaid. Every minute spent on unfactored code counts as interest on that debt. - Ward Cunningham Note: Wording slightly modified to use ‘refactoring’ and ‘unfactored’.
- 7. Technical Debt … for today’s talk Artifacts we build that impede delivery of future value. Big ball of mud: http://www.laputan.org/mud/
- 9. What is a SYSTEM? A system is a network of interdependent components that work together to try to accomplish the aim of the system. A system must have an aim. Without an aim, there is no system. - W.E. Deming, The New Economics
- 10. This is NOT a System:
- 11. Systems eat org charts for breakfast...
- 17. Causal loop diagram of childhood obesity https://www.researchgate.net/profile/Brynle_Owen/publication/279991790/figure/fig2/AS:284655178797063@1444878491561/Fig-3-Causal-loop-diagram-of-cause-of-childhood-obesity-in-community.png
- 18. What is Technical Health? The capacity of our system to deliver future value.
- 19. Craftsmanship
- 20. Moving the needle on craftsmanship ❏ Agile engineering training ❏ Technical coaching ❏ Pairing / mobbing ❏ Code reviews ❏ Coding katas ❏ Book clubs ❏ Lunch and learns ❏ Code retreats ❏ TD tools (i.e. linters, code analysis)
- 21. Defects & Errors
- 22. Moving to zero defects ❏ “Quality first” from CEO down ❏ Measure and track ‘failure demand’ ❏ Measure error impact ❏ Classify errors by impact/risk ❏ Prioritize fixes ❏ Automated tests ❏ Exploratory testing ❏ Static code analysis ❏ Continuous integration / delivery ❏ Feature switches ❏ Instrument code (e.g. NewRelic)
- 23. Psychology
- 24. Psychology ❏ Isolate code ‘oases’ to improve ❏ Measure technical debt reduction ❏ Call out code improvements ❏ Make it safe to do the right thing ❏ Automated tests ❏ No blaming on defects ❏ Code reviews ❏ Collective code ownership ❏ Pairing / mobbing ❏ Make everyone awesome!
- 26. Moving to an effective organization ❏ Dedicated team members ❏ Co-located teams ❏ Respect Conway’s law ❏ Feature teams ❏ Don’t outsource core IP ❏ Team hiring ❏ Respect “mythical man-month”
- 27. Reduce!
- 28. START HERE:
- 29. Let’s GO LIVE! A Model of System Quality...
- 31. Wrapping up... ● Technical debt is a symptom … not the core problem. ● Technical debt growth is a symptom of an unhealthy system. ● Try using the term ‘technical health’ and see if changes things. ● Craftsmanship is necessary but insufficient. ● Active support from leaders is necessary. ● Build causal loop diagrams with teams & leaders. ● Grow technical health via multiple points in your system. ● Technical debt is not a personal failing … it’s a system thing!
Editor's Notes
- Open - Chris 15m up to TH 25m diagrams - 5m per 5m on ST 5m to close
- Q&A throughout
- Nearly everyone will agree. The differences lie in how we expect to achieve it. Engage audience to tell us some things they think improve quality in the products they are making... Expectation: Focus on METHODS, PEOPLE, MACHINES, TECHNOLOGY, TAMPERING ALL WRONG - none of them focus on the SYSTEM This talk is a distillation of Declan’s thinking and observations over some time…
- Ask attendees the question. Likely (but wrong) response is “ALL OF US”. Right response is on next slide.
- Quality is the outcome of many decisions throughout an organization. Teams can only achieve the extent of quality that the system will allow. It is the SYSTEM OWNERS’ RESPONSIBILITY to take whatever steps required to IMPROVE THE SYSTEM so that the people doing the work can achieve higher and higher standards of QUALITY.
- This is a story about a common problem in organizations that develop software. It begins with code that started off with the best of intentions to do good, but became beset by problems The seeds of the problem were sown when the development team began to roughly translate user stories into code, but due to outside influences, had to abandon in an unfinished state As problems arose, the team struggled to put out the fires, but were distracted by the same influences to do a less-than-adequate job to repair the overall structure of the code And more fires arose. And more. Sound familiar?
- Use your own metaphor - the fire analogy could be appropriate. Also used ‘risk’ when working with an insurance company.
- As first observed by W.E. Deming, later his contemporaries like Peter Scholtes, Russell Ackoff, and others. This ISN’T to beat up on management for no good reason. It’s to call attention to THE SYSTEM as the source of variation in our ability to achieve quality.
- IMPORTANT IMPLICATION: Systems cannot manage themselves A view from the outside is required Manage interactions vs. actions So how do we explore systems? We’re going to share with you a core competency you can use to explore and understand complex systems and why they behave the way they do Causal Loop Diagrams
- This is causal loop diagram from the NIH describing childhood obesity.
- Should be here by 1:30 Explain the causal loop. And _ Colours
- Craftsmanship takes time - so start now! May need training to ensure practices are understood Will need continuous learning pairing/mobbing Coaching Intentional learning Pressure to deliver must be diminished to allow craftsmanship to flourish
- XP is the physics behind craftsmanship Need intentional practice Can see immediate results This is not a one-and-done => never ends
- 80% Capacity of a customer dealing with errors
- These methods alone will not allow a team to achieve zero defects;
- Need leadership to support quality and dial down pressure to deliver
- Need leadership to support team structure, responsibility & accountability. Avoid splitting dev & QA for example.
- Need leadership to support quality and dial down pressure to deliver
- So, let’s bring this back to the system level. Technical Debt is effectively reversing the Deming Quality Chain Reaction. Moving in reverse, when we neglect our designs we: Diminish Quality (ignore problems, keep increasing usable incompleteness, etc) Increase Costs (more re-work, more unanticipated mistakes, waste) Decrease Productivity (because we’re working more to stabilize and put out fires than innovate) Reduce our Market Share (because we’re not meeting customers’ expectations) Look to get out of business (because we’re not caring about customers) Reduce headcount to keep the lights on
- Significant implications for how we manage organizations. The dominant model is to locally sub-optimize at the team layer and hope improvement spreads to the rest of the organization. This is the original Fool’s Errand. At best, you’re signing up for a lifetime of putting out fires and mediocre results.