The document discusses technical debt in software projects. It defines technical debt as compromises in quality or maintainability that accumulate when developers take shortcuts or make quick fixes rather than implementing clean code. Technical debt comes from decisions to cut corners, such as not refactoring code or thoroughly testing features. Over time, technical debt can lead to slower development, more bugs, and heavier testing needs. The document recommends calculating technical debt through software metrics like code complexity, duplication, and test coverage. It also suggests effective ways to manage technical debt in agile projects, such as creating a technical debt backlog, educating stakeholders, automating tests, and conducting retrospectives to improve practices and prevent accumulating further debt. Regularly paying down

1. What
scrum masters and product owners
should know about
software quality
and
technical debt.
lukasz.koczwara@stxnext.pl

2. AGENDA
45 MINUTES ABOUT
1. What is Technical Debt and where does it come from?
2. What would I need to do in order to calculate technical debt
for a software project?
3. How much technical debt is too much technical debt?
4. What are the most effective ways to manage technical debt
in a software project (agile approach)?

3. What is Technical
Debt and where does
it come from?

4. planning
daily stand-ups
releasetoPROD
restart
featurefreeze
regression tests
feature
request
FEATURE REQUEST
quick & dirty
solution
clean & smart
solution

5. ILLUSION OF “everything is ok”
“we will refactor
it later”
“there is no time
for testing”
SPRINT 12SPRINT 10 SPRINT 11
quick & dirty
solution

6. CARRYING OVER TECH. DEBT
quick & dirty
solution
“we will refactor
it later”
quick & dirty
solution
“we will refactor
it later”
“there is no time
for testing”
SPRINT 12SPRINT 10 SPRINT 11
quick & dirty
solution

7. What is TECHNICAL DEBT?
Technical debt is the difference between
what was promised and what was actually
delivered.
Tom Poppendieck defines technical debt as
everything that makes your code harder to
change.
Consequence of cutting corners throughout
software development. Technical Debt are all of
those things you choose not to do now and after
some time you still leave them undone.
Figure 1: Technical debt grid quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
lekkomyślny
brawurowy
rozważny
roztropny
nieumyślny
celowy

8. Classifying technical debt
Figure 1: Technical debt grid quadrant
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
Entry into a new market – first to
market may mean that lower quality or
features with more workarounds
might be acceptable.
This is a natural occurrence. Teams
would like to improve upon whatever
has been done after gaining experience
and relevant knowledge.
This happens typically to
programmers who are incompetent
and unaware of the implications of
adding/removing a piece of code,
thus incurring a huge technical
debt.
Pushing the project through because
the client wants it on a set date, and
no one has built a relationship with
the client to discuss the details, nor
has the client been informed of the
effect on quality if the delivery is
rushed.

9. TIME REVEALS THE TRUTH
“we will refactor
it later”
quick & dirty
solution
“there is no time
for testing”
SPRINT 12SPRINT 10 SPRINT 11
quick & dirty
solution
“we will refactor
it later”
few months
quick & dirty
solution
SPRINT 31
more bugs
unreadable code
code duplication
slower development
postponed releases
heavy manual testing

10. What would I need to do
in order to calculate
technical debt for a
software project?
You cannot improve what you don’t measure.
What you don’t measure, you cannot prove.

11. SOFTWARE METRICS
CODE
COVERAGE
NESTED
CODE
CODE
LEFTOVERS
CODE
COMPLEXITY
CODE
DUPLICATION

12. SOFTWARE METRICS
CODE
COMPLEXITY
● Indicator of where the logic is stored
and how the logic is distributed.
● Files with high value of Mcc most of
the time are responsible for too many
things at the same time.
Refactoring of such files can be reflected
in more granular logic distribution
in project.

13. SOFTWARE METRICS
NESTED
CODE
● Code in deep nesting levels is very
difficult to understand.
● Developers spend overly much
time “thinking and searching”
before they modify it.
● Higher risk of introducing changes.
● Nearly impossible to be tested
completely.

14. SOFTWARE METRICS
CODE
LEFTOVERS
● Code is only commented not deleted.
● An indicator that developers are unsure
about their code changes.
● Understanding mixed real-and-commented
code is slow, because the commented code
is probably relevant and also needs to be
understood.

15. How much technical
debt is too much
technical debt?

18. Helicopter view

19. Hotspots view

20. Issues view

21. File detailed view

22. File detailed view with issue explanation

23. Quality gates

25. Monitoring & steering dashboard

26. Productivity view

27. Landscape overview

28. What are the most effective
ways to manage technical
debt in a software project
(agile approach)?

29. managing technical debt
DEBT
backlog
makeup
stories (chores)
technical
retrospective
build relationship
on transparency
make risk
prominent, use
numbers
educate on true
cost of technical
debt
test often
automate tests
invest in CI strong DOD
build awareness at the
management level of the
hidden cost behind the quality
cleanup releases
/ warranty phase
inspect & adapt software
development cycle
agile >> scrum
just make it work for you
inject best
practices
build quality culture
encourage
knowledge
sharing

30. TECHNICAL DEBT
COMES FROM
DECISIONS
NOT CODE

31. TECHNICAL DEBT IS
#1 IMPEDIMENT
FOR TEAMS TO
BE AGILE