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!
such as…. • no design
• poor design • duplicated code • deprecated code • un-‐tested code • complex code • any kind of “workaround”…
the metaphor… • every Cme
you choose the ﬁrst opCon (the quick and dirt way) you create debt (like a ﬁnancial 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
“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)
}!Ci&T at a glance! Founded
in 1995! HQ in Brazil w/ ofﬁces 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! 2010www.ciandt.com / @ciandt!
it is a true project…
L • criCcal Cme to market milestone • prudent technical debt (“let’s ﬁx 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 diﬃcult (extra eﬀort, 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.
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?!?
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 deﬁniCon of done • in the following sprint, regression tests eﬀort dropped half as well as the bugs found by the PO! J
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
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?!?
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!
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, Jeﬀ Dalton, David Anderson, Mike Konrad and Sandy Shrum • hTp://www.mountaingoatsobware.com/scrum • PracCcal Roadmap To Great Scrum -‐ Jeﬀ • hTp://jeﬀsutherland.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, Jeﬀ 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 Managers Guide -‐ By Craig Larman • Agile Sobware Development -‐ by Alistair Cockburn