There Are No Bugs, Just TODOs

There's a great manufacturing-management book that regrettably speaks to a manufacturing context and not a project context and therefore applying it literally to our software projects would be a fallacy, called “The Goal”—and then the rederivation of the same principles for project management is in a follow-up book called “Critical Chain.” They are both weird in that they are textbooks written as novels and therefore you do have to roll your eyes a little bit, of course when the beleaguered manager follows the smart scientist’s advice his company succeeds and his marriage gets better, sigh. And why is it a he, both times? But if you pay the cost of these eye rolls you get some joyous moments.

For instance, your “panic mode” is discussed in The Goal (as “factories that seem to have three priority levels: Hot, Red Hot, and Do It NOW!!!”) and the emergence of those panic modes is actually diagnosed as a failure of those first principles. If you had managed differently, you would have been aware of your spare capacity, and this panic mode instead becomes a business problem of some sort—either you are not getting enough biz value out of your “SuperImportantEmergencyBugfix” project to justify continued investment of developer time or you are not getting enough biz value out of the EvenMoreImportant project or else you are getting enough business value out of both that it is time to expand your dev team so that your bottom line can get better sooner. But rather the panic is usually because the two projects are not profitable either way, and the company was willing to take a loss to build them up to profitability, but now revenues have gotten unexpectedly tighter and people are trying to fallaciously optimize on cost rather than marginal profit.

I do agree completely on "failed promise" and this is actually why I think the bug vs feature is flawed. I think "failed promise" is a great ticket type though ;)

There are obvious cases where I have nothing against what you say. But to use the analogies, "I thought the food would take differently and I don't like this one" is the more common type and it's the one that's murky to resolve.

The point here is that regardless of the reason, you want to tend to "customer is not happy" case.

I disagree. Who is sorting those tickets? Are they sorted arbitrarily or were the technicals considered? Is the ticket at the top feasible given the current state of the codebase/product?

In theory this would work, but it has the pre-requisite that whomever is managing tickets understands technology - which, in my 10 years in the field, has been quite rare.

I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if there isn't one, you should either ask until you get a good reason or stand your ground.

The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.

> Assign to a single person.

That doesn't work in teams with collective code ownership, ie all successful teams. But you can replace this with "assign to a single team" and i think it works much the same. The footnote to this says:

> For larger teams, that can be a team account, but in that case, it is team leader responsibility to go through all team owned tickets regularly and delegate them

But that isn't correct. You can have a team pull from a single queue of tasks assigned to the team as a whole. There's no need to proactively assign them to individual team members.

> Every team must have a single ordered queue of tasks.

As long as you understand that "tasks" does not encompass technical housekeeping tasks like refactoring, improving the test pipeline, etc, sure. The queue of tasks needs to be ordered by someone with customer/business/domain knowledge. There's a negligible probability that this person is also expert enough to prioritise housekeeping against feature work. But the development team itself can do that, no problem.

> I advise to start with the “Todo”, “Doing” and “Done” triad and only add more if absolutely required

This sounds good. My one thought is that there are usually different people who can say "i think this is done" (the development team) and "yes, this is done" (product owner / QA / etc), so i suspect todo/doing/ready/accepted as the minimal set. But you could find a way to make three states work, i'm sure.

> When people scream “this is a bug”, it is irrelevant what it is caused by

It's relevant to estimating velocity. If over a quarter, you estimated you'd do a hundred features, but actually did one feature and ninety-nine bugs, you should not plan to deliver a hundred features next quarter.

It's relevant to continuous improvement. If you're getting a lot of feature requests, great, carry on. If you're getting a lot of bug reports, not so great, slow down and see how you can improve.

> Saying “no” is hard, but without it, the issue system becomes an unmanageable mess.

We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world. As long as you know what the most important tasks are, it doesn't matter if there are an infinite number of less important tasks behind them.

> Yet I do believe this is actually a property of any job position: people rarely want their job to disappear. The moment you create a job position, it tends to metastasize.

Very strong truth! My third (?) law is that if you hire someone to do something, then that thing will get done regardless of whether it is actually useful. I am most often reminded of this law when dealing with security people.