Nailed it.

My team's product owner is as much part of the team as any of the engineers. Her role includes balancing the need to deliver products with the need to build reliable and scalable software, and to make those arguments to other parts of the company on the team's behalf. Since we're all skilled professionals, we're able to trust each other to make good decisions, and if I say "we cannot proceed until we have done <necessary technical work>" then that is taken seriously and work is prioritised as required.

I'm baffled by the awful environments that people apparently work in where this is not the case.

A well-functioning team is composed of skilled professionals. If you are being asked to do something, it is because someone else has a problem that needs to be solved. "No" is an especially unhelpful response to that scenario. Other approaches can work:

- "No, but how about this alternative idea?"

- "No, this prerequisite is required. How can we make that happen?"

- "Not without causing these other problems – let's decide if it's worth the tradeoff"

- "No, that idea is fundamentally impossible. Here's why."

If you work in an environment where engineers are never listened to, then it's a bad environment. But similarly, engineering requirements are not the only ones, and it's important to realise that quite often an engineer doesn't have all of the required information to make the correct long-term decision.

Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.

Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.

I've never been in an environment where you could say no to the b.a.'s under agile either. And I've tried being more articulate as well and that just results in the same claims to your manager as "no" does that you're not being cooperative, a team player, etc.

I'm pretty sure after working several places that did agile that most of these "worked great for me" stories are made up.

I've never met another dev in real life who did something other than agile and preferred agile.

The process is there to account for the places where the people fail. If a requirement of a process is unfailing people then it’s not a valuable process.

That's just wrong. It's there for lots of reasons – to help avoid failures and surprises, to deliver sustainable pace, to help make estimations, to ensure a common understanding of problems and challenges… the list goes on.

Scrum doesn't require infallible people – it's just a tool to help avoid failures, which happen regardless of the skill of your team.

I’ve seen instances of all of the items the article claims being problems in practice. That was across a wide variety of teams & skill levels.

I’ve also seen no evidence in the literature or research that backs up your assertions.

I’ll concede some teams have benefited from scrum practices, but in the face of my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business.

I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum.

Why was Scrum added to these teams if they were already working? It's a tool to deal with problems. It's not something to use if another process is already working.

I’ve seen instances of all of the items the article claims being problems in practice.

I have found essentially the exact opposite of all the problems that are claimed to exist, and I've equally seen no research to confirm that they somehow destroy teams.

my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business

My experience directly contradicts that. Every Scrum-ish team I've worked with has had a pretty steady pace of development and produced good software. Some other processes have worked too; the worst I've seen are fake-agile-actually-waterfall processes.

I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum.

There's no such thing as 'real Scrum' so I won't use that defence. A good process is one that works for the team and company. Scrum is not a universal solution; for extremely high-performing teams it's probably overkill; for bureaucratic teams it will crush everything. It's just another good tool to use where appropriate.

But nothing about the process fundamentally change the problems with software estimation. So in cases where teams are delivering rapidly at high quality but unpredictably, scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.

I'd argue quite the contrary.

> scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.

So weird. The "paperwork" tends to make bad project managers all too transparent.

There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation).

Instead scrum attempts to track a made up velocity number by using any number of known to be inaccurate estimation techniques. It then gets hyper focused on breaking down tasks into small enough tasks that the velocity number stays constant, all while forgetting about the real desire, the quality software the business desires, delivered to paying customers. At that task, scrum has proven to be no more predictable than any other technique.

An enlightening exercise for any project manager is to go to a sales team and explain what you are delivering in a given sprint. Almost always, they won't care at all about that, and will instead ask for when some 'major epic' thing will be done, at which point you won't be able to tell them with any more certainty than if you'd just guessed.

Thats the best case. The worst case is that all that work you put into showing transparency around velocity ends up being used against the teams working on the hardest and most innovative projects in your organization. Their velocity will be all over the map while the maintenance teams will look good. You'll have convinced the leadership of the organization that velocity is a real number to track (cause you spend so much resources tracking it) and the incentive structures will reflect it. You just made it worse for good engineers to join the teams solving your hard problems.

What methods would you suggest for software estimation then?

Invest in going fast, reliability & figuring out priorities. There are lots of agile methodologies that abandoned the estimation step for the reasons I mention (fdd,rad,dsdm).

If you don't know what values scrum brings over for example traditional waterfall, then the scrum handbook is a good place to start to learn.

If the process is just as often implemented incorrectly as correctly, that is a failing of the process. And in this case that is the most damning thing you can say about scrum. More often than not, people do it wrong. I'm tired of that excuse.

The companies I have worked on who claim to use scrum does not suffer from the issues OP brought up. So I question your statement. I also have >20 years experience.

> If the process is just as often implemented incorrectly as correctly, that is a failing of the process.

That's bs. That would be like putting a tractor driver in a Cessna and when the plane crash clamr that Cessnas are inherently unsafe to use. Yes, scrum requires buy in and some basic level of competence. If one or both of these are missing in an organization and they still say they use scrum then that can hardly be blamed on scrum.

Or to give a much more serious response : this article seems to be very unprofessional, about trying to defend unprofessional behaviour as "normal".

The scrum guide talks about roughly 1hour/week for the scrum team to show stakeholders (such as upper managers and customers) what has been done. Any engineer can at any time reach out to people in the company to demo what has been created, if there's interest.

So I'm not sure what point you're trying to make with starting your own company if you want visibility outside the team.