Technical Debt & Scrum: Who Is Responsible?

12 thoughts on “Technical Debt & Scrum: Who Is Responsible?”

1. I fully agree that technical debt (TD) has to be presented during sprint review. Should I describe TD full life cycle, I would say :
   Main 2 root causes with 2 distinct life cycles:
   1)priority to business feature delivery against quality code dev and architecture
   2) evolution that requires to review previous code.
   Identification steps
   In theory, in both root case, TD are detected before causing issue
   1) during sprint poker planning because there will be 2 opposite estimations, a quick and dirty one & a longer but clean one. In this perfect world, a TD user story is initiated in the backlog and will be handle later one.
   2) also during sprint poker planning because there will be a heavy estimation for the new user story , or there will be to 2 opposite estimations, one forgetting the TD side effect & one taking into account the TD side effect. Case 1 can apply at this time for this new user story.
   Execution phase : Once in the backlog, it follows usual process
   None Nominal case : It’s none nominal when it is not detected during the poker planing
   Even with a dream team, it happens that TD are not identified so early in the process.
   In such case, if you listen carefully, first signs appear during daily meetings through when dev team will talk about problem. As SCM, when I have such feeling, I ask the dev team if it could be due to a TD. Doing so minimize the impact of the TD by detecting the cause early.
   Worst case, you detected it because some US take far more time than expectation or worst because some US estimation are infinite (= longer that 1 sprint to be deliver), while they should not. In such case, 99% chance you have a TD, a bid & deep one !
   Identification is a key issue of TD. It can jeopardize the scrum team mood as well as Scrum image because efficiency will decrease little by little, but surely.
   TD identification is not natural nor easy because technic is a mean not an objective,
   The whole team is involved to handle TD, but I think the SCM is the best person to think about it and help the team to identify when there is TD. Once identified, it becomes rather PO and dev team responsibility to manage it.
   Feel free to comment.
   As soon as TD is detected, fog disappears, sun shines again 🙂

2. I suggest moving away from the term “Technical Debt” and instead refer to it as “Technical Health”. Many of us accept “debt” in our daily lives. We borrow money to buy a home. Countries are running up tremendous debts to booster their economies or provide national security. On the other hand, Technical Health implies we are concerned about our well being. We understand that if we have a disease that it potentially will get worse, and we will become more ill over time. We understand the importance of taking care of ourselves if we are to maintain our health over time..

   Please view my blog posting at http://www.agile2success.com/2017/12/18/technical-health-for-the-new-year/ for more about this topic.

3. Absolutely! Being a feature factory ignoring technical debt is an unsmart decision in the long run. Being focused on a debt-free code base is often similarly problematic as the return on investment is questionable. The most successful companies manage to find the right equilibrium between those two forces.

4. One critical aspect related to technical debt, even if fully visible in the backlog, is how to properly articulate the business value of paying it off relative to the value of new features. When technical debt stories go head to head with other user stories, often those win because their value is often more easily understood.

