Hacker News Reader

Comment by shados | Hacker News Reader

Scrum is a specific implementation of some vague overarching concepts. Of course it's going to be prescriptive, that's the point. Else you're just doing "agile".

When you bring a prescriptive implementation, you can then leverage learnings from many orgs over many many years to handle all the edge cases instead of reinventing the wheel.

If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.

I'm no fan of Scrum, and rather use almost anything else, but that doesn't change that there's significant value in using systems that are mostly figured out and "work". Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. At that point you're better off just doing your own things. Which is what folks do, they abandon Scrum and do agile their way.

View on HN

If you do "Scrum, exactly", then when things don't quite work out, being "on your own" is the best case scenario. Worst case is that someone yells at you and blames you because Scrum Objectively Works so it must be your fault.

I see no reason to believe that Scrum is a tightly tuned machine that must be precisely run to work at all, and any deviation from it makes it fall apart. In fact, if that is the case for Scrum I'd consider it a fatal objection. I don't believe the effectiveness landscape for project management techniques is shaped like that, I don't believe that the effectiveness landscape is a black pit everywhere just around Scrum only for a sudden spike of effectiveness to exist precisely where Scrum is located, and if it were shaped like that, I don't believe in the capability of anyone to have found and proved that spike. Since the only practical algorithm to explore this landscape is gradient descent, anyone carefully and thoughtfully exploring this landscape should never have found Scrum.

Or, to put it in less mathematical language, the idea that Scrum is super effective but if you deviate from it just a bit it all falls apart is complete garbage.

Do real agile, all the time. Scrum's only useful for raiding for ideas, and I'm not particularly impressed with it for that purpose, either. But it's not quite literally bereft of good ideas. I wouldn't give its ideas any particular credence for coming from "Scrum!", through. I don't see a lot of evidence that it is specially deserving of respect. It seems to work for some people, yes, I don't deny that, but the rate at which it works for people is sufficiently low that I don't think it has any sort of special claim.

> Since the only practical algorithm to explore this landscape is gradient descent

That's why an algorithm was not used. Effectiveness has not been sufficiently analysed to be reduceable to a line on a graph.

> Do real agile, all the time.

People who call something "real" without defining what "real" is may be well-practised at sounding nice and emphatic in meetings, but without any detail it's hard to see it as anything more.

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right.

> If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own.

So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?

I think I'm expressing myself incorrectly.

Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At that point you can't just use a book to figure out next steps. You have to actually talk it out and use your brain to figure out what to do, because its unlikely your internal process has as much documentation around every single "paved paths".

It's also just a process. What does it mean not to find success here? If you ship broken software, it's unlikely to be because you didn't move the right ticket in Jira.

If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Don't get me wrong: I very much dislike Scrum and you'll never see me push for it in a team. My point was merely that if you take an "On rails" experience like Scrum, and tweak a few little things, you lose on almost everything. The books no longer apply. When the entire point of this particular process is basically the books and documentations, doing "Scrum but not quite" really kills the point.

> If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc.

Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.

If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.

It's like baking a cake without adding sugar; it's not really a cake anymore.

Sometimes teams don't understand practices and will discard them.

As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint.

I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value".

No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.

> If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse.

Dogma.

> It's like baking a cake without adding sugar; it's not really a cake anymore.

Nonsense.

> No doubt they weren't getting value out of them

This piece goes against this piece:

> , but that doesn't mean they were doing things well and they lost opportunity to improve as a group.

Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?

> For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.

Less interested in size, more interested in throughput/attrition.

> Dogma

> Nonsense

You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.

>Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?

Strawman.

I'm afraid you'll have to take my word for it that the team where just bad at it. They got better with coaching and even managed to see some value.

The values behind the process are more important. This team just weren't talking to each other about their own performance.

> throughput/attrition

Of staff or customers? Attrition is very low of both. Not sure it's that relevant though. 3 engineers have left in the last 2 years and one of those three is returning. Is that a good thing?

As for throughput, even the slowest of teams ship on a daily basis. Not sure what other context you could mean.

> You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.

Your statements are dogma. "You must've just done it wrong" is scrum marketing. If it works it's scrum, if it didn't work it must not've been.

