Quality vs productivity

What does your DoD say? Does it include unit tests and refactoring?

Has your team communicated why it's important to write unit tests, refactor to remove duplication and encourage code reuse?

Is there a way you can measure the cost of the existing technical debt in the existing code base and it's effects on quality and velocity?

The DoD should also reflect the quality standards of the wider organization. If the team simply did what the PO was asking, would they be in breach of those standards?

Yes, we have DoD which says that story is done when unit tests are passed and all needed refactoring is done. But PO asks team to make an exception in this case, "because Scrum and DoD is not a religion and I am asking you for few lines of code". We fully agree that all new features must stick to the DoD. But here PO says - it's not a feature, it is a bugfix (client's ip is not correctly recognized in the system log, because of the proxy created by another team), you should fix it, I won't pay for it as much as you want.

I feel that as a scrum master I should be against such exceptions, but this few lines of code is so important and I can not imagine to pay for it thousands $$$ - I could code it in one hour without tests and refactorings :) So as I said - I can undestand both developers and PO :)

Is there a way I can measure cost of existing technical debt? No, I I think I don't have such a measures. What kind of measures do you think?

Scrum master should talk to PO and explain why 1000 lines function is a bad idea, if indeed it is a bad idea. If PO thinks it is not that bad, maybe you can work with them, make it more small increments rather than one big bang refactoring move. Instead of 50 points in one go, maybe you can split refactoring into smaller stories, of couple of points each and then include those in sprints, over several sprints you should have those worked out. Split one 1000 lines function into 100 ten lines functions and write tests for them is not that complex, and it is a good start. Next sprint move them into classes, next sprint make blah, blah, blah... you get the point.

Send the Product Owner to PSPO training. He is sacrificing quality for short term wins, clearly he doesn't understand the role of Product Owner. :-)

If the PO doesn't understand the principles of technical debt and code maintenance, you should find a way to get through to him and teach him.

But if he does and doing it his way doesn't violate the DoD, the developers should just add the two lines of code and be done with it.

Developers often overlook the fact that the main purpose for the existence of commercial software products is to generate revenue. From the business perspective, it just might not be acceptable to spend 400 man-hours and $10,000 on something that could be done in 1 hour.

So the bottom line is: if the problem is the lack of knowledge and education on the part of the PO and the senior management, you should educate them. The power of the Scrum Master is in skillful and crafty persuasion.

But if they understand the long term repercussions of their policies and insist on doing it their way, well, the business that pays the bills and will always have the last word. If the developers don't like it, they need to get over it or find a different company to work with. Sad but true.

Hi all,

One solution could be (?) :
1. add the 2 lines of code. The technical debt is increasing a little. It is a fact your PO Must know. Your client should see a minor change done in a minor time.
2. tell the PO the technical debt Must decrease.
3. plan the necessary work to decrease your technical debt. Even in several sprints in parallel with other tasks (?).

Inconvenient : the work will be done "twice".
Advantages : client OK, PO should agree with this, dev team should understand this, Scrum won't be called into question.

Regards,

Max

Hi,
I agree your PO tries to trade quality for time. That is not possible.
Long ago he has lent functionality, because he wanted a feature fast. What he didn't take into account is the interest rate of 400%.
If a bank offered him money with this interest rate, he would never lend it.
Now he has a high debt. His suggested solution is to lend more money, with the same interest rate.
A bank would never lend him money again given his credit status.
This is a rare case where there is a simple answer: The developers are right, the PO is wrong. The SM may never let the PO trade quality for time.
The only exception would be if these two lines would safe the company from bankruptcy.

I think we need to find the root cause of this argument:

1. ask the developers why the code should be re-written in terms of performance, stability and maintainability
2. what will be changed if we add these 2 lines of code ( the impact of the possible technical debt)


at the same time, you may remind the role and responsibility of PO with him, so that the dev team can have their autonomy in the technical decisions in the future.

My 2 cents

The PO gets to say WHAT he would like, but he does not get to say HOW they dev team get there.

I agree with tim. when I rethink this scenario, I was asking myself: Is this a gold plate by the team? who can tell which is more important: technical debt or time-to-market?

So PM probably should involve more stakeholders to have their feedback before make a rush decision.