Retrospective - too many small and random problems. Death by a thousand needles

Question

After reading some literature about retrospective and actions it is not clear to me what to do if team faces big variety of random and small issues during sprint, and these problems do not occur often.

For example, there is: - a bad code region where it is hard to implement new features, but features that touch this code come 1-2 times per year(of course this is just an observation of the historical events and there is no guaranty that this will not change in a month). It will take 1 week to, refactor the code; - Or there was a rare story that requires complicated deployment process, but the same, such stories/tasks happen few times per year and it usually takes 2 days to do it.

Because actions from retrospective take teams time that can be dedicated to implement new product features it is not clear if team should pick any of such actions.

Should team just take the biggest impactful problem despite the fact that it is rare? Or should it collect more data and don't take any action items from retro( besides data collection)?

Answer 1

You should define "big impact" - what metrics are important to you? Which improvement gives the biggest customer value? You might apply the same measures, that are used to priorize features in the backlog (for example: Backlog Prioritization techniques).

Try to estimate what the impact of these improvements in a long term will be. Are you able to deliver features faster and with better quality?

If there are critical issues / bugs that might break the whole application, they should be fixed as soon as possible!

Dealing with technical dept can be a thin line, where there is sometimes no right or wrong - but there are approaches to do so:

• 11 Strategies for Dealing With Technical Debt
• Escaping the black hole of technical debt

In general the agile way is iterative, maybe you try to split the big problems into smaller ones and improve your process / code base in small steps (Although I know that some refactorings have to be done in one big step).

Answer 2

Technical Debt is Often Invisible

The problem with technical debt isn't just that it's there. The bigger problem with such debt is that it becomes a "missing stair" that everyone steps around and never talks about. In other words, it becomes invisible work that eventually acts as an unexplained drag on the project.

The law of transparency says "No invisible work, ever!" Make the problem and the costs visible, and the correct approach for managing project risk will largely become self-evident.

Some Ways to Address Technical Debt

From an agile practice perspective, you have some key options based on the characterization of the risks:

1. Take known technical debt with a clear etiology (a "known known") and add it to your backlog as work to be prioritized.
2. Use the team's knowledge about the problem area to add a fudge factor to the level-of-effort estimate every time a new story touches upon a known problematic area. Depending on the work, this may be a "known known" or a "known unknown."
3. Have the team write a wrapper or interface for the problem areas. This leaves the landmine in place, but makes it easier to step around it almost indefinitely—until you can't because the underlying behavior of that code section needs to fundamentally change.
4. Write some better (and if necessary, duplicative) code and deprecate reliance on the old code. Don't move the old code until or unless it's in-scope during an iteration.

The point of all your options is to avoid unknown-unkowns, where you can't quantify the level of effort or the project risk involved. There are certainly other techniques you can use—whole books such as Working Effectively with Legacy Code have been written on the topic of technical debt and legacy coding techniques—but from a project management perspective the issue is about balancing the team's sustainable forward progress against hidden or unexpected costs.

A Project Manager or Agilist's Real Goal

If you have a known problem with the codebase that is affecting the quality of the product, the performance of the team, or the performance envelope of the project, then your obligation is to surface that issue so that the issue and its associated costs are fully visible to the team and to management. By creating transparency around the issue, you convert project drag to a known-known that management can address (or not) based on a more-informed strategic decision.

Answer 3

This is risk and issue management. I have little knowledge about Agile but I suspect handling risks and issues is no different, albeit perhaps some minor / benign technique differences.

Both require prioritization and both risks and issues are prioritized based on the value created from curing the issue or mitigating the risk against the cost of doing so and secondary risks created. The difference between a risk and issue is that, with risks, the value is calculated against its probability. So for an issue, you can quantify your impact like a yearly loss of $50,000 in revenue. For a risk, you bang that loss of $50,000 against its probability, say 10%, and the expected value of the loss becomes $5,000.

But the rest of the analysis is exactly the same.

So your challenge is to arrive at a probability of those inconvenient, small issues that may occur, the impact of those issues, the cost of fixing those issues, and secondary risks created by fixing those issues, and then compare that with the rest of your backlog and prioritize accordingly. You could arrive at a solid business conclusion that it pays to ignore them and just deal with them as they occur or you may learn it pays to go fix them and rid yourself of those minor annoyances. The answer is in your analysis and only you can do that.

Answer 4

I really despise risk categorization; it is usually yak shaving - it usually obstructs the conversation about how to address the risk.

In your case however, I think categorization and FMEA might be helpful.

If there are truly a thousand needles, randomly distributed, then your project is doomed. But in your question you hint that many of those needles are associated with a single cluster of code. If that is true, then it makes sense to

1. begin to track risks and issues that touch on that cluster of code.
2. Assess & quantify the cumulative cost of those issues against the cost of refactoring that code.

impactful vs rare is a standard ALE calculation. You've already done the hard part - identifying common origin of multiple issues. Now collect data to support an ALE & a decision about the best approach.

Answer 5

A variety of problems may be caused by only a few root causes. You might want to dig deeper and find those root causes for the problems. Such root causes are often systematic, i.e. related to your company's culture and structure, management style, maybe even values and principles.

You can investigate a couple of problems to see if there are common causes (in my experience there often are; the challenge is to find them and address them).

If you are able to work on the root causes, then there will be less problems in the future. One way to find the root causes is to do a five-times-why exercise in your retrospective. Other ways are to use Appreciative Inquiry or to self assess your way of working.