what scrum masters and product owners should know about software quality and technical debt
TRANSCRIPT
What scrum masters and product owners
should know about software quality
and technical debt.
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)?
What is Technical Debt and where does
it come from?
planning
daily stand-ups
release to PROD
restart
feature freeze
regression tests
feature request
FEATURE REQUEST
quick & dirty solution
clean & smart solution
ILLUSION OF “everything is ok”
“we will refactor
it later”“there is no time
for testing”
SPRINT 12SPRINT 10 SPRINT 11
quick & dirty solution
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
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 quadranthttp://martinfowler.com/bliki/TechnicalDebtQuadrant.html
lekkomyślny brawurowy
rozważnyroztropny
nieumyślny
celowy
Classifying technical debt
Figure 1: Technical debt grid quadranthttp://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.
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
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.
SOFTWARE METRICS
CODECOVERAGE
NESTEDCODE
CODELEFTOVERS
CODECOMPLEXITY
CODEDUPLICATION
SOFTWARE METRICS
CODECOMPLEXITY
● 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 distributionin project.
SOFTWARE METRICS
NESTEDCODE
● 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.
SOFTWARE METRICS
CODELEFTOVERS
● 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.
How much technical debt is too much
technical debt?
Helicopter view
Hotspots view
Issues view
File detailed view
File detailed view with issue explanation
Quality gates
Monitoring & steering dashboard
Productivity view
Landscape overview
What are the most effective ways to manage technical debt in a software project
(agile approach)?
managing technical debt
DEBTbacklog
makeupstories (chores)
technicalretrospective
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
TECHNICAL DEBT COMES FROM
DECISIONSNOT CODE
TECHNICAL DEBT IS #1 IMPEDIMENT FOR TEAMS TO
BE AGILE