[plughs]

There are certainly good reasons to make a team's progress visible. PMs/POs ( I'm never sure of the difference ) will want to know if a project can meet the release date. They will want to know that the need-to-have features are being worked on before the nice-to-have. I don't want to sat a team should work in total isolation.

I can only say that IME a team is going to be a lot more productive if they are able to own their development process. Good infrastructure, knowledgeable engineers, healthy relationships instead of competitive ones - that's what creates a highly productive team and highly productive engineers.

[lonelappde]

> will want to know if a project can meet the release date

The number one main headline takeway axiom of Agile is that this question is completely banned.

Agile is about delivering working software continuously, delivering whatever increment you get working at each timepoint, adapting to observed reality as it comes, and not having deadlines for specific features that might turn out to be impossible or harder than estimated.

[axlee]

That question is banned until a board meeting comes up and your owners asks you "What are your plans for the products the next quarter, misters CEO and CTO"?

If you babble around saying plans and deadlines are for suckers and that things will happen when they will happen, I am not sure they will keep paying you and your team's salaries for long. This new contrarian cargo cult of waving away any kind of medium-term planning or estimation is hurting businesses as much, if not more, as when all projects were waterfalled and timeboxed to death.

Yes, estimating is hard to get right. No, it does not mean we should simply get rid of it. Because engineers do not live in a little bubble of code: there is usually a whole company around them who need insight into what is getting built and when they can expect it. And anybody who believes that asking this question is too much or intrusive has never worked in a non-engineering position, or think of themself too much.

[BigJono]

The mistake here is making your measurements too granular. What happens is the board meets, long and medium term plans are made, etc etc. That's all good. Then what happens is every level of management calls in the banners and forces them to pitch how they align their teams and projects to whatever was pitched one level up. Somewhere along the process, you hit the point where planning stops being a positive and starts being a liability.

This process never stops, until you have some toothless PM slave driving devs because they're 8 levels removed from the strategic planning and they've pitched a 40-point/week development rate to their boss because they don't have enough information to do anything else. Anybody that tries to break the pattern is going to find themselves on the receiving end of an unfavourable performance review in any big business I've ever worked for.

There's a happy middle ground somewhere, where devs are given plenty of space to work but their output is still tied to the business's long term objectives. How you reliably reach that middle ground is probably a 8/9/10 figure question depending on the business.

[closeparen]

Anyone relying on a medium-term estimate about a software project has clearly never been near one.

A software system is an objective reality. It doesn't care what we want from it; it simply is. We can have intuitions about it, and use those intuitions to generate hypotheses about what will work, and ask the compiler / test suite to check them. But with a system of any real complexity, we're going to encounter surprising answers sometimes. We can't know how surprising, or how often, how long it will take to make sense of them, or what the ramifications will be for the rest of the project, until we actually get there.

It's not like we were producing useful estimates and then decided against it. They were always lies. Refusing to provide a medium-range estimate is finally telling the business the truth, that we have no idea. Instead we can tell you what we do know: the functionality we delivered last sprint, and the functionality we're going to work on next sprint. That is what you pay us for. The software actually delivered. Not bullshit promises.

But if you really do want a good faith, best effort forecast, then we need to plan the project in as much detail as possible upfront. Lock down the requirements, design the implementation, break down the work, and schedule it. Map out exactly what we're going to touch, so we can at least have a gut feel about how surprising it's going to be. That is waterfall. Own that, and do it right. Don't skip important steps and dress it up in agile clothing.

[satyrnein]

That question is not banned; story points and velocity measurements are mainstream agile, right?

[davidwf]

"Banned" may not be the right word, but I do agree it's the wrong question. Story points and velocity measurements are about giving a reasonable guess about what's "likely" to be completed at any given point in time in the future, with bigger error bars the further out you look. Agile projects don't "complete" so much as a decision is made to release at a given point, and everyone is happier with agile in an environment where there's an expectation of multiple, continuous releases.

[_y5hn]

Except they are used wrong and not required for agility. How many tasks per time is an observation, a hypothesis about usefulness of projection. Story points? Waste.