[kotlin2]

I get the appeal of ticketing, I really do. But ultimately, it's a form of control. ICs can't be trusted to figure out what to do on their own, and can't be bothered to talk their team for guidance. And management needs dashboards to track progress. I get it. But I don't want to work on a team where such things are necessary.

[chrisfosterelli]

Ticketing is a form of organization. If it's being used to control people, that's a problem with the org, not ticketing.

Simply having everyone do what they think is best and hoping they talk enough to sort that all out on their own is great until you have several people unsure what to work on, two people accidentally doing the same thing, and management upset because your features are taking twice or thrice as long as your guestimates.

Eventually you realize that for anything sufficiently complex you need to track what the steps are, who is doing what, and when each part is probably going to be done. You don't want to be a bottleneck, so you make it publicly available to the whole team. Then congrats, you've invented ticketing.

[prange]

It’s not as simple as that. ‘Talking’ doesn’t create a reference where you can see what’s been done yet, and of course people leave teams or get sick etc. so there are many reasons to want to see what was and wasn’t completed.

[eru]

On a small enough scale, 'talking' does work. So do post-its etc.

If kotlin2 sticks to those small enough scales, they can indulge their preferences.

Bigger organisations have more and more need for structure.

[prange]

Very true. My point was that you don’t have to use ticketing as a control mechanism - you can use it however you like and it doesn’t imply distrust. Similarly you can have an overbearing or micromanaging boss whether or not ticketing is used.

[Arcanum-XIII]

I'd wager that the original idea here is more akin to a list of task, with some info added on top of it. That's how I see it myself.

And yes, I need to have a status. It allows me to warn people outside the dev team if there are any outstanding issues or if we'll be able to soon release something. Communication is key when your team is not its sole customer.

[brundolf]

That's one form that ticketing can take, but I think it's way off to suggest that's all ticketing is. I've known even solo devs who got a lot of benefit out of a (simple) ticketing system.

[eru]

As your organisation get bigger some structure and bureaucracy is necessary and beneficial.

Of course, whether that structure and bureaucracy needs to be a ticketing system is a different question.