Ticket & Sprint driven development leads to shitty software.
I won't bury the lead here because I too am the kind of person who scrolls to the bold sections of the article.
Using tickets to drive development discourages refactoring and the boy scout rule.
The boy scout rule is the idea that you should leave the code base better than you found it, like the rule boy scouts have for campsites. See some litter? Pick it up. See a poorly named, hard to follow function? Break it into pieces until it's clear what the function does, then give it a better name. This is all fine, but significantly harder to do on a team.
If you've worked as a software developer for awhile, the following sentence may be triggering: "Let's make a separate ticket for that." It's very common for software teams to end up working like this, where developers can't change anything without a ticket. They can't just see a problem and fix it. Any and all changes have to go through a pipeline of planning, refinement, etc.
This is good for preventing rogue developers from doing some huge refactor that makes the code base look completely different without running it by the team. But it makes it almost impossible to get small, incremental improvements merged. Here are some of the little day to day refactorings that should be happening but don't, because the developer sees them while working on a different ticket, and they don't warrant creating a new ticket:
- Renaming a variable, function, method, interface, trait, class, etc to be more clear.
- Extracting a function, method, or class to handle some reused behavior.
- Adding missing documentation, fixing typos, updating and/or removing old comments.
- Questioning where a piece of code lives, and moving it to a more appropriate file/module/class etc.
Basically, the team turns into a "feature factory", because that's what tickets are all about, adding features. You start to talk about Q4 being dedicated to tech debt removal when in fact tech debt removal should have happened constantly, in small increments, over time. A lot of tech debt is not a deficiency in developers, it's a problem with the system they work in.
So, what's the solution? Heck if I know! Imagine 5 mechanical engineers trying to fix 5 parts of an engine at once, then all doing their fixes at precisely the same time, while the engines still running. That's what working on a team of software engineers and deploying to production is like. A lot of discussion around software design patterns, effective decoupling and clean architecture is all based around this fundamental problem: creating software out of well defined, interchangeable parts. It's how you go from craftsmanship to mass production.
One idea might be to provide "zones" during a sprint. When you take a ticket, it come with a zone in which you may change any contained contained code to be higher quality while making progress on that ticket. No two developers should be assigned the same zone in a given sprint. Having a framework around this would encourage improvement. It's just a though, so don't take my word for it.
Working from tickets can prevent merge conflicts, manage priorities, and give non engineers insight into the project. Surprise surprise, it's a tradeoff.
If you find the solution to maintaining quality in software with a team of contributers, let me know :)