I googled "scrum sucks" and now I can see a pattern described as an argument against the whole scrum/agile/whatever thing, which is already happening since we started adopting agile: we're consciously incurring technical debt and being allowed to create a mess out of the previously existing code architecture just to "get this ticket out of the way"

We're also refraining from acting immediately on negative user feedback on a feature just released, which I think can wear user perception of the company as a whole, all because it's "not the focus" of the current sprint

This happens when Product is given too much control over the tickets prioritizations. At least - when looked at in the short term.

The real long term root of this - is the delivery team inability to give correct estimations. Those should include fixing the tech debt inherent in every ticket. Do not fall into the "just this little hack, and we can deliver!" routine. Design it twice, implement once, write good tests, Qa It once.

refactoring should be implicit with each ticket if you always leave the code better than when you touched it.

If it makes a ticket a 3 then it makes it a 3.

Agile isn't about pushing poor code. it's about getting quick feedback.

But then if you don't/ can't act on it, I don't know, I still prefer scrum over waterfall for one reason. I don't want to scroll back and forth all the time on a 40 page requirement doc and still end up misinterpreting something. lol

Lemme start with one thing first....

Technical debt doesn't exist.

Just delete this word from your brain...

If someone uses it, give them the death stare and ask them what they mean *precisely*.

The word never had a real meaning... But it is used nowadays nearly always when someone tries to "explain tasks no one wants to do and thus we say technical debt so no one assigns time for it so everyone is happy and can continue to bitch and moan"...

I mean it.

There might be a lack of quality assurance, e.g. missing test coverage.

There might be scaling problems, e.g. a badly implemented REST API causing excessive resource usage...

There might be a lot of things which could be explained precisely even to a non technical person....

But there is really no technical debt.

What you describe is mostly mismanagement.

Which is pretty common, especially when doing agile.

Cause it means nothing to do agile when no one critically analyses and improves the workflows implemented.

Which is usually the number one thing everyone does wrong in SCRUM.....

If a ticket cannot be solved in the necessary time, then we have a problem. Dailies are not status meeting. They're meetings to provide a transparent feedback.

If a ticket cannot be solved, then that would be the proper channel to say: We need to postpone and reevaluate the ticket, cause this will not be solvable this sprint.

What one shouldn't do is try to make the ticket work in the estimated time by just "shitting out code that's known to be diarrhea".

Thats not what SCRUM proposes either. That's mismanagement and miscommunication - and has nothing to do with SCRUM.

Acting upon negative user feedback has also nothing to do with SCRUM at all.

If there is a high priority bug, it should be fixed. Again, that's what dailies are for. Transparent process. We have a high priority bug, we need to reevaluate the sprint - what can be postponed, who can fix the bug most efficiently?

I'm not an advocate for SCRUM by the way.

But I do get really pissed with bashing workflows.

If a workflow doesn't work, ask why.

Research where the problem lies.

Fix them.

If people don't want to change, then that's not a workflow problem. :-) ;)

That's stupidity.

Tech debt is a debt incurred for releasing a feature sooner than you should. Side effects can be an architecture flaw, inefficient code, undiscovered dead code, or etc. It is a real thing.

For example our main competition hinted that a hot feature was coming. Their marketing had a bunch of “we are going to be the first to give you this” and “they aren’t going to be playing catch up” messaging. So we wrote the same feature quick that they hinted at, quick, dirty, and a bit unstable. Then we released and announced it two days before their scheduled press release day to fuck up their event. We then wrote tickets and cleaned it up for a long while afterward. We took technical debt to have a feature sooner. Then we paid off the debt.

When management introduce "agile" it is mostly an excuse for the exact opposite, like forcing people to attend daily morning meetings where they can repeat what should be obvious from looking at GitHub, Kanban board / ticketing system or whatever tool is used to track work progress asynchronously.

@IntrusionCM Tech Debt another ways of saying: "we are cutting corners", or "it works! but....".
It is even a way to describe wrong architecture, that can't handle the unexpected load.

In my experience - these corners will be cut, when the team is under pressure to deliver "Something", mostly because the Product/Sales gave the client a "delivery date".
Agile does *not* work well with delivery dates.

@magicMirror @irene

What you're describing is simply mismanagement.

@irene

Is this debt in the room with us now?

What's the account number?

Who's the accountant?

What's it's value?

What's the interest?

For anyone thinking I'm joking or satirical - I'm not.

The term is extremely misleading, has no concrete meaning and is simply made up bingo bullshit.

There is no "debt".

There is action and consequences.

If you write diarrhea code to meet a deadline cause management doesn't do it's job right - then that's mismanagement.

Debt is real and is always an abstraction. It means you get something that you can’t afford but incur additional cost and risk.

A financial debt has an interest rate linked to some value like prime rate. A debtor can’t know how much they will pay over the course of the loan at the time it is taken. That debt is taken because there is hopefully more benefit than enduring risk and repayment cost. The balance is in the financial systems of a debtor and lender.

Technical debt works in the same way. Business gets technology that they can’t afford for increased risk and repayment cost. The balance is in the repository and the system used to track the debt. Risk is generally related to public facing failures and reputation.

If a business forgets to track and pay a financial debt they are in trouble. If a business forgets to track and pay a technical debt they are in trouble. That is where mismanagement is an issue.