4. }!before we start…!
How
is
your
boss
here?
what
the
hell
is
happening
with
this
project?!?
5.
6. Technical Debt!
Why should you care?!
Paulo
Roberto
Camara
Tech
Manager
at
Ci&T
proberto@ciandt.com
@proberto98
www.ciandt.com!
{!
7. which
opCon
would
you
go
for?
• the
easy
and
quick
way,
but
the
code
doesn’t
look
very
nice…
Future
will
be
dark…
• a
cleaner
and
more
sophisCcated
design,
but
it
will
take
longer
to
put
in
place.
No
clouds
ahead!
12. “Technical
debt
is
everything
that
makes
your
code
harder
to
change.”
(Tom
Poppendiek)
13. such
as….
• no
design
• poor
design
• duplicated
code
• deprecated
code
• un-‐tested
code
• complex
code
• any
kind
of
“workaround”…
14. the
metaphor…
• every
Cme
you
choose
the
first
opCon
(the
quick
and
dirt
way)
you
create
debt
(like
a
financial
debt)
– if
it
is
a
debt,
it
incurs
interest
• you
may
pay
only
the
interest
• or
you
may
pay
down
the
principal,
reducing
the
interest
in
the
future
15. interest?!?
• bugs
• extra
effort
• slower
development
• delays
17. “Every
minute
spent
on
not-‐quite-‐right
code
counts
as
interest
on
that
debt.
EnCre
engineering
organizaCons
can
be
brought
to
a
stand-‐sCll
under
the
debt
load
of
an
unconsolidated
implementaCon…”
(Ward
Cunningham,
1992)
20. interest?!?
• bugs
• extra
effort
• slower
development
• delays
21.
22.
23.
24. a
liTle
context
(before
I
show
you
what
I
am
really
talking
about)
25. }!Ci&T at a glance!
Founded in 1995!
HQ in Brazil w/ offices in the US, Japan, Europe & China!
Argentina and China !
Global Delivery Centers in Brazil,
Staff: 1,300+!
Annual growth: 40%!
Provide high performance teams to our clients!
2010
www.ciandt.com / @ciandt!
27. }!What we do!
Service Offerings!
Application Development & Management!
Mobile Solutions!
Cloud Computing!
Product Engineering!
SAP!
Business Intelligence!
!
www.ciandt.com / @ciandt!
28. }
How
we
do
it
Ci&T runs 100% !
Agile projects!!
www.ciandt.com / @ciandt!
30. }!do you remember this chart?!
what
the
hell
is
happening
with
this
project?!?
31. it
is
a
true
project…
L
• criCcal
Cme
to
market
milestone
• prudent
technical
debt
(“let’s
fix
it
later!”)
• yes!
We
met
the
milestone!
J
• but….
a
new
“criCcal”
milestone
was
set…
• more
reckless
technical
debt
(“refactoring
is
for
losers!”)
• things
got
more
difficult
(extra
effort,
extra
bugs,
frustrated
team,
unhappy
customer…)
• we
didn’t
meet
the
second
milestone…
L
• two
sprints
spent
on
refactoring,
almost
no
new
funcConality
delivered…
• a
long
Cme
to
recover
credibility.
33. let’s
look
another
example…
almost
40%
of
the
total
sprint
capacity
and
quality
has
became
an
issue…
what
a
hell
is
happening
with
this
project?!?
34. lack
of
automated
tests,
coCnuos
integraCon!
• complex
billing
system
for
an
Insurance
company
• lots
of
integraCons
with
legacy
systems
• automated
tests
were
not
easy
to
be
created
(and
kept
working
later!)
• and
the
Product
Owner
didn’t
accept
to
spend
sprint
capacity
with
“no
useful
code”
• aber
a
lot
of
conversaCon
–
and
problems
–
team
was
able
to
create
a
minimal
test
suite
(one
enCre
sprint
spent
on
that!)
• keep
this
tesCng
code
up
and
running
had
become
part
of
the
definiCon
of
done
• in
the
following
sprint,
regression
tests
effort
dropped
half
as
well
as
the
bugs
found
by
the
PO!
J
35. a
good
reference
now!
• a
large
building
company
• an
18
months
project
• high
technical
and
business
complexity
• company
board
as
the
main
stakeholders
• Ci&T’s
team:
12
people
• monthly
deliveries
• currently
at
sprint
12
36. technical
debt
under
control!
• code
standards
/
design
/
code
reviews
/
frequent
refactoring
– cost
to
add
new
features
is
almost
the
same
since
sprint
3
• conCnuous
integraCon
/
automated
tests
– daily
builds
deployed
on
customer
environment
– completely
automated
deploy
process
– merge
Cme
reduced
to
zero
• quality
– from
0,1
bugs
/
KLOC
to
0,06
bugs
/
KLOC
on
producCon
but
how?!?
42. and
how
about
the
product
owner?
(because
it
seems
he
is
somehow
important,
doesn’t
it?
J
)
43. you
may
see
him
as
the
bad
guy…
Ø pushing
the
team
very
hard
Ø adding
unnecessary
complexity
Ø not
opened
to
technical
arguments
44. but
he
is
the
one
who
will
have
to
pay
for
the
debt
eventually!
45. it
is
all
about
communicaCon
• The
product
owner
–
usually
-‐
does
not
know
what
is
refactoring,
code
review,
TDD,
etc
– And
he
does
not
need
to
know!
• But
he
needs
to
know
what
is
the
size
of
the
debt
and
make
conscious
decisions
about
when
and
how
to
pay
it
– Keeping
him
in
the
loop
is
a
team
responsibility!
49. good
references
Sites
ArCcles
• Being
Agile
–
blog
interno
da
Ci&T
• CMMI®
or
Agile:
Why
Not
Embrace
Both!
–
by
Hillel
• hTp://www.controlchaos.com/
Glazer,
Jeff
Dalton,
David
Anderson,
Mike
Konrad
and
Sandy
Shrum
• hTp://www.mountaingoatsobware.com/scrum
• PracCcal
Roadmap
To
Great
Scrum
-‐
Jeff
• hTp://jeffsutherland.com/scrum/
Sutherland,
Ph.D.,
October
20,
2009
• hTp://www.scrumalliance.org/arCcles
• Scrum
and
CMMI
-‐
Going
from
Good
to
Great,
• hTp://www.agilechronicles.com/
Carsten
Ruseng
Jakobsen,
Jeff
Sutherland,
Ph.D.
Books
• Agile
Project
Management
with
Scrum
-‐
by
Ken
Schwaber
• Lean
Sobware
Development:
An
Agile
Toolkit
-‐
By
Mary
Poppendieck,
Tom
Poppendieck
• Agile
and
IteraCve
Development:
A
Manager's
Guide
-‐
By
Craig
Larman
• Agile
Sobware
Development
-‐
by
Alistair
Cockburn
