Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs.

You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.

I imagine everyone's capacity is different, but you wouldn't want anyone with a low capacity on your team, so that's moot. Frankly, there is no need to go beyond what you can keep in your head, unless your personal capacity is naturally limited I guess, because as soon as you progress in some way the world has changed and you have to reevaluate everything anyway, so there was no reason to worry about the stuff you can't focus on to begin with.

We traded properly working on problems for the Kafkaesque nightmare of modern development.

As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it.

Except in the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it.

The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.

And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers. It sounds counter intuitive, but agile is about autonomy and lack of micro-management, not lack of leadership.

If anything, the one thing those two things reject are “product managers” in lieu of “product owners”.

It is officially marketed as such, but in the real world it is always the managers who introduce it into an organization to get ahead of the curve, allowing them to sour everyone on it before there is a natural movement to push managers out, so everyone's exposure to it is always in the bastardized form. Developers and reading the documentation don't exactly mix, so nobody ever goes back to read what it really says.

> And agile teams are supposed to be self-managed but there’s nothing saying there should be no engineering managers.

The Agile Manifesto is quite vague, I'll give you that, but the 12 Principles makes it quite clear that they were thinking about partnerships. Management, of any kind, is at odds with that. It does not explicitly say "no engineering managers", but having engineering managers would violate the spirit of it.

> not lack of leadership.

Leadership and management are not the same thing. The nature of social dynamic does mean that leadership will emerge, but that does not imply some kind of defined role. The leader is not necessarily even the same person from one day to the next.

But that is the problem. One even recognized by the 12 Principles. Which is that you have to hire motivated developers to make that work. Many, perhaps even most, developers are not motivated. This is what that misguided ticketing scheme we spoke of earlier is trying to solve for, thinking that you can get away with hiring only one or two motivated people if they shove tickets down all the other unmotivated developers' throats, keeping on them until they are complete.

It is an interesting theory, but one I maintain is fundamentally flawed.

What you actually do is going to depend on the kind of project you're working on and the people you're working with. But it mostly boils down to just talking to people. You can get a lot done even at scale just by talking to people.