Hacker News Reader

Comment by tootie | Hacker News Reader

Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors.

The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in an agile way. Agile is the contract. But it's also a tough sell. 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. If you layer sprints on top of a fixed timeline, you're just adding needless complexity since your end state is predetermined and how you get there is irrelevant.

View on HN

I have almost never seen Scrum sold as magical by developers. Executives? Yes. Consultants? Yes. But developers?

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."

>I have almost never seen Scrum sold as magical by developers. Executives? Yes. Consultants? Yes. But developers?

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

Seconded. I've also seen it promoted by developers who are in what one could call a "honeymoon period" of their careers. First or second job, probably learned programming at university so every task is an interesting challenge, SCRUM is their first agile methodology, they don't have enough broad knowledge about programming and the industry to become disillusioned and cynical. I've had such people evangelize SCRUM to me, with pride in their eyes, like it was the best thing since sliced bread.

I’ve noticed this, too. For some reason a junior developer on my team 2 years our of school was made into scrum master, and if we so much as sneeze there’s no JIRA ticket for it he starts whining.

It was heavily hyped by developers about 10 years ago. Now they've all given up because they didn't learn the right lesson.

it's really a victim of the developers who sold it as a magical process

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.

Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybrid waterfall/sprint methodology that mostly worked fine, but i suspect that was more to with the general culture and people involved than anything else.

I think no industry producing anything new ever found a working process to predict and keep the timeline. (If omniscience really existed, it would have more lucrative applications.)

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.

Absolutely. And I'd add that predictability is dependent upon not learning anything over the course of the project. To be predictable either you know everything that matters up front (which is only true for trivial projects with no competitors) or you refuse to learn anything along the way (with, e.g., a big-bang release at the end).

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.

? All the specified above endavours - usually run into what one could call the end of the map. Here be science! If you run into e.g. new material science because your goal stretched beyond the scope of what has been done previously, you can blame the engineer for not telling you that you will leave the boundary of the knowledge of a field- you can not blame him for the estimates beeing wrong.

Nope, never.

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.

> "it should almost never take longer than that" vs. "it will probably take that long."

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

Here's an article that explains the phenomenon much better than I can. It made its rounds in HN a week or two ago: https://erikbern.com/2019/04/15/why-software-projects-take-l...

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.

On the actual use and calibration of confidence intervals - https://www.lesswrong.com/posts/ybYBCK9D7MZCcdArB/how-to-mea...

AFAIC, the only thing that works with a fixed deadline is a variable scope. Which is basically a tenet of Agile.

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...

One thing about agile is that usually companies not only set fixed deadlines but also fixed feature set; which usually means lower quality.

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.

Exactly. Probably 90% of the burden on a successful agile project is in setting expectations with stakeholders for an iterative delivery without a fixed scope. It can be a tough sell but it shouldn't be. If you've ever done a top line estimate on a fixed scope project, you know it's just absolutely not possible. Why set a deadline you know with 100% certainty you're not going to hit? Just bake it into the contract and upfront expectations.

Yes, absolutely. Many times. I've done a bunch of projects that were tied to immovable event dates. The only way to deal with it is having very flexible scope. Typically, these have been more "creative" projects and not tied to a lot of critical functionality so we just make sure we keep our MVP quite small and treat everything else as iterative enhancements so we can cut off whenever we're out of time and still have something presentable.

DHH has a nice methodology that works with fixed deadlines: his basic rule is that features can be dropped/simplified, but deadlines must be met.

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

He's applying an old concept. The Iron Triangle has been in use since the 1950s.

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

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

This is true, but fixing the deadline and not committing to the scope requires clear communication by the project management / sales teams with the clients about it, and this is rare.

> Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process.

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."

There are in fact two kinds of Scrum (or rather, Scrum implementations), both of them compatible with the Scrum guide: ‘Left to Right’ Scrum (backlog-driven, implementation-focussed) and ‘Right to Left’ Scrum (goal-oriented, iterative).

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...

"Right-to-left scrum" seems like a hollow phrase made up by that consulting firm you linked.

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.

This logical fallacy is sometimes called No True Agile.

>> developers who sold it as a magical process

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!

>Scrum simply can't be implemented as a purely developer process.

aka, WaterAgileFall.

aka WaterFail

Reply on news.ycombinator.com