How to repay technical debt still delivering features?

Question

The picture I saw far too many times over my career. A team of developers in a company driven by non-technical management, practising scrum, severely pressured to deliver points and features by certain deadline therefore having no chance to concentrate on quality or dealing with technical debt. Not many developers if at all understand what is going on in depth of code, tests coverage is not sufficient so any attempt of refactoring anything leads to bunch of regressions. It takes more and more time for a frustrated team to add a feature and then even more time to figure out why this feature broke the product in several places and how to fix it without breaking in further.

Management understands that something is not right and hires a new head of dev expecting him to bring improvements resulting in more features delivered quicker. It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features.

What is usually the best strategy with that? Are there any links on success stories?

Answer 1

Nothing in Project Management is Free

It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features.

You already know the answer: you can't create a bigger pie by carving it into more slices. Ultimately, a team has a finite amount of capacity. The Scrum Master's job is to referee the process so that everyone (including the Development Team and the organization at large) understand that the Product Owner must make choices in how it allocates the team's capacity.

The more bug-fixing and technical debt stories the team handles each sprint, the fewer feature stories it can do. Likewise, the more the team concentrates on features, the less time the team can allocate to addressing bugs or outstanding issues.

There's no free ride. There's no silver bullet. Scrum makes the cost of the choices visible to the organization, but doesn't make things cost less.

Answer 2

Here's a simplified, idealistic example of what is usually happening in this situation:

Management has Team A that they think has a velocity of say 100 story points/iteration.

Management thinks Team A can deliver 100 pts of business value stories each iteration.

In reality Team A is is always pressured to provide more and really they can do 90 pts of busines value while needing 10 pts allocated to defect and tech debt efforts. Management doesn't distinguish between these efforts however when looking at the team velocity.

Management has figured out the customer backlog is 1000 story points, so they plan that Team A needs 10 iterations to complete the project which fits within customer timeline. Really the team needs more like 11-12 iterations.

Now PO/PM doesn't want to hear this above problem, because the project is fixed scope,budget, and timeline so there are 2 places to stretch: Deliver a fully featured, lower quality product or make your dev team work for free (salaried employees love this ;). The PO doesn't want to negotiate scope with the customer; its easier to internalize this problem rather than work with the customer to find a solution.

As a scrum master here's how I combat this: I let the PO create a tech debt story that is worth 0 story points BUT I get him to prioritize it higher than some lower priority feature work. I do this during iteration planning where I have all the technical folks tell the PO that this tech debt REALLY REALLY REALLY needs to be addressed now or it will hurt the project big time over coming iterations.

At the close of the iteration, that low priority feature work gets carried over to the next iteration and the PO is forced to do some expectation management with the customer. In the meantime I have forced the team's velocity down from say 100 units to 90 units this iteration. I keep doing this over and over again until the team's average velocity is actually representative of what business value they can deliver while still getting to work on tech debt and defects.

The next time this team is utilized on a project, management has a clearer understanding that they should only consider a business value velocity of 90 units when committing to a fixed scope/budget/timeline project.

Answer 3

Quick Answer: During each sprint planning meeting, discuss technical debt issues and create a placeholder card in each sprint with 5-8 or so story points that will be used to address re-factoring. You can do this as well for releases.

This is a way to incorporate technical debt in your teams planning and the best way to describe it to management, is that it 'is a requirement'. During sprint planning, discuss the importance of performing this function and why it adds value to the business. Each sprint, set aside time within Sprint planning to discuss cards related to addressing technical debt and re-factoring.

Answer 4

Overall, I think the answer to your problem lies in more transparency, but to get that, I think it may help to re-frame your issue a bit. It sounds like there are two things happening here and I think there's value in looking at them separately.

The first is that the development organization needs time for things other than coding new features. This may be technical debt, maintaining their CI infrastructure, keeping up to speed on new techniques, or a dozen other things that go into maintaining a successful development team. Whether you allocate a certain amount of time in the sprint and do them on the back end or create stories/defects for them (I like this approach better, but some people don't) that is still work the team needs to do and should get factored in to how many feature-based stories the team can do. That allows teams to draw the lines on the dependencies for people who aren't familiar with the technical side of things. The PO then has to expressly say "I value this new feature over correcting that broken feature.

And that leads well into the second thing it sounds like your team is encountering: team empowerment. The team is clearly not setting the expectations. When a team takes on a story, they should be including reviewing the existing code, adding new code, writing tests, and refactoring (and anything else they feel is important to the story) in their estimate. I used to tell teams that Done on a story meant there was no more forseeable work that needed to be done on that feature. That means that if there are bugs that come up after the release, the story wasn't done. Again here, we loop back to transparency. If technical debt is really making it harder to deliver new features (which I fully believe; it's a common problem) then the team's velocity should be steadily declining. If it is, you can point to this as the cost of the current approach and the reason to change. If it is not, then either there's some dishonesty going on somewhere that is hiding the reality of the situation, or technical debt isn't really having such a significant impact.

Now, that's probably going to be a tough reality for people to accept. My best advise is to work with that new head of development. They brought him in to affect a change and he's going to have the most leeway in being disruptive to expectations and processes.

Answer 5

Try to articulate the business value of technical initiatives

Regardless of whether management is technical or not, it is good to question the business value of work that the developers want to prioritize.

For example, developers typically cannot wait to be on the latest and greatest versions of new software. However, many have found the hard way that waiting for a stable version is prudent. In some cases, we have skipped upgrading to a version altogether because it didn't have features of significant value to us.

Other developers come up with the idea of completely rewriting software from scratch.

• Getting support for a software system rewrite?
• How to deal as PM for a technical-only refactoring project

Read here about why Joel Spolsky calls it the "the single worst strategic mistake that any software company can make".

If after doing this due diligence, you are convinced that there is business value, then it should not be so hard to convince management.

And people who take pride in their work deliver high quality and avoid taking shortcuts even when they are under time pressure.

• Why do some people take pride in their work?

Answer 6

This has happened to our team. our scum master and product owner placed all the bug fixing 1 month before the product launch which is a no-no. Although we need to adhere to that despite of debates and arguments. Technical debt is really a pressure to a development team. Here are some things that we learned along the way.

• Always make sure that the architecture is being reviewed every now and then. A good and strong architecture will provide solid foundation for the product that you are building. at least someone must understand the overall flow and architecture of the product. Its also a big plus if that person has a good refactoring skill and good oop/design pattern skill.

• refactor whenever you can. Even a small refactoring effort everyday will add up on repaying technical debt.

• development team must work closely together and communicate frequently. we had an instance where two people solved the same bug because of miscommunication.

• try to negotiate to the po and sm regarding adding a week or two for repaying technical debt.