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
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.
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?
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.
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.
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?
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
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?
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.
![KSI - Dirty [Official Visualiser]](http://i.ytimg.com/vi/VoDh1h1dPUE/mqdefault.jpg)
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
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.
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?
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.
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.
Thanks for showing how to stick pink sticky notes on a whiteboard. Really useful.
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?
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
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?
I've been working as BA last 9 years in Fixed price projects from scrach.
Mesej yang jelas, struktur yang jelas, mudah difahami, terima kasih
Thanks for the video!
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.
jesus
sorry but not helpful!