5

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?

  • This is just another rant against non-technical management. The whole post is written with disdain for the non-developer. Businesses existed before software developers; it might be time to recognise that fact and also that developers cannot do it all. – Venture2099 Jan 29 '15 at 16:04
  • 1
    I am sorry if it sounds to you as a 'disdain'. Do you have any practical solution for situation I described? – G33K Jan 29 '15 at 16:41
  • I will be honest - I am not completely sure exactly what your problem is other than you feel pressured by a deadline. What specifically are you asking for a success story of? – Venture2099 Jan 29 '15 at 16:44
5

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.

  • Agree. And this is what I usually explain. But let me tell you what happens in management's heads then: "Oh, this guy says there are no free lunches, well, maybe, but perhaps he is not just strong enough to do the job, let me hire a new head of dev, maybe that will work". Surely better expectations management methods must be in use. Not necessarily stone soup though. (en.wikipedia.org/wiki/Stone_Soup) – G33K Jan 29 '15 at 15:38
  • 1
    @G33K Nope. The Scrum Master, Product Owner, and Development Team can share in the responsibilities of trying to educate management, but if you have bad management then it's time to look for another job. There is no silver bullet. – Todd A. Jacobs Jan 29 '15 at 15:41
  • The picture I described is quite common. So many 'another jobs' are similar in this sence. And you do not want to have a number of short 'another jobs' in your CV, do you? So, I prefer to deal with the situation. My question is - how can I do it better? – G33K Jan 29 '15 at 16:46
  • Sometimes it is better to jump jobs; educating management usually isn't in your job description and can often result in you getting fired or just losing credibility with the organization, but if you want one approach to dealing with it see my answer G33K. – WBW Jan 29 '15 at 20:45
  • Well, the reality is that every company except few are like I described, more or less. There is no point in keeping changing them. – G33K Feb 5 '15 at 11:08
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.

1

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.

  • @G33K Hi there, can you please take a look at my response? Let me know if there is anything else I can elaborate on or help with - – Jon Luzader Feb 3 '15 at 14:43
  • Jon, I think that will help with mild technical debt. It will not help when 70% of resources have to deal with technical debt to save the product. – G33K Feb 5 '15 at 11:12
  • Hi @G33K, if this is the case and it is this bad, you likely need to devote an entire sprint each release to paying down technical debt. For example, if you are running 2 week sprints and doing 5 sprint releases, size your goals appropriately for 4 sprints, continue to address a small amount of debt during each sprint, and towards the end of the release devote a full sprint towards it. Be sure to track stories on debt separately so it can be visualized, create a 'debt' burn down chart to display to the team and mgmt. – Jon Luzader Feb 5 '15 at 14:57
  • You also need to focus on re-educating the business on managing debt, and I think you can do this in terms of expressing risk, risk and tech. Debt are directly related - sorry for typos I am on mobile. – Jon Luzader Feb 5 '15 at 15:00
1

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.

0

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.

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.

  • Your examples do not address the OP's question on how to repay technical debt. – David Arno Jan 30 '15 at 12:32
  • Through the examples I am asking the OP to reassess his technical debt. It may be smaller than what he thinks it is. – Ashok Ramachandran Jan 30 '15 at 14:08
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.