What scrum masters and product owners should know about software quality and technical debt

What scrum masters and product owners

should know about software quality

and technical debt.

lukasz.koczwara@stxnext.pl

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