Technical Dept
Chapter 8 / Essential Scrum Practical Guide
Haeseung Lee @ Product Management
Defining
Technical Debt by
- naive dept
- unavoidable debt
- deliverate debt
Then, how to
- managing the accrual of technical debt
- making technical debt visible
- servicing technical debt
"Technical Debt?"
Shipping first time code is like going into debt. A little debt speeds development so long as it is pad back promptly with a rewrites...The danger occurs when the debt is not repaid. Every minute spend on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.
Cunningham 1992
"Reckless Debt?"
You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - your are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
Fowler 2009
"Mess isn't technical debt"
A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying off in the future. A mess is always a loss.
Nowadays...
Technical Debt refers both to the shortcut we purposely take and also to the many bad things that plague software systems. These includes
- Unfit(bad) design
- Defects
- Insufficient test coverage
- Excessive manual testing
- poor integration and release management
- Lack of platform expertise
- and many more...
Technical Debt, in this book
- Naive Technical Debt
- Unavoidable Technical Debt
- Strategic Technical Debt
Typical Example
- typical example for incurring technical debt in code is that huge source file every developer fears to touch.
- typical example for technical debt from the operations side of things is deploying your application in only one availability zone in your datacenter even through you have demanding uptime requirements.
Technical Debt, isn't it?
unnecessary complexity, dirty hacks, and unreadable code are not technical debt. There is no good reason for introducing such a mess in the first place. If developers feel that they don't have the time to write simple, maintainable code there clearly lacking experience and professionalism.
"Single brain know-how" is another phenomenon often described as technical debt. But being dependent on a single person to maintain or run a critical part of your application isn't technical debt - it's a lethal threat to your business.
Consequences of Technical Debt
Text
Causes of Technical Debt
Pressure to Meet a Deadline
Attempt to Falsely Accelerate Velocity
Myth: Less Testing can Accelerate Velocity
Debt builds on Debt
Technical Debt must be Managed
Managing the Accrual of Technical Debt
- use good technical Practices
- use a Strong Definition of Done
- properly understand Technical Debt Economics
Making Technical Debt visible
- Make Technical Debt Visible at Biz Level
- Make Technical Debt Visible at Tech Level
Servicing(or repaying)
Technical Debt
Closing
Agile method
is subset of change Management.
Not only "Speedy", But also "Cultural"
Why agile fails
- Agile is Brutal
- Agile creates Transparency
- Agile demands Fixing Root Causes
Scrum vs. Kansan
| SCRUM | KANBAN | |
|---|---|---|
| Cadence | Regular fixed length sprints(ie. 2 weeks) | Continuous flow |
| Release Methodology | At the end of each sprint if approved by the product owner | Continuous delivery to at the team's discretion |
| Roles | Product Owner, Scrum Master, Development Team | No existing roles. Some teams enlist the help of an agile coach |
| Key Metrics | Velocity | Cycle time |
| Change Philosophy | Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation | Change can happen at any time |
Technical Dept
By Lee, Haeseung
Technical Dept
Study of Agile>Scrum