5. One of the biggest recurring issue I’m seeing is the shadow accounting as mentioned in this article. It causes issues in multiple ends. I’ll not talk about the pain points but I’ll briefly mention a very easy , quick solution that would help to realize the problems.

   What we’re currently experimenting is introducing Developer and System as personas. A sample US,

   “As a developer I would like components to be in story book so that it would be easier to reuse them”

   ”
   React storybook is a tool for writing styleguides.

   Background

   We have started writing more and more components and it’s important to be able to keep track of them, not to write the same things twice.

   Benefits

   helps new developers to use the existing components faster
   makes the components more encapsulated
   fascilitates the communication with the designers
   helps to keep the design consistent

   Acceptance criteria

   All X components are put in storybook
   Documentation written how to use the storybook

   Notes/Questions/Uncertainties

   No components UI tests (storyshots)
   No deployment of storybook”

   and it goes through the flow that a feature request would go. Story has to be clear, refined, discussed, estimated, and prioritized by the Product Owner. Creating such channel would align the team members in any time to put their hidden ideas to one and only backlog. Also because it goes to through the same flow, the technical only things would be easily readable by anyone in the project. Also story splitting can be applied to limit the improvement at one time, and do the iterations.

   I agree with dealing with it every sprint within some percentage levels as this is one of the strategy. Also what I see helpful in case of huge technical debt is dedicating more time, or dedicating a sprint. When it comes to the business value, well, the PO would not have a business if the system fails 🙂

   I don’t really think that the Product Owners only care about the features and nothing else when they’re working with the team. The issue is they don’t have enough visibility and control over the technical tasks. When they would see, for example 20 backlog items, which are all understandable by him/her with the goals and the impacts, they would be the one who would arrange time/resources in roadmap for that. Also because of the lack of visibility and control, frustrations, and lack of trust happen which leads to a harder situation for dealing with the actual work – dealing with technical debt.

   One last thing from this approach is that it would show the impacts of the things done earlier. What I mean, PO would/should know if they would get more users the amount of reported bugs might increase, or amount of feature requests. It’s a good thing because the business is growing. But, while doing that, The system and The developer personas would also generate requests because they are in the same environment, and they definitely shouldn’t be forgotten. And this all eventually would educate the PO with foreseeing the technical debt as it’s giving transparency and control earlier.

   So, to sum up, in my opinion the real issue is communication. And improving communication practices for technical tasks would ease many things.

6. I am convinced that there are many forces out there which drive technical debt taking. My observations of the organisational dynamics leading to a technical debt have inspired me to design a board game which explains the related issues to non-technical staff. This game has been the technical debt eye-opener at c-level ever since. I am sure we need 3 things to do in order to tackle the issue: explain, explain, explain

7. I totally agree, Ron!

8. While it would be helpful if the scrum bible, the Scrum Guide, addressed technical debt, perhaps even more powerful, the product management bible, Marty Cagan’s Inspired: How To Create Products Customers Love, does address it. Inspired (p.28) says, “The deal with engineering goes like this: Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend on… whatever they believe is necessary to avoid ever having to come to the team and say, ‘we need to stop and rewrite’…. I get nervous when I find teams that think they can get away with much less than 20%.” Cagan’s comments TL;DR? If you’re not spending 20% at least on paying down technical debt, you’re marching toward technical bankruptcy.

9. Joshua adds per email:

   Stefan – for your “related articles” I recommend a nod to the book “The Art of Agile Development” by James Shore and Shane Warden, which has a lot to stay about tech debt.

   For example…

   https://www.jamesshore.com/Agile-Book/done_done.html

   https://www.jamesshore.com/Agile-Book/collective_code_ownership.html

   https://www.jamesshore.com/Agile-Book/refactoring.html

10. I would not talk about rework due to quick but bad coding. This is not a good practice , nether in V project nor in SCRUM. The solution as a SCM in that case is to change or educate the team.
    I’m both an architect for decades and a SCM for nearly 4years now. My architecture job & skills help me understanding source of technical or functional debt and the key is there :
    DEPENDENCY and STRUCTURAL CHANGE.
    When user stories are independent from each others, you don’t have debt. You just give up older stories and develop new one. When you have dependencies, then you start having large blocks of code having a structural organization (an architecture) and when a change happens that required a change of the previous architecture, all of a sudden you have a large debt. I have not other solution than understanding the overall impact and reviewing all the all technical of functional blocks that need to be rethink and re coded.
    This happens for example when the initial backlog was done for one type of customer and is extended to several types. All what was done for one required to be able to support N. In such case, we freeze new US until the change is done -properly -. Spreading such change on several sprints leads to far more issues and delay than focusing on the debt recovery. Should the PO really requires to develop new US, I dedicate 1 ou 2 dev max for the new US and the rest of the team for the debt recovery. I do NOT change the team focusing on the debt until it is recovered.

11. Because Agile is responsible and especially Scrum. When you have iterations smaller than 6 weeks which Scrum prescribes is hard to make a coherent arhitecture. Also the way this is tested means that bugs that appear due to requirement dependencies go unnoticed until the release to final customer.

12. A significant source of technical debt are third-party dependencies going end of life.
    These are not by-products of speed vs quality, but still part of debt.

This site uses Akismet to reduce spam. Learn how your comment data is processed.