Here are the questions from the chat:
Q: How do you prioritize technical debt pay down vs new features?
A: There's no single right answer, but some things to consider:
- Understand impact of TD on future development
- Estimate effort for TD vs features
- Involve engineers in prioritization
- Set minimum TD paydown each cycle
- Consider TD that enables new features
- Balance long term health with short term wins
Q: How do you estimate technical debt?
A: A few common ways to estimate technical debt:
- Subjective rating (high, medium, low) of code quality issues
- Time estimates to refactor or fix specific code smells
Create Success With Analytics: Living With Technical Debt - Balancing Quality and Perfection
1. Living With Technical Debt:
Balancing Quality and Perfection
With:
Cliff Gilley
Moderated by:
Hannah Flynn
TO USE YOUR COMPUTER'S AUDIO:
When the webinar begins, you will be connected to audio using
your computer's microphone and speakers (VoIP). A headset is
recommended.
Webinar will begin:
11:00 am, PDT
TO USE YOUR TELEPHONE:
If you prefer to use your phone, you must select "Use Telephone"
United States: +1 (914) 614-3221
Access Code: 902-382-948
Audio PIN: Shown after joining the webinar
--OR--
after joining the webinar and call in using the numbers below.
2. Delivering compelling applications with analytics at their core has never been more
crucial—or more complex. For over 17 years, Logi has helped companies embed
sophisticated dashboards and reports in their applications. Logi is the only developer
grade analytics platform on the market, and is rated the #1 embedded analytics platform
by Dresner Advisory Services.
Over 1,900 mission-critical applications have trusted Logi’s analytics development
platform to deliver sophisticated analytics and power their businesses. The company is
headquartered in McLean, Virginia, with offices in Dublin, Ireland and Reading, UK. Learn
more at LogiAnalytics.com.
3. 3
Click on the Questions panel to
interact with the presenters
www.productmanagementtoday.com/webinar-series/create-success-with-analytics
www.projectmanagementupdate.com/webinar-series/create-success-with-analytics
www.businessinnovationbrief.com/webinar-series/create-success-with-analytics
4. About Cliff Gilley
For over 15 years, Cliff Gilley has been a product manager and Agile coach at a wide variety of companies across many
different industries, and is currently working as a Technical Product Manager for the K2 corporation in Bellevue,
Washington. He also blogs regularly as the Clever PM, teaches Product Management for General Assembly, and is an
active board member with the Pacific Northwest Product Management Community.
About Hannah Flynn
Hannah went to The University of Chicago, where she majored in Environmental Studies with a concentration in
Economics and Policy. She now works with Aggregage on social media strategy and webinar production on sites such as
Product Management Today, B2B Marketing Zone, and Customer Experience Update.
5. 5
What is Technical Debt?
LivingWith TechnicalDebt: Balancing Quality and Perfection
6. 6
Origin and Current Application
• Originally coined by Ward Cunningham, a
contributor to the Agile Manifesto.
• Intended to capture work that was done to
offset the unknown or unknowable at a point
in time.
• Now it describes tradeoffs we make during
development by leaning on the “fast” over
“good”.
LivingWith TechnicalDebt: Balancing Quality and Perfection
Ward Cunningham
7. 7
Why do we accumulate Technical Debt?
• The “right” way to solve a problem costs too much (time, effort,
resources, etc.)
• The available technology or skills don’t permit the most elegant
solution.
• There can be reasonable disagreement about the “best” way to
solve a problem.
LivingWith TechnicalDebt: Balancing Quality and Perfection
8. 8
Why do we accumulate Technical Debt?
• Product development and engineering are necessarily tied to business objectives.
• Technical complexity and time to deliver are in constant conflict.
• We choose to take on Technical Debt as a function of a “default” ship mentality (opposed
to “default delay”).
LivingWith TechnicalDebt: Balancing Quality and Perfection
9. 9
Being Real About Technical Debt
• Technical Debt is a reality that we deal with every day.
• If we’re not open about it, it’s happening in the shadows.
• Driving down Technical Debt is just as important as building new features.
LivingWith TechnicalDebt: Balancing Quality and Perfection
10. 10
Being Real About Technical Debt
• Technical Debt is a reality that we deal with every day.
• If we’re not open about it, it’s happening in the shadows.
• Driving down Technical Debt is just as important as building new features.
LivingWith TechnicalDebt: Balancing Quality and Perfection
The cost of never paying down…technical debt is clear;
eventually the cost to deliver functionality will become so
slow that it is easy for a well-designed competitive
software product to overtake the badly-designed software
in terms of features.
- Junade Ali, Mastering PHP Design Patterns
11. 11
Why Understanding Technical Debt
is Critical for Product Managers
LivingWith TechnicalDebt: Balancing Quality and Perfection
12. 12
Decisions We Make Impact Technical Debt
• Schedules, priorities, and design decisions all drive
accrual of Technical Debt.
• Too many Product teams don’t involve engineers early
enough in the process.
• When we aren’t thinking about or talking about the
delivery early and often, we don’t set our engineers up for
success.
LivingWith TechnicalDebt: Balancing Quality and Perfection
13. 13
Nobody Gets Away Without Some TD
• Almost no business can afford to let their
engineers take as long as they want to solve a
market problem.
• The very nature of software development requires
that we make trade-offs or less-than-optimal
choices.
• It’s not whether we take on Technical Debt, but
what we do with it that matters.
LivingWith TechnicalDebt: Balancing Quality and Perfection
14. 14
Sometimes Technical Debt is Useful!
• Focusing on “perfection” sacrifices delivery – and
sometimes we don’t even want the “best” solution.
• Understanding the options and tradeoffs lets us move
forward with our product.
• If we know we’re taking on Technical Debt, we can
implement the system in a way that encourages
refactoring
LivingWith TechnicalDebt: Balancing Quality and Perfection
15. 15
The Intersection of MVP and
Technical Debt
LivingWith TechnicalDebt: Balancing Quality and Perfection
16. 16
The “Real” Definition of MVP
• MVP is one of the most overused
terms in Product Management.
• Minimum + Viable + Product – if
it’s not all three then it’s not an
MVP.
• Most people sacrifice one of the
three, and suffer for the choice.
LivingWith TechnicalDebt: Balancing Quality and Perfection
MVP Final Product
17. 17
MVPs Are Limited, Creating Intentional TD
• Whenever we are working on an MVP, we will make
sacrifices.
• We might not focus on scalability, automation, or other
sources of technical debt.
• When we do this, it needs to be intentional and done in
a way that supports future refactoring.
LivingWith TechnicalDebt: Balancing Quality and Perfection
18. 18
Perfection is Enemy of Good, But MVP Means MVP
• The point of our MVP is to test a hypothesis – it should be
the best test that we can create.
• We’re not cutting corners on the product, we’re making
decisions based on our needs.
• At the end, it still must be minimal, viable, and a
product.
LivingWith TechnicalDebt: Balancing Quality and Perfection
19. 19
“Default Ship” v. “Default Delay”
• All our decisions lie on a spectrum – does this choice
delay shipping or accelerate it?
• Every company leans to one side or the other as a
default position.
• Accepting Technical Debt is a practice that leans us
toward “ship” over “delay”.
LivingWith TechnicalDebt: Balancing Quality and Perfection
21. 21
Knowing Really is Half the Battle
• Technical Debt happens whether we accept it or not.
• When TD is taken on in the shadows, it will show up
again when we least expect it.
• Knowing we’re taking on TD allows us to convince
stakeholders it needs to be paid back.
LivingWith TechnicalDebt: Balancing Quality and Perfection
22. 22
The Longer It Festers, the More Harmful it Becomes
Every piece of Technical Debt that we take on compounds with other
TD already in place.
The more time between taking on TD and resolving it, the more likely
we are to forget about it.
The more code we put into place, the more complex our remedial
refactoring will be.
We still need to be thoughtful about taking on TD, and when it’s not
worth it we reset stakeholder expectations.
LivingWith TechnicalDebt: Balancing Quality and Perfection
23. 23
Don’t Blindly Accept It – Mitigate It ASAP
• If we don’t fix it, we’ll pay for it in other ways.
• We have a responsibility as Product Managers to
ensure we’re fixing what we’ve chosen to “break”.
• Even if TD doesn’t immediately impact users, it will
cause issues further down the line.
LivingWith TechnicalDebt: Balancing Quality and Perfection
24. 24
Tips to Mitigate Technical Debt
• Trust, but verify – ensure that the Technical Debt actually
does need to be taken on.
• As soon as the TD is identified, add mitigation stories to
your team’s prioritized backlog, and keep them high.
• Educate stakeholders about TD – what it is, why it
happens, and what it means for them.
LivingWith TechnicalDebt: Balancing Quality and Perfection
26. 26
Technical Debt Shouldn’t Be a Four-Letter Word
• Technical Debt is an essential part of delivering product to
your market.
• Understanding when and why we take it on balances the
needs of engineering and the product/market.
• While building the best product we can, we still must balance
the reality that complex problems take time, effort, and
understanding.
• Sometimes the MVP is the best learning tool we have, and
sometimes getting the MVP out to the market requires
sacrifice via Technical Debt.
LivingWith TechnicalDebt: Balancing Quality and Perfection
The origins of technical debt date back to the 1990s, when Ward Cunningham (a contributor to the Agile Manifesto) was working with a finance company. Using terminology that he thought would resonate with his stakeholders, he coined the term “technical debt” to capture the idea that we “borrow” time by taking shortcuts, which must be paid back or accrue “interest” in complexity and risk. While he was originally referring primarily to working with technology that was itself limiting and limited, over time we have expanded the term to encompass all of the choices that we make to deliver short term value at the cost of long-term stability.
There are a lot of reasons why we accumulate technical debt in our software – from the blatantly reckless (“We don’t need a design, we’ll make it up as we go along.”) to the thoughtful and measured (“If we do this thing in this way, we can launch now and fix it in the next sprint.”). But between those two extremes is a spectrum, including several common possibilities – we may discover that the best way to solve the problem before us will simply cost too much in time, effort, or resources; we may discover that the technology simply isn’t quite stable enough; or we may find that there are simply too many options and differences of opinion about the “best” way to solve a problem.
There are a few truisms that are all too often sublimated or conveniently left out of our decision-making processes during software development. The first, and most important, is that the business usually drives software development, and not the other way around. That is to say, the development teams should always be attempting to achieve some business goal – and this in turn implies that there are business considerations that must be taken into account. Release dates that are based on specific market needs can and should constrain development work – meaning that some of the TD that we incur is due to meeting these constraints. Next, we know from decades of research and common sense that the technical complexity of solutions we’re building are always in conflict with time to deliver – its’ the classic Good / Fast / Cheap pyramid – “Good” comes at the cost of “Fast” or “Cheap”. Finally, there’s a cultural issue that sometimes leads to us determining when and how to take on TD – I’ll call this the “default ship” v. “default delay” mentality, something we’ll touch on later.
Even though we often don’t want to talk about it, Technical Debt is something that happens every single day during the development of our products. It’s something that can either happen behind the scenes, because people are afraid to talk about it, they’re punished for taking “shortcuts” that are needed to meet deadlines, or we’re even being willfully ignorant of the choices being made until they cause us pain – which they will at some point in the future. It’s also important for Product Managers to educate their stakeholders about the dangers of not taking steps to remedy Technical Debt. Whether you want to believe it or not, driving down the technical debt that you know about is as important as building new features.
Most people either don’t understand or don’t want to admit what Junade Ali observed in 2016 – ignoring TD opens you to serious business consequences. [read quote]
Intro to understanding TD
All too often, we shift the burden of caring about Technical Debt to our engineering teams – which is a seriously bad move. Sure, it insulates us from the problems in the moment, but removing us from the conversation means that we lose visibility into what those decisions are and what they mean for us. Further, as Product Managers, we’re often direct contributors to the things that cause engineering teams to incur technical debt in the first place. We’re the ones who manage launch schedules with our dev teams, we’re the ones who are in charge of priorities and prioritization, and we’re often the ones who are called on to make final design decisions – all of these things can cause our dev teams to take on technical debt. We also indirectly cause technical debt when we don’t involve our engineering teams early enough in the process, to tell or warn us ahead of times about things that might cause pain down the line. As Product Managers, we owe it to our engineering teams to make sure that we’re constantly thinking about the actual delivery process behind the plans that we make – so that we can set them up for success with minimal technical debt!
Engineering tasks are constrained by business requirements – there’s almost no business out there that can allow their engineers to take as long as they want to solve whatever problems they might have (contrary to what the #NoEstimates crowd might want us to believe). Rather, the very nature of software development and business delivery requires that we make technical tradeoffs and decide that short-term gains are more important than long-term stability. Because technical debt is an inevitability, we should be less concerned about whether we are taking it on (because we are) and more concerned about what we do with it after it’s already decided. We should also be aware of the ramification of taking on technical debt versus doing the “right” thing at the time – it could be that the best choice is to delay delivery to improve quality, but we can only make that decision if we raise the question.
It’s also important to understand that Technical Debt isn’t always a bad thing. There are very good reasons that engineering teams will take on Technical Debt in order to meet the business goals that we have set for them. First, we as Product Managers already know that we don’t always need to build the best, most feature-laden, fleshed-out feature – we should extend that acceptance to our engineering teams, and not let perfection be the enemy of good. We also want to make sure that we’re talking about TD so that we know the limitations of our product or platform as a whole – this information is critical as a Product Manager, because it can inform our own work in prioritization, design, and problem definition. Finally, if we’re upfront about the fact that we’re taking on TD, we can make sure that the implementation of the TD work is done in a way that invites refactoring – not in a way that requires a complete ground-up rework. Knowing that we’re intentionally taking on TD and adjusting for that choice is a responsibility that every Product Manager should take very seriously.
Intro to intersection of MVP & TD
“MVP” is one of the most overused and seemingly misunderstood concepts in all of Product Management, to the point where people have proposed other terms which actually mean pretty much the same thing as MVP. The problem is that most people forget that a true MVP is the minimum amount of work needed to deliver a viable set of features that are actually a product. If it’s missing any of these three attributes – if it’s more than the minimum needed, if it’s not actually viable, stable, and usable, or if it’s not actually a product that solves some set of valuable needs in the market, then it is not an MVP. Whether you prefer to call this “minimum lovable product”, “minimum usable product”, or “simple / lovable / complex”, we’re all talking about the same thing – something that reflects the least amount of work that is usable and stable enough for people to enjoy, and that solves a valuable market problem. Within those definitions, we can be flexible – if you want lovability, make that part of minimum or viable. The goal is to build the cupcake before you build the wedding cake – failing early saves us time, effort, and money. That is the point of an MVP.
“Minimum Lovable”, “Minimum Usable”, “Simple / Lovable / Complex” -- all are restating the “correct” definition of MVP
The intersection of MVP and Technical Debt should be pretty obvious – as a simple matter of focusing on the minimum part of our MVP, we’re likely going to make sacrifices on the technical approach. We might choose not to focus on scalability, automation, complexity, edge cases, or any number of possible sources of technical debt. The point that we need to take home today is that we need these choices to be intentional and not accidental, and when we know that we’re taking on this TD, we want to make sure that it’s implemented in a way that supports future refactoring. The sooner we can come back and improve what we’ve taken technical debt against, the better off we will be.
The reason we focus on building an MVP is to test a hypothesis – it could be a market hypothesis, it could be a problem hypothesis, or it could be a solution hypothesis. But we’re building the MVP for a specific reason, and we always want our MVP to be the best test of our hypothesis that we can make – we shouldn’t be cutting corners to make the product that we want to release, we should be making decisions based on the needs that we have and the data that we’ve collected from the market. We want to be “ruthlessly devoted” to ensuring that we’re delivering our MVP while making sure it’s the best MVP that we can make. Is that a contradiction? Perhaps, but as Product Managers we’re used to dealing with contradictions and still managing to deliver on our promises.
There’s a concept I came across while doing research for my blog a couple years ago that really struck me, and I’ve been evangelizing it ever since. This is the concept of “default ship” versus “default delay” cultures. While there’s a spectrum between the two, it seems that a lot of different companies wind up landing on one side or the other, usually for historical and cultural reasons. A “default delay” company tends to come from the bad, old world of actually shipping physical media – where you simply couldn’t afford to ship with bugs, because fixing them was such a pain. Similarly, many large B2B platforms take a “default delay” approach because of the costs associated with disrupting the processes of their large enterprise customers. In the consumer space, “default ship” is far more common – Facebook is infamous for it’s “move fast and break things” motto, and there’s rarely a AAA video game title that doesn’t ship without a day-one patch, among other continuous fixes over time. It’s important to know where your company lies on this spectrum, as it can directly affect how we choose to deal with TD. Companies that are more accepting of TD tend to be further along the spectrum of “default ship” than those who want to take on as little debt as possible, who wind up on the other side, as “default delay” cultures. The more we can convince our stakeholders and our company that TD is not necessarily a bad thing, and can be an accelerator, the more we can shift our culture to be more “default ship” oriented, which is where most companies should be in this modern era of software development.
Managing technical debt
Fortunately, managing technical debt actually isn’t really as hard as it might seem – and while you might never be able to handle or manage all of the technical debt that your teams are taking on, you can start with present and future choices and work your way back as time allows. The single most important factor in managing TD is simply knowing about it – being honest with your teams about the fact that TD happens, that it’s a necessary evil, and that it’s okay to not just talk about it, but to discuss it with others both inside and outside the engineering organization. The worst thing that we can do is ignore it – because unknown technical debt always shows up when we least expect it, and then everyone is scrambling to firefight the issues when they could have been mitigated sooner, if we’d only been honest about it. And, as Product Managers, when we know that we’re taking on TD, we can use that opportunity to educate our stakeholders about it, and to help them understand when, how, and why we’re going to pay that debt back. If we take the time to educate our stakeholders, we just might find that they’re more willing to negotiate on priorities than we think that they might be, particularly if we can position paying back TD as a net benefit to both the company and the customer.
Ignoring technical debt is a tempting thing to do for any Product Manager – even if it sounds like we’re intruding on the “how”?. But when we ignore it, we wind up setting ourselves up for failure in the future. You simply must be aware of the technical debt your teams are taking on for the following four reasons… [read slide]
1 – TD compounds over time, just like interest – a decision here, then there, then over on the other project, all combine to create a mishmash of interactions that we will someday have to unwind. Sooner is better, later is never.
2 – Let’s be honest, we’ve all got huge backlogs of work, and it’s very easy to lose track of one or two stories that deal with mitigating TD. The longer we let something sit on the backlog, the more likely it is to never get done, and this seems particularly true for TD work items, as they’re not usually viewed as providing “customer benefit.”
3 – The longer we wait, the more code will be added around the TD that we incurred, and as a result, unwinding that choice that we made to skip some concern becomes much harder to resolve. When we take shortcuts in complex solutions, we’re just increasing the complexity for the future.
4 – None of this should be taken to mean that we should just blindly take on TD to accelerate our delivery, every time. Rather, we need to work with our engineering teams to understand exactly why they think we need to take on any kind of TD, what the options are if we choose not to take on the TD, and what the benefit is to the system or the customers in doing so. Taking on TD needs to be a conversation and not just a decision.
Pay for it in other ways:
New hire training and onboarding in development
Slower time to market for future features that interact with TD
Difficulty of testing may result in uncertainty in future work
Issues down the line:
ETL @ Mercent
Complex systems introduce unknowable risks – TD compounds this
It always hits us at the worst possible time.
It’s our job as Product Managers to understand the “whole product” – which includes the choices being made by our development teams. We need to be proactively involved in discussions about technical debt, so that we can do a better job of prioritizing our problem statements, and managing stakeholder expectations, the two most important things that we wind up doing every single day. Here are three tips to mitigating technical debt that you can literally start doing tomorrow. [Read slide]
Trust but verify – it’s really easy to just take the engineering team’s word for it, and to just accept that they know what they’re talking about. But sometimes there are alternatives to taking on the technical debt, sometimes there are things that the team just doesn’t want to do, even though they can do it. We should trust their opinions, but engage with them to be sure that we’ve exhausted other viable options.
Mitigation – All too often, we take on technical debt and tell ourselves that we’ll add the stories to mitigate it later. And then we forget. And then two years later, the TD comes back to bite us. It’s essential that whenever you decide to take on technical debt, you immediately add remedial stories to the backlog so that they can be prioritized and addressed sooner rather than later.
Education – Stakeholders don’t care about TD because (1) they don’t know about, or (2) they don’t understand it. Part of our jobs as Product Managers includes taking the time needed to help our Stakeholders understand the consequences of prioritization and schedule choices, and ensure that they recognize that taking on technical debt is a short-term gain with long-term effects.
Intro to wrapping it up
If you take nothing else away from this webinar, it’s the understanding that technical debt is not a four-letter word (neither literally nor metaphorically). It’s an essential component of use delivering valuable products to the market – if we never incur technical debt, it’s entirely possible that we never ship a product. We need to be proactive as Product Managers in working with our engineering teams to understand when and why we want to take it on, and balance those desires against the business reality that we’re trying to work in. And we should leverage technical debt as another learning tool – understanding the nature of the technical debt that needs to be taken on can keep us better informed about how the things that we want can (or can’t) be easily done – which in turn feeds back into prioritization and stakeholder management.
Thank you for your time today, I hope you’ve enjoyed this little discussion about the ins and outs of Technical Debt – let’s turn the podium over to you, the audience. Does anyone have any questions?