> Strawman.

Go on then, explain? Your gripe was that your team, that you admitted didn't find value in retrospectives, didn't bring up process issues in retrospectives. Why would they? They didn't find them valuable. Probably because the things brought up in retrospectives never got addressed. Agile solution? Add more process. Again, this is dogma.

> Of staff or customers? Attrition is very low of both. Not sure it's that relevant though.

If I employ 500 engineers and they're all miserable and constantly leaving, and we're never adding value to our clients, should I be proud that I employ 500 engineers? What does team size matter? Value-creation and employee happiness are the metrics that determine the health of an engineering org. Which I chose to label as "throughput", or how much value is created, and "attrition", a proxy for employee happiness.

OK, but scrum is supposed to be a way of doing agile. And "we're going to do agile by a rigidly defined process" is an oxymoron. If your process isn't one of the knobs you can turn, then you aren't actually agile.

>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work.

I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team composition, output requirements, and their risk tolerance. Ticket systems existed before scrum, feedback loops existed before scrum, bug tracking existed before scrum, prioritization existed before scrum. Scrum just took all the things that already existed and put them in a very specific and somewhat restrictive process. It was eye candy for the execs who had no idea how their department worked, it was a cash cow for the consultants selling it. It's ok if you don't have anything else or you're dealing with high turnover or something like that, but if you have a mature department already, it's probably more restrictive than not.

Anecdotally, I've experienced the exact opposite. The company I work with had been doing waterfall development for 15+ years. We switched to agile using the Scrum framework. It wasn't smooth sailing the entire way, there were teams early on that struggled with adopting Scrum. Most often it was due to the team attempting to solve every retro issue by updating "the process", which only addressed symptoms instead of fixing underlying communication problems within the team. The other major hurdle was getting product to accept that a roadmap isn't a set of commitments but is instead a list of prioritized "wants". Now, we're 3 years out from the switch and most of those pain points have been removed. It's lead to massive improvements in quality, predictability, and overall happiness across the company.

I had the same experience, in a longtime waterfall company, that adopted Scrum, with significant pain points but it was still a world of improvement. The thing that the Scrum haters don't see is that its biggest benefit is invisible -- it's in what doesn't happen, in what Scrum avoids.

Scrum avoids the eighteen-month waterfall death marches that kill a department or a company. Scrum gets you thinking in terms of managing scope, of pacing deliverables, of thinking of a list of prioritized "wants" as you say rather than a dictated set of commitments. Scrum makes you approach development as it has to actually happen in the real world, rather than as a dictated plan that inevitably won't survive contact with adversity.

Of course it's completely possible to still mess that up, with overzealous adherence to process and ceremony and metrics. It's very possible to run Scrum as a set of perpetual two-week waterfalls -- and very possible that that's still a great improvement over two-year waterfalls.

The problem with scrum discussion is it's always compared to waterfall, particularly unyielding waterfall. Even construction planning, which is where waterfall came from, of has slips and adjustments. There were other methodologies other than waterfall before agile or scrum arrived. I went to college in the mid 90s and they taught that waterfall existed but a more iterative approach was actually used in practice. If you were doing immutable waterfall, anything would have been better, maybe including nothing at all.

Having said that, I'm glad Scrum worked for you.

Scrum is like a global variable or a goto statement. If used carefully it could provide benefit but is often thought negatively. Used by untrained or junior team members and projects spiral. Senior members shy away because of experience.

People say that about communism too. I'm not open to debate any of the tankies I know are on HN, but if a paradigm brings utopia if implemented properly, and misery otherwise, and there have been no known utopia-yielding instances of the paradigm despite repeated attempts, it's time to consider that maybe misery is inherent to the paradigm.

You're not wrong. Communism implemented perfectly would also work beautifully. It just can't.

The main difference here is that Scrum is not nearly as complicated to implement. Though the issue is the same. There's always someone somewhere who thinks the process doesn't apply to them and the whole thing falls apart.

I did work in one company that had a fairly well implemented Scrum, and it did work pretty well. I've never seen it replicated though, so for all practical purpose, it's exactly as you say: it's not worth trying because it only works when done perfectly, and that almost never happen.

Reply on news.ycombinator.com