Scrum Master's responsibility concerning technical debt
Hello everybody,
I would like to know how you guys see the role of scrum master when it comes to technical debt. Sticking to the book, technical debt should be something that is primarily affecting the development team and should be addressed by them. Since a lot of SMs I know (me included) also have a development background we all know that technical debt is bad and will impact the team's ability to deliver an increment of value at the end of the sprint (possibly even to the point that the PO will complain about the team's performance or reject the increment). Worst case is that management starts to question the value of Scrum.
Since the SM is the guardian of scrum and coach to the team and if he knows about this possibility, should he intervene in some way? Is it even his responsibility to coach the team upfront to pay attention to technical debt? Or should he only offer his help if the team asks for advice?
If the SM has a technical background and the PO doesn't (seen frequently): if the SM is aware of the implications of technical debt, should he proactively engage the PO or should he talk to the team and encourage them to bring this topic up to the PO, so that he is made aware of the situation and can adjust his plans correctly?
My point on this: if the SM is aware of technical debt and detects that the development team's way of addressing the issue is insufficient he should approach the team, raise awareness and make sure the team understands the cost of technical debt (in terms of velocity and quality). Likewise he should encourage them to engage the PO (perhaps offering to initiate a discussion or arrange a meeting) to talk about the situation (transparency!) so that all parties can work together to improve the situation.
What is your take on this?
I am totally agree with you that Scrum master should give an advise for the team if he/she see some advantages which will increase quality or speed of the project delivery or defend the team from obstacles like technical debt. I think it is a must for a Scrum master. Scrum master has 4 hats: Facilitator, teacher, mentor and coach. So he/she can wear any hat in appropriate situation. He must track the process in order to deliver project with better quality, decreasing risks and uncertainties, moreover define obstacles and impedinments for the greater success of the project.
The first thing to do is to make technical debt as transparent as possible. If the team and the PO are clear about the nature and extent of the debt being incurred, they may be prompted into self-organizing a mitigation strategy.
One technique is to coach the elicitation of a technical debt register, so that undone work is exposed and considered for articulation into the Product Backlog.
Hello, as it was pointed out, first the technical debt should be transparent to the Team. As a Scrum Master, it could be suggested the Team starts including the filed issues to a release backlog, and then to each Sprint back log, with creating a user story.
My Team implemented this practice, and it helped to get all defects under control. We do not create US and add them to a Release Backlog. We use the defects tracking tool directly.
Initially we ran into the issue of not knowing how to size such stories, as typically those issues come either from the field or our regression Team. Note, we have to deal with legacy products along with developing new products.
A lot of times, info provided in filed cases is not enough to understand what should be fixed, how much of work it will be needed, even if it is a valid defect, and so on.
So, we are taking each defect as a Spike User Story first. That helps to investigate on the issues. It also helps to see if the issue is that urgent to be fixed. Once the Spike work is done, a new user story gets created to fix the defect. The size of such user story is well known, the priority of the fix is more accurate. So, each US (defect) gets prioritized by the PO and goes into a Sprint backlog accordingly.
Now, we down to a very manageable tech debt size. Each new defect that comes, gets through such Spike, and ends up being fixed based on its priority against other deliveries.
Hope this helps.
Just a comment on
"A lot of times, info provided in filed cases is not enough to understand what should be fixed, how much of work it will be needed, even if it is a valid defect, and so on"
Does it help if this home work is done by the PO except the How part?
>>>Does it help if this home work is done by the PO except the How part?
This depends on a product owner technical skills level.
The PO, we work with, does the very first level of prioritization. Only high priority defects come to the Team, to further evaluate them. Sometimes, developers need to look into the code to see how much of changes might be needed. Or, evaluate if a third party product is involved in a needed change, and so on. That often times requires some skills that not all POs possess. Our products are quite complex and do reply on third party products. So, having the Team to do the Spikes works better, at least for us.
Are Field Issues are Operational issues you mean.