Prioritizing technical debt using bcg matrix in agile engagement
1. Prioritizing Technical Debt in Agile Engagement using BCG matrix
By
Sandeep Sapre
Date â 19-May-2017
Abstract â
There is always bitter battle between business mind and engineer mind on the perfection
expected from iterative software delivery. Along with the growth of the product in terms of
new features , it is also equally important to know the debt that are piling up and take a slack to
address those. Purpose of this white paper is to bring these two perspectives together and
suggest approach. All development will result in some amount of technical debt â the challenge
is to manage it, reduce it and develop practices to keep it at a level that does not impact
performance and availability of your critical business services.
This paper will offer in depth analysis of technical debt in agile practices and how BCG ( Boston
Consulting Group ) matrix can be used to prioritize and reduce the technical debt.
Key Concept â Technical debt,agile,BCG ( Boston Consulting Group) matrix & market share
2. Technical debt -
In 1992, Ward Cunningham, inventor of âwikisâ and a signatory to the Agile
Manifesto Doctrine, coined the term âtechnical debtâ to describe the application
design trade-offs organizations make every day.
Technical debt is like financial debt due to quick and dirty solution provided in terms of non-
scalable design /quickly written code or whenever corners have to be cut in design, coding and
testing due to time to market pressure. It incurs interest to be paid as of financial debt . In this
case, âinterestâ means impact on availability as well as higher support and application
maintenance costs .Other reasons for technical debt may be poor decision made by engineering
team ,legacy code or outdated infrastructure.
As shown in Fig. 1 landscape of technical debt ,on the left, evolution or its challenges; on the
right, quality issues, both internal and external. With iterative development , project may not
follow systematic design and testing in long term view which increases the technical debt. But
considering time to market is a backbone of agile , one must be aware of the amount debt.
Fig. 1 Technical debt landscape
One must identify those debt and plan in form of backlog story during release & sprint
planning. Along with code analysis, architecture is also crucial part of technical debt [1]
3. Type of technical debt and risks associated -
With agile development , based on initial understanding of business service/product ,
application design is prepared. It is expected that as iteration evolves, the same design
document/architecture is updated to avoid misunderstanding between business, architect and
development team.
Code debt may happened due to inexperience development team or very complex code written
which is difficult to understand and updates to it may lead to another problem. Another source
of technical debt are lack of documentation and testing protocol.
Technical debt is a trap as depicted in Fig. 2 so if you do not address then loop will continue to
accrue the interest.
Fig. 2 Technical debt trap
Risk due to technical debt can be classified in two terms :
1. Aggregative â These are the risk which accumulates over the period of time and then
prohibit organization to respond to new market, competitiveness and security attacks
e.g. unmaintained code
2. Time driven â Risk which has larger impact as time passes yet the cost to fix it remains
same e.g. oil change in car at 5000KM or 20000KM. At certain point neglecting the to fix
the issue can cause catastrophic failure. Typical in IT industry example can be providing
infrastructure scaling required.
Bad
code/design
/testing
High cost to
maintain
Moved
resources to
create new
functionality
Missed
business
opportunity
Lower
budget
Technical
Debt
4. BCG Matrix (Boston Consulting Group ) -
The Boston Consulting Group (BCG) Matrix is a portfolio management tool created in 1970 by
Bruce Henderson. The purpose of the matrix is to ensure long-term revenues by balancing
products requiring investment with products that should be managed for remaining profits. The
BCG matrix has two axes: relative market share (indicating profitability, through economies of
scale) and market growth rate (indicating market attractiveness), which means assets can be
classified into 4 categories:
Question Marks, Rising Stars, Cash Cows or Dogs. [2]
Fig. 3 BCG Matrix
ďˇ Question Marks: New assets enter the market as Question Marks.
ďˇ Rising Stars: Rising Stars generate significant revenues and can generate profits, but
they also require investment and focused marketing in order to maintain their positions
in the market.
ďˇ Cash Cows: Cash Cows are in a low growth market which means market share is difficult
to win and margins are tight. Therefore they should be âmilkedâ for remaining revenues
and profits. Cash Cows are often the main source of company profits..
ďˇ Dogs: As assets with low market share in a slow growing market, Dogs usually represent
the last stage in an assetâs life and should be considered for divestment.
The matrix enables you to determine which assets could produce future revenues and make
investment decisions that ensure funds are allocated to the right assets.
5. Prioritizing technical debt using BCG â
Fig. 4 Technical Debt â BCG
As a researcher and being worked in IT industry on agile projects, I have prepared the technical
debt BCG as shown in Fig.4 which may vary based on company and product being offered in the
industry. BCG derived here is typically for solutioning type of project for embedded software
products with scrum method. It is experience that most of the time business line is more
interested in Cash COW segment if market is dynamic/volatile.
Business line and technical mind must sit together to craft this technical BCG and then those
can be part of release or iteration plan which further can be as per module/product line/feature.
Conclusion -
Technical debt is created the moment is product/service is released and keeps on accumulating
for subsequent versions and is natural process. If this is neglected can cause damage to
business in terms of customer compliant, low market share and non-scalable product. With the
proactive approach , if this is tackled at right time then gives edge to the organization in
competitive world.
References â
[1] Philippe Kruchten, University of British Columbia & Vancouver Robert L. Nord and Ipek
Ozkaya, Technical Debt: From Metaphor to Theory and Practice Engineering Institute
[2] Michel Porter ,Competitive Strategy ,1998
www.scrumaliance.org
www.agilealiance.org
www.agileweboperations.com
Rising STARS
⢠Difficult to maintain- Code base is too large or
complex to maintain
⢠Poor test coverage - Insufficient tests writeen
leading to poor coverage
⢠Customized Request - It is case based wherein
customer may demand specific change which can't be
denied due toi business value
QUESTION MARK
⢠Scalability - Flexibilty of code to adapt future
changes without much hussle
⢠New features - Set of new feature from Product
Owner which may be disruptive type
⢠Legecy code - code which no longer enginnered
but patched
Cash COW
⢠Rearchitecting the product - Initial and
subsequent versions of product calls for rearchitecting
⢠Poor documentation - Lack of documentation (
design + code)
⢠Fragile Code - code which is easy to break/fragile
DOG
⢠Non optimal implementation -
Implementation has scope for refinement
⢠In-effective infrastructure - Lack of
server,environment & tool chain
Technical debt -
BCG
LowHigh
Low
High
M
a
r
k
e
t
G
r
o
w
t
h
Market Share