I agree that fixed-scope contacts cause a lot of problems for Agile approaches. However, they also cause a lot of problems for non-Agile approaches. If I have to deal with supposedly fixed-scope situation, I'm going with and Agile approach.

There are two basic cases. One is that scope is truly fixed (which is rare). In that case, having a new releasable version every week with highest-priority features first is excellent risk management. When the date comes, you'll have something to ship. You also get to continually validate and improve internal processes, so you're more likely to be using the time available effectively.

The other is that scope was fixed in the contract but is in practice variable. So every week you deliver something to the customer. Every week you build trust. And every week you encourage them to do tests, deploy early, anything so they start getting value. At that point they get user and business feedback, and come to you with changes. That's the point where you start shifting from fixed-bid to time-and-materials. Maybe you keep to the same budget, but now they're getting more for their money. Maybe they look at the backlog and say, "Wow, there's still lots more value to deliver, let's keep going."

In many places, especially smaller ones, project managers are also developers (or lead developers etc), and they often drink the Scrum kool-aid.

Developers may advocate small-a agile, but I have never heard of an actual developer pushing for Scrum, SAFe, or any of the name-brand "agile" methodologies, that come with expensive consultants and certifications and "coaches" and conferences and a whole ecosystem around them. These are things for project managers for the benefit of project managers who see project management the main deliverable l in and of itself. The same with JIRA actually, it's not a software development tool, it's a project management tool, sold to the same people who previously bought MS Project. These things are all overheads in the software development process, not enablers, as another poster says, the goal of most organisations is not to be effective at their stated mission, but to maintain their internal power structures.

Developing new aircraft, building a new ship, building a custom-designed bridge (most of them are) are processes that often run out of time and / or budget.

If you want predictability, you want repeatability. But in software all reliably repeatable parts become automated away.

But I think good projects release early and often precisely so that they can learn as they go. At which point predictability goes out the window.

I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the distinction.

This sounds like a much better way to estimate. Do you have any links to content discussing this?

I haven't seen a good way to turn the concept of "it should almost never take longer than that" into a concrete process. I've always seen it as a gut check, often implemented as "take your initial estimate and double/triple it." What I actually see is that a lot of teams implement that but walk back the doubling when the business/PM delegation persistently asks for more in less time. Only in really engineer driven cultures have I seen engineering teams successfully push back.

The alternative is some sort of sub-iteration hybrid where you attempt to fix deadlines for much smaller units of work and constantly revise.

This is OK for some industries. But 2/3rds of a car doesn't quite sell...

That in turn means technical debt; which puts future deadlines and feature sets at risk.

Since in SCRUM as a team you try to not compromise on quality the only way out of this is to push back on deadlines or feature set (or both).

So instead of blindly executing orders; the development teams can push back on deadlines.

Most of the time these are actually negotiable. Even the "hard" deadlines....

It doesnt mean the dev teams always win however they are better equipped to inform "management" about the consequence of the deadline.

https://www.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/00628747...

https://en.wikipedia.org/wiki/Project_management_triangle

If time is fixed, then scope and/or cost must change.

Even if so, that would be in itself a failure of Scrum. A process that works only sporadically and only with exceptionally well organised groups ain't really all that much.

> It requires a high degree of trust to say "we'll pay you $XM in exchange for X sprints of whatever we prioritize with no fixed end state" but that's what you need to be agile.

...no? It requires a well-defined end-state, and that includes not defining the irrelevant. It's not really "give me $XM and we'll deliver anything from accounting software to a really nice puppet."

Unfortunately Scrum is too often explained and implemented that first way, leading to the anti-Agile feedback we see on HN with some regularity. The second way is much more compatible with complementary tools such as Lean Startup and Kanban and I wonder if this (to me very welcome) non-exclusivity explains why it is less talked about.

[1] https://blog.agendashift.com/2018/07/04/righttoleft-works-fo...

From what I can tell, it has all the meaninglessness of an empty buzzword used primarily as a method of trying to engage people and give an opening on selling their services by stating "oh if you don't understand the difference sit down with us and let us show you how different and better it is."

It looks like if scrum doesn't work they call it "falling left to right scrum", and if it works it's their "brilliant right to left scrum".

Even by their own definition they both have a backlog that gets prioritized and selected each 2 weeks into a sprint backlog, and executed during the sprint.

The rest is just hand waving. "One is goal focused vs the other is backlog focused. Oh yeah but we do put our goals in the backlog." So they're both backlog focused then? The only thing they're really sayings is "When prioritizing tasks, make sure they accrue to something and aren't just random work." Which is both obvious, and of course too simple to write and sell a book about, so instead this whole other terminology is made for it.

Thanks for sharing the link though.

If I ever find a developer who can sell, selling is not a developer's USP in general, there are exceptions and I would hire those exceptions instantly!

aka, WaterAgileFall.