The document discusses the concept of technical debt in software development. It provides examples of projects that accumulated large amounts of technical debt by taking shortcuts and ignoring code quality, which led to increased bugs, delays in meeting deadlines, and loss of credibility. It also presents examples of projects that controlled technical debt through practices like design standards, code reviews, automated testing, and regular refactoring. This allowed them to develop new features efficiently and maintain high code quality over time. The key messages are that technical debt should be avoided by focusing on quality, and if debt occurs, it needs to be promptly addressed to avoid large interest payments down the road.
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
The technical debt metaphor is useful in capturing the long-term impacts of
tradeoffs taken during software maintenance between productivity (getting
something done sooner) and maintainability (degradation of the code's
quality over time). This webinar on Technical Debt will present
techniques and insights that help software engineers to identify and track
technical debt in their projects. We will outline how business and product
quality goals should affect the choice of approaches (and combinations of
approaches) for managing technical debt. More specifically, we will discuss
a set of automated approaches based on static code analysis that are likely
to spot problems in source code that have real impact on productivity and
defect proneness. Based on previous empirical studies, we will give further
advice on which types of debt can be found by these tools, and which types
are not yet detectable.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
The SQALE method: Meaningful insights into your Technical DebtJean-Louis LETOUZEY
This is the presentation I made at the Agile 2012 conference (August in Dallas). It explains:
- Why Technical Debt is a powerful new paradigm
- What Managing Technical Debt means
- How SQALE helps to manage your Technical Debt
- The 3 remediation strategies supported by SQALE
“Grey is the new black.”
This mid80’s declaration from the fashion industry has become synonymous with radical shifts in the norm of any field. Agile provided such a radical shift for traditional waterfall processes. Yet as Agile has matured, it is redefining itself at a pace that rivals the whims of the fashion industry.
This presentation presents not only the (somewhat obvious) shifts from waterfall to Agile, but the second and third generation of shifts within the Agile community itself. Basics such as automated unit tests are falling away (“Deployment is the new unit test”).
The overall message is to continue to question practices, and strive to understand the reasons behind a practice so that you know when it is safe to discard.
(Presented at Agile India 2013)
Monolith to serverless service based architectures in the enterpriseSameh Deabes
Brief introductions about the following topics and how they relate to each other: SOA, ESB, Cloud, Cloud Native Architecture, Microservices, Multigrained Services, NoESB, API-First, Full Lifecycle API Management, etc.
The session will focus mainly on microservices pitfalls and what to do about it.
Masters of Process Episode 1: On Deck with Michael Gill and Curtis CummingsLizzyManz
Masters of Process brings you the no-code revolution in full. Join us as we meet with top innovators in the space and explore how they are reinventing the way a modern business operates. Brought to you by industry insiders from No Code Ops and Process Street, each half hour episode is a goldmine of productivity, products, and scaling.
I had a great opportunity to design questions for this year's Agile Olympiad organized by UNICOM Learning as part of India Agile Week 2014. This is the deck for finals rounds. Not only did I have fun throughout the Olympiad, it was also a great learning opportunity. Here are the questions - sorry, won't be sharing the answers, but I am sure you will have a great learning time finding those answers...
Developing a software project is definitely not like building a house. If you focus on the learning aspects instead of the simple building you'll probably discover something interesting and unexpected.
How to justify technical debt mitigations in Software EngineeringAndré Agostinho
In this presentation André Agostinho e Cassio Silva covers the importance in dealing with technical debt in software engineering showing the real impacts, daily approaches and best practices for mitigations
The technical debt metaphor is useful in capturing the long-term impacts of
tradeoffs taken during software maintenance between productivity (getting
something done sooner) and maintainability (degradation of the code's
quality over time). This webinar on Technical Debt will present
techniques and insights that help software engineers to identify and track
technical debt in their projects. We will outline how business and product
quality goals should affect the choice of approaches (and combinations of
approaches) for managing technical debt. More specifically, we will discuss
a set of automated approaches based on static code analysis that are likely
to spot problems in source code that have real impact on productivity and
defect proneness. Based on previous empirical studies, we will give further
advice on which types of debt can be found by these tools, and which types
are not yet detectable.
What is Technical Debt? It doesn't have to be negative, but it does have to be carefully managed. Here is a quick run-down of best practice to approaching Technical Debt management.
Technical debt is often characterized as design or code tradeoffs. In this talk I discuss how shortcuts in requirements analysis might lead to technical debt as well.
Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.
Presentation given by Fadi Stephan from Kaizenko at AgileDC2018 on 10/15/2018 in Washington DC. Also see blog series on Managing Technical Debt at https://www.kaizenko.com/managing-technical-debt/
Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.
The SQALE method: Meaningful insights into your Technical DebtJean-Louis LETOUZEY
This is the presentation I made at the Agile 2012 conference (August in Dallas). It explains:
- Why Technical Debt is a powerful new paradigm
- What Managing Technical Debt means
- How SQALE helps to manage your Technical Debt
- The 3 remediation strategies supported by SQALE
“Grey is the new black.”
This mid80’s declaration from the fashion industry has become synonymous with radical shifts in the norm of any field. Agile provided such a radical shift for traditional waterfall processes. Yet as Agile has matured, it is redefining itself at a pace that rivals the whims of the fashion industry.
This presentation presents not only the (somewhat obvious) shifts from waterfall to Agile, but the second and third generation of shifts within the Agile community itself. Basics such as automated unit tests are falling away (“Deployment is the new unit test”).
The overall message is to continue to question practices, and strive to understand the reasons behind a practice so that you know when it is safe to discard.
(Presented at Agile India 2013)
Monolith to serverless service based architectures in the enterpriseSameh Deabes
Brief introductions about the following topics and how they relate to each other: SOA, ESB, Cloud, Cloud Native Architecture, Microservices, Multigrained Services, NoESB, API-First, Full Lifecycle API Management, etc.
The session will focus mainly on microservices pitfalls and what to do about it.
Masters of Process Episode 1: On Deck with Michael Gill and Curtis CummingsLizzyManz
Masters of Process brings you the no-code revolution in full. Join us as we meet with top innovators in the space and explore how they are reinventing the way a modern business operates. Brought to you by industry insiders from No Code Ops and Process Street, each half hour episode is a goldmine of productivity, products, and scaling.
I had a great opportunity to design questions for this year's Agile Olympiad organized by UNICOM Learning as part of India Agile Week 2014. This is the deck for finals rounds. Not only did I have fun throughout the Olympiad, it was also a great learning opportunity. Here are the questions - sorry, won't be sharing the answers, but I am sure you will have a great learning time finding those answers...
Developing a software project is definitely not like building a house. If you focus on the learning aspects instead of the simple building you'll probably discover something interesting and unexpected.
How to justify technical debt mitigations in Software EngineeringAndré Agostinho
In this presentation André Agostinho e Cassio Silva covers the importance in dealing with technical debt in software engineering showing the real impacts, daily approaches and best practices for mitigations
Presentation done at the "CTO Crunch" event by France Digitale, Paris, 24/02/2015.
Based on his experience (VP Eng @ Digiplug, CTO @ Pixmania, VP Eng @ Criteo, CTO @ Aldebaran Robotics and now CTO @ Viadeo), Julien shares some hard-learned, bullshit-free lessons on what it means to be a CTO.
Hiring, Tools, Methodology, Technology, Politics: welcome to Hell :)
En puisant dans ses différentes expériences de direction technique (notamment chez Pixmania, Criteo et Viadeo), Julien Simon parlera des risques qui menacent les équipes et les plates-formes en forte croissance, en donnant au passage des pistes pour les anticiper et les résoudre.
Why change code that works - On Technical Debt and RefactoringCarsten Windler
Why should you change code that works? In this presentation we'll cover why Technical debt is harmful, how you deal with existing debt and how you can prevent to pile up new debt.
SRE Topics with Charity Majors and Liz Fong-Jones of HoneycombDaniel Zivkovic
Charity's words make you think while Liz's words make you act, so when you combine them, you get one of the best meetups on Elite DevOps Performance, SRE and Observability topics – ever!
Google Meet recording stopped working, so this *noisy* DIY-copy is the best we got: https://youtu.be/geqoOg4WXcQ. Still, the video is worth your time because you will see how empathy, and simple focus shift
1) from Dev and Ops to your Users,
2) from APM tools to Observability,
can make your workdays more productive, enjoyable and meaningful.
To learn how to define your first SLO, go to Honeycomb's 3-part SRE Crash Course https://go.hny.co/serverlessToronto.
Building a successful DevOps solution requires a holistic view of your development ecosystem plus solid technology that can support your organization today and in the future. Learn how to start defining your own successful DevOps solution and how to position Helix to be at the center of it all.
How to deal with tech debt: Lessons learned from the best engineering teamsAlexandre Omeyer
Tech debt can be really overwhelming. Often when you start to address it, you realize you’re only just scratching the tip of the iceberg. It doesn’t have to be an insurmountable problem, understanding how to prioritize the right issues will enable you to turn the boat around.
Join us in hosting Alexandre Omeyer, CEO & Co-founder at Stepsize. For the first time he will be walking us through his incredible research, which includes interviews with 200+ software engineers.
In this webinar you will learn:
- How to define and understand tech debt.
- The tactics for dealing with tech debt head on.
- Implementing processes and tools to use when dealing with small, medium, and large pieces of tech debt.
- How to think and approach tech debt depending on your company’s stage, size, business priorities, and culture.
Watch the webinar on YouTube: https://www.youtube.com/watch?v=QnizCRe-sV8
From Technical Debt to Technical HealthDeclan Whelan
Everyone agrees that technical debt is a burden on software innovation that we would rather avoid, and certainly clean up whenever possible. However, in most organizations, people don't prevent technical debt nearly as much as they should, and they don't ever get the time to clean it up. Why, then, if there are clear incentives to deal with technical debt, is it a rampant problem?
In this session, we will focus on how to deal with technical debt on several levels, including the individual developer, the team, the software value stream, and the larger organization. While technical debt may manifest itself in a developer's IDE, the problem starts long before the developer decides to copy and paste some code, or creates an overly-complex and under-documented class. The pressures on teams and individuals to take on more debt than they should come from many sources. Therefore, the solutions to the technical debt problem must extend beyond the team.
Similar to Technical Debt - Why should you care? (Agiles Buenos Aires 2011) (20)
Baseado nas previsões para 2016 feitas por Jim Marous, esse material preparado pela CI&T traz uma visão adaptada para a realidade do Brasil e já adianta... 2016 será o ano do Banco Digital.
O próximo nível de experiência digital do cliente bancário (CIAB 2014)CI&T
Paulo Camara responde a três perguntas nada simples que desafiam o setor financeiro. Como aumentar o engajamento dos usuários digitais atuais?
Como acelerar adoção dos novos canais?
Como gerar nova receita através deles?
Mobile banking e o novo cliente digital (CIAB 2014)CI&T
Marcio Kikuti, estrategista digital da CI&T, discute o papel do cliente digital usuário de tecnologia bancária. Esse perfil de usuário, bombardeado com inovações diariamente, tem alta expectativa de interação com as empresas e é exigente quanto ao nível do serviço. Como lidar com este novo cenário?
Não precisamos mais discutir a importância do tema. Mobilidade é o caminho, e não há volta. O momento não é mais do "Por que Mobile?" mas sim "Como?" A Ci&T está pronta para apoiar o seu negócio a sair apenas do campo das ideias e definir a melhor estratégia de execução para o seu projeto de mobilidade, considerando todas as dimensões e complexidades envolvidas.
Contate-nos: www.ciandt.com
DrupalCon Sydney - Selling Drupal to Large EnterprisesCI&T
In this session, Felipe Rubim shares experiences as part of a Drupal Sales Engineering Team. He discusses how Drupal can help optimize a client’s digital marketing strategy, arguments against Drupal that development teams can expect to hear, points development teams can highlight as they promote Drupal to new customers and how to know when the team should cut their losses and move on to another company that will profit from Drupal’s benefits.
Clearly mobile will still be a strong trend in 2013.
Mobility strategies should be consolidated in B2C and B2B markets.
According to Gartner, mobility will continue as a top ten technology trend until 2015.
Of course this topic is very broad, so here are our expectations of where mobile will advance in 2013.
Tendências em Mobilidade para Corporações 2013CI&T
É evidente que Mobile continua sendo forte tendência em 2013.
As estratégias de mobilidade devem se consolidar no mercado B2C e B2B.
Segundo o Gartner, o tema lidera o ranking das dez maiores tendências tecnológicas do próximo ano até 2015.
Como o assunto é muito amplo, veja alguns tópicos nos quais Mobile deve avançar a passos largos em 2013.
As grandes corporações já de deram conta da importância de estarem preparadas para o acesso de seus sistemas e informações por dispositivos móveis, mas poucas já traçaram estratégias de como fazer isso.
Apresentado por Paulo Câmara no Forum Mobile+ em Setembro de 2012.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Le nuove frontiere dell'AI nell'RPA con UiPath Autopilot™UiPathCommunity
In questo evento online gratuito, organizzato dalla Community Italiana di UiPath, potrai esplorare le nuove funzionalità di Autopilot, il tool che integra l'Intelligenza Artificiale nei processi di sviluppo e utilizzo delle Automazioni.
📕 Vedremo insieme alcuni esempi dell'utilizzo di Autopilot in diversi tool della Suite UiPath:
Autopilot per Studio Web
Autopilot per Studio
Autopilot per Apps
Clipboard AI
GenAI applicata alla Document Understanding
👨🏫👨💻 Speakers:
Stefano Negro, UiPath MVPx3, RPA Tech Lead @ BSP Consultant
Flavio Martinelli, UiPath MVP 2023, Technical Account Manager @UiPath
Andrei Tasca, RPA Solutions Team Lead @NTT Data
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