Team has to include 'the business', as in, voice of customer, features lens, in those tradeoff prioritizations along with what do we engineer, and what's the truth of where we are on the field, for delivering what satisfies the customer and our constraints. // Hat tip Rands in Repose.

As for "Ultimately it's not about trust, it's about accountability and predictability" that's precisely the characterization I reject. Accountability means you earn your keep by being effective. Predictability, well, milestones come and go, the software gets used forever. That's the predictability needed, which goes right back to effectiveness. You won't magic either of those in a Jira.

> As for "Ultimately it's not about trust, it's about

> accountability and predictability" that's precisely

> the characterization I reject.

How do you know if you're effective? Perhaps it's a difference from one company to another but I don't think it's unfair that my manager (and others dependent on my team's output) want to scrutinse my decisions, and the outcomes of the team.

Likewise, I can scrutinise the choices of engineers with weekly sprints, to ensure the goal is hit i.e. a timely release with flexible features, or a feature complete product that might overrun.

JIRA doesn't magic effectiveness, agreed. It can help show the truth of the decisions taken toward a goal and how work is progressing. I'm not advocating waterfall (any estimate of "this fully specced feature should be finished in two months" is pure fiction) but JIRA or other similar products can work to let managers know ahead of time, "We're not going to finish this by our initial estimated delivery date." That's a useful tool.

The budget lever is still available in limited forms e.g. do you devote two engineers from the team to project A or three? The point here is that the engineers have to be already up to speed on the codebase and already know how to work with their colleagues; and adding more on project A leaves fewer for project B, C, and D etc.

Also there is monetary budget. Can I solve an engineering inefficiency by throwing larger servers, or buying a licence for a relevant software service?

Maybe one could say that in the beginning of the project, one can use that budget lever, but not in the end (mythical man month)

Once the wheels are in motion you can only accelerate by breaking off sub-projects/teams... but if you're at a point where this can accelerate you, it means you were already slow-as-hell :|

I’m not so sure that’s true. I mean, it’s probably not worse but often I find that my gut feel of “it’ll take for weeks” is more accurate than trying to break the feature down beforehand and add up the parts. I’ve always said that the estimation process rests on the hope that if you break a big wild-ass guess into a lot of smaller wild-ass guesses, the errors will cancel out. I don’t think that’s always the case.

You forgot about quality. It can blow the other 3 out of the water.

You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!

"The quality level you agreed beforehand" is meaningless without some infrastructure and processes in place to verify it. And in practice, those infrastructure and processes are compromised at least as often as the feature set, the budget, or the timeline.

Budget = Resuorces / Time = Time / Scope = Quality

Timeliness has an equally direct impact on software value, but in this planning context it makes sense to distinguish what is delivered and when it is delivered.