Ticket-Driven Development: The Fastest Way to Go Nowhere
Posted by self@reddit | programming | View on Reddit | 43 comments
Posted by self@reddit | programming | View on Reddit | 43 comments
flooberoo@reddit
The article mentions sprints, but where are the planning sessions? Where are sprint reviews? The purpose of those are exactly to solve the issues mentioned. How can you not know what you are building and why, after having extensively discussed just that for hours?
Gwaptiva@reddit
Everything must be a sprint or your staff is taking advantage of you. If they're not always under high pressure, you're doing it wrong
/s
flooberoo@reddit
Sprints do not imply high pressure unless you chose so.
postmodest@reddit
They don't call them "strolls"....
LiNGOo@reddit
If you chose to misread the framework, that's a you problem lol
flooberoo@reddit
How does the word "sprint" imply high pressure?
postmodest@reddit
Explain to everyone in the room what the common non-programmer meaning of "Sprint" is so we may discuss whether such an event puts more or less pressure on the participant.
flooberoo@reddit
Running quickly.
When I go for my evening jog I often sprint (interval training), yet I don't feel particularly pressured while doing so.
Pressure only comes into the picture if there are negative consequences related to the result.
The act of sprinting does not result in pressure. Receiving complaints if the result is not satisfactory may. But that has nothing to do with sprinting itself, and everything to do with bad management.
JodoKaast@reddit
So you're saying you don't sprint for the entirety of your evening jog, right? Why not? Would sprinting that much, for that long, put too much pressure on your body?
flooberoo@reddit
It would. So I take breaks. Just like I take breaks from work. So I'm not sure what your point is?
Also, is it a perfect name? No. Does the name make it completely impossible to understand the concept? Also no.
_mkd_@reddit
the point ---> 📍
🌒
✈
☁☁☁
you ---> 🧍♂️
flooberoo@reddit
Do comments like that make you feel good? Does it help you relax after coming home from work you don't actually enjoy doing? As long as you take it out on internet strangers and not your loved ones it's all good.
cmsj@reddit
The point is that we don’t do a sprint and then a jog, we just roll from sprint to sprint to sprint. Try sprinting for your entire evening jog time/distance.
The choice of word is mostly irrelevant, but it was still a dumb word to choose.
Xemorr@reddit
Now suppose instead of interval training, you were being chased by a man with a knife and have to sprint to maintain your distance 😂 that is closer to the colloquial understanding of sprinting
flooberoo@reddit
Really? Maybr it depends on where you are from. Where I kive doing sports is much more common than being violently chased, but I can believe not everyone is equally privileged. Perhaps the authors of e.g. the SCRUM manifesto are in a similar position to me and did not realize sprinting implies violence?
welshwelsh@reddit
The problem is that development has been specialized and siloed to the point where nobody understands the whole system they are working on.
There will be a tester whose job is just writing tests. But because they don't develop features, they don't understand the system they are testing, and they never talk to business stakeholders so they have 0 clue about the purpose of that system.
The same is true to some extent for everyone, from the devops engineer to the UI developer to the business analyst.
Everyone has their tiny, hyper-specialized place on the assembly line, carefully designed so that anyone can easily be replaced by an offshore resource that only understands a single technology. Nobody works on the entire system end-to-end and there is nobody who both talks to the end users and also works on development.
The result is that nobody cares about the product because nobody really understands it. Nobody has much to say during planning because nobody understands how the business objectives of the project relate to their work.
Quexth@reddit
That sounds like your experience.
There is another end to the spectrum, everybody does everything. Which is not fun either, depending on the situation.
popcapdogeater@reddit
I've worked in both environments, if given a choice, I'd rather be in the one where my coworkers at least have an idea of what I'm talking about if I ask a question.
At my current job I can ask 10 people "Hey what task generates this report file? *crickets*
flooberoo@reddit
I'm not sure I follow. I, personally, know nothing about front-end development. I would not be able plan a frontend feature. But I still care about the frontend. Why wouldn't I? I still want to come up with a nice interface towards it, so I can help my colleagues who know more about it.
Specialization only leads to silos if you choose to do so. If you don't care about the product, why do you work on it? Why not find something you do care about, that makes you happy?
who_you_are@reddit
It is similar (yet different) for my situation as well.
We do integration with APIs. Our team tries to get an end user/high access to whatever platform we import/export from so we can check data on the platform (or/and trigger import/export). We don't know the inner of the platforms, we learned the end user platform by ourselves. We are able to do a first triage if anything can be on our side, or on the otherside.
For example, the otherside often have cache issues for end-user, but the administration portal has none of them, so just checking there is often enough.
Which help since we are usually the first one in the chain to be blamed and at the end, the client just wants its data at the end. So the easiest we can confirm or deny something, the easiest it is to, at least, pinpoint the team that needs to troubleshoot any issues.
We also don't need to wait for another team just to check in their platform something silly we can already check.
SkoomaDentist@reddit
It’s agile so you’re not supposed to plan beyond the next sprint.
flooberoo@reddit
Nonsense. The product backlog is a thing that exists.
Drevicar@reddit
It doesn't exist if I refuse to look at it or acknowledge it.
SkoomaDentist@reddit
In theory.
In practise agile very often means there is next to zero long term planning.
flooberoo@reddit
But that seems to be true regardless of what you do in most cases. Bad project management has always existed, and will always exist. Just "agile" is maybe too difficult for many organizations, as it requires taking more responsibility than many are up for. Just because no one is "forcing" you to do a good job does not mean you are not allowed to do it.
floppsb@reddit
Just sounds like this person has a terrible team… fixing problems like these are one of the purposes of sprint retrospectives. If your team isn’t implementing suggestions from the retro, then it might be time to look for another team.
vaalla@reddit
Or the team cannot fix the issues raised in retro, worked in companies where my team had to work with partners and other teams and all the issues we raise were valid and everybody knew about it but nothing could be done.
In my experience most retros are a waste of time and maybe a self pat on the back for the team, but cannot change important issues like asking a partner to drop support for old hardware, or partners to improve performance to crappy code, or ask the company to change a shitty ticker system.
The better way is to raise the issue when you observe it and ralk with the team then, maybe on chat, maybe in person, no need to wait a whole week until the next retro when nobody remembers the issue where the context.
Hypergraphe@reddit
Jira driven developpement aka blackhole developpement.
average_turanist@reddit
Tickets are the best way of management and development. I tried the other way like waterfall and it is soul crushing.
Big_Combination9890@reddit
Yeah, nice sentiment, but you forgot the most important point in your little bullet list there:
Because no amount of positive thinking and wanting to make the world a better place, will change squat, when devs cannot do these things, because it could cost them their job.
Schmittfried@reddit
It’s absolutely in most developers‘ power to do additional improvements when working on tickets. You don’t have to and shouldn’t ask. You’re responsible for the code, you decide what technical steps (including refactoring) are necessary to finish the ticket.
And at least for seniors it’s also expected and ok to push back. Sure there are toxic environments that don’t allow this, but in that case the best course of action is leaving anyway. Companies/managers that don’t want sycophants will allow you to push back and even let themselves be convinced. You just shouldn’t get scared if they don’t take your opinion at face value immediately.
ConnaitLesRisques@reddit
But then your performance is compared to those who don’t improve the code while working on tickets.
rusl1@reddit
100% this. I've been in this context and it was the most depressing experience as a passionate developer
Big_Combination9890@reddit
Sure, but here is the question: If there is no incentive to do so, why would anyone?
When the people advancing in their careers are the malleable yes-men who just worry about meeting whatever idiotic KPI some management consultant sold the company, code quality be damned, why would anyone take the heat, risk his career, lose out on money, just to keep the pile of shit running for one more year?
In some companies, sure. In many others, the moment they do that, some "manager" will try to replace them with an intern and "AI". Which won't work of course, but again: Why would anyone take the heat for that?
So, my answer remains:
No.
This problem wasn't caused by developers. And the onus to fix it sure isn't on us either.
philnelson@reddit
Somehow it’s never the boss or the system but the fault of individuals lower in the ranks, as per usual.
viktorzub@reddit
Really usual?
Supuhstar@reddit
... The project manager, staff engineers, and software architects??
When the devs are working on dev work, the project manager is steering the ship and the high-level engineers are meeting and designing…
also, sprint retrospectives and planning sessions…
Is this person just face-down doing ticket after ticket, not thinking, not looking around themself, and assuming everyone else everywhere else does that too?
bduddy@reddit
What part of this has anything to do with tickets?
techdaddykraken@reddit
Tickets are just another hierarchal way of organizing information.
Whether you use ‘tickets’ in a Kanban board, or ‘tasks’ in a spreadsheet, or ‘jobs to be done’ in a project management software as subtasks, or you simply let tasks develop organically from meeting notes during daily scrums, or you call them ‘features’ or ‘user stories’ or ‘functional requirements/non-functional requirements’ or ‘software specifications’…
At the end of the day you need a method to organize your information and categorize it.
Tickets work well because they are designed to encapsulate the critical information and allow you to view one at a time sequentially, while still being tracked globally, and the ticketing system typically integrates with other CI/CD pipelines for ease of use.
The issue isn’t the tickets, or ticket-driven thinking.
The issue is using tickets as a meaningful metric for tracking productivity.
All tickets are not created equal. Even when you use systems to standardize your tickets, such as planning poker, where each ticket is prioritized and categorized as a group, you still end up with tickets mislabeled, or not broken into the granular detail necessary, or assigned to the wrong team member, or not necessary to begin with due to architectural oversights. And that’s not counting the fact that some non-zero amount of tickets at the beginning of development will cause future tickets in the form of refactoring and bug fixes.
Humans are error-prone creatures. Unless you are paying them well enough to have zero errors, you must accept that there will be errors. Attempts to line-item human productivity have never gone well in the history of anything, without being coupled to extravagant amounts of money.
I can promise you that every single ticket would be completed on time, with zero flaws, if every developer was making 2 million per year.
That point shows that the issue is management, not the tickets or how they are organized or tracked.
TheMaskedHamster@reddit
I agree with the whole thing, but I would call that ticket driven management.
Tickets are a great way to plan and track things, especially for remote teams. But anyone above a direct manager should not be tracking individual tickets, because they are completely meaningless from an upper management perspective. And a direct manager should have the experience and direct instruction not to count tickets, because they are are almost never comparable.
If upper management wants to track the status of something, let a direct manager give them an epic or a specific issue ticket. They want metrics, but the act of using metrics to track individuals is almost always wrong, and if it wasn't wrong before you used it, it will be after you start because then the metric becomes the goal.
anengineerandacat@reddit
Most of these questions get answered in planning sessions, if your getting tickets without any form of planning session or at the most minimal a three amigos you have an issue.
I lead a small team and whereas for business reasons the entire team isn't involved in the story planning and sequencing (because there might be confidential projects still deep into planning) before we start our sprints we always have a quick session where we go over all the stories for the upcoming sprint and gather concerns / questions / additional technical details.
We also have a defined sprint goal, what is the business value we are providing this next sprint? This way it doesn't feel like we are continuously working on small units of work and instead are building to a broader feature.
For larger projects we often do a broader kickoff, detailing what the next N sprints will look like and ensuring all the engineering team is aligned.
Outside of that at a project management level you sorta want people just doing their work, whereas stories can be shuffled around budgets mean you have N sprints to complete the work and you need X points for that project done every sprint to keep the timeline.
Might not be true agile, but realistically speaking you can't churn on a solution forever only got so much money so there is some level of compromise.
cazzipropri@reddit
Finally someone said it, but I don't think they said it enough.
The kind of bureaucratization that ticket-driven thinking can lead to is A LOT worse than described here.
NullCyg@reddit
Your title is good. Kill the AI thumbnail