Slaying Technical Debt

In this Scrum Tapas video, Professional Scrum Trainer Todd Miller discusses the concept of Technical Debt and ideas on how to work to remove it. He looks at different concepts and why removal over time is important to the long-term viability of a product.

[@strangetml]

0:30 why there was technical debt 0:44 Tech debt: internationalization 1:00 why debt? more bug when release for internationalization 1:23 method: product backlog refinement sections 2:35 debt wall makes team want to get rid of it 3:00 took debt issues into sprint planning sections 3:15 debt wall helps create sense of ownership (to pay back the debt) 3:35 remove debt along incremental value delivery 4:30 try visualize and owns the debt to increase software quality and customer's satisfaction

[@scrum532]

Business value is not independent from technical debt. This was unintentionally highlighted in the language used surrounding the talking points. Too often it is presented as an independent item creating a false dichotomy. Reducing production bugs, increasing feature release rates, improved customer satisfaction, and improved morale all have a direct and tremendously impactful relationship with business value.

[@Mayaadyby.]

Thank you for this video. I think you forgot to mention that, after we put all bugs on the whiteboard first, we prioritize them then, take actions to eliminate them.

[@alexc8920]

Thanks for showing how to stick pink sticky notes on a whiteboard. Really useful.

[@МаксимБелкин-л1к]

Mesej yang jelas, struktur yang jelas, mudah difahami, terima kasih

[@2LegHumanist]

How did you determine what is technical debt? Was it as simple as identifying defined anti-patterns and code that does not conform to SOLID principles? Were there any other considerations? How did you quantify it? Was there any disagreement on what does and does not constitute technical debt?

[@toddmiller976]

Hi, In the situation I referenced, there was often much debate over what/wasn't technical debt. It was an application that initially was meant for a single purpose but grew quickly outside the bounds of the capabilities of the architecture. We'd run into long methods, archaic implementation strategies, or code that was no longer fit for purpose. We tried to live by the "boyscout rule" but in some instances, the effort to refactor was great so we'd create a card for it. To quantify, these items were on the product backlog where we used relative estimation to provide some sort of effort. We worked on chipping away at it while still ensuring we delivered business value from sprint to sprint.

[@danilovalle3263]

Thanks for the video!

[@LAMPOVOEIT]

Is that what you are teaching people all around the world? How to create stickers and put them on the board? I thought you would provide us with a silver bullet solution or at least guideline how to plan it and slice piece by piece. What if you have fixed price projects, how to deal with it?

[@ScrumOrg]

Sergii, this is just 1 thing of many ways to deal with and manage technical debt. Todd was giving an example of things he has done with his teams to deal with it. You can find hundreds of articles and suggestions to dealing with Technical Debt here: www.scrum.org/search/node?keys=technical+debt

[@toddmiller976]

Hi Sergii, I wish there was a silver bullet but unfortunately there is not. This was a simple visual method a team I was on used and it worked for us. You asked an interesting question about fixed price projects. I have worked in that world quite a bit. The looming pressure of deadlines can cause developers to be pushed into rushing, taking shortcuts, and working long hours which has us coding with tired eyes. Ideally in those kinds of situations scope is negotiable, not quality. What's important, I believe, is bringing transparency to any technical debt that has been created and tackling it immediately. Hopefully, we are doing our very best not to create it in the first place. What are your current experiences?

[@LAMPOVOEIT]

I've been working as BA last 9 years in Fixed price projects from scrach.

[@beatanowakowska1403]

Sounds too easy :D but I would strongly agree that technical debt is highly connected with value. If you have technical debt experiments are so much harder, so you cant validate hypothesis and figure out what brings value.

[@mandeepsaini5517]

sorry but not helpful!

[@JonathanCrossland]

jesus