Scrum is fragile, not Agile • Hacker News Board

Re: Scrum is fragile, not Agile

#121

Post by tamrix » Mon, May 27, 2019, 1:41 AM UTC

beachy wrote: post #15

wpietri wrote: post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

Scrum won out IMO because it's an awesome word and conjures up subliminal images of brute force pushing obstacles out of the way, bringing success to the team. Execs can relate to it without even knowing what it is.

Scrum won because in reality not everyone is a wizz bang developer like your guys so make yourself out to be.

Re: Scrum is fragile, not Agile

#122

Post by [deleted] » Mon, May 27, 2019, 1:42 AM UTC

barrkel wrote: post #31

brightball wrote: post #22

Earlier quoted context omitted.

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…

[deleted]

Re: Scrum is fragile, not Agile

#123

Post by jnwatson » Mon, May 27, 2019, 1:42 AM UTC

Reading all the comments out there, there is some atrocious stuff people call Scrum. I'm not even a huge Scrum fan, but it folks seem to criticize what people do in the name of Scrum instead of what is actually in the process.

The TLDR of Scrum is simple: (product) management gets to set the priority of things every 2 or 3 weeks. After that, we see what got done and check to see if the priorities are still the same.

If the priorities are wrong, don't blame Scrum, blame management. If tech debt is increasing, don't blame Scrum, blame management.

There's no magic bullet to determine what is important, and certainly Scrum Master training won't help an incompetent manager a competent one.

Re: Scrum is fragile, not Agile

#124

Post by pandapower2 » Mon, May 27, 2019, 1:45 AM UTC

klyrs wrote: post #84

rileymat2 wrote: post #62

Earlier quoted context omitted.

By breaking it down into smaller stories?

My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.

The most successful (but still crappy) solution to this that I have seen is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks.

While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.

Re: Scrum is fragile, not Agile

#125

Post by akeck » Mon, May 27, 2019, 1:47 AM UTC

stevage wrote: post #86

The position may be right, but it's so badly argued. Arguments he uses in support: - the dictionary definition of "agile" - how many times the word "agile" appears in the Scrum Guide - how "lengthy" the Scrum Guide "seems" - that Scrum is a process, so does not "sound Agile". Ugh. How did this reach #1 on HN?

I think because people are frustrated. My read of the conversation is that there's a lot of latent resentment towards modern Agile and Scrum practices.

Re: Scrum is fragile, not Agile

#126

Post by gchucky » Mon, May 27, 2019, 1:52 AM UTC

forgotmypw wrote: post #41

I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good. But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc. Most places j…

I'm on a team that started doing Scrum a few months ago, and we're still figuring it out.

To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?

Re: Scrum is fragile, not Agile

#127

Post by marcosdumay » Mon, May 27, 2019, 1:54 AM UTC

ScottBurson wrote: post #83

Managers, not understanding the difference between latency (how long each task takes) and throughput (how much work is getting done in total), always try to optimize for latency. The predictable result: throughput goes to hell, and then latency goes with it. People who actually write software understand that you have to optimize for throughput first. Not to worry: latency won't be forgotten! But a primary focus on th…

The rationale is that if you minimize latency, throughput has to be maximum too, so optimizing latency is enough.

In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.

Re: Scrum is fragile, not Agile

#128

Post by sidlls » Mon, May 27, 2019, 1:59 AM UTC

wpietri wrote: post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

I don't find much constructive value in your comment. To me it seems like a politely worded screed about the incompetence of management and organizations.

To drive the point home I could easily transform "[o]n average, the first priority of managers and execs is maintaining the power structures that make them a big deal" into a derogatory comment about engineers, fad chasing, and resume padding by a simple word substitution. It would be neither accurate nor fair to many (perhaps most) engineers: just as your comment isn't really accurate or fair to managers or organizations.

Re: Scrum is fragile, not Agile

#129

Post by spamizbad » Mon, May 27, 2019, 2:06 AM UTC

zdragnar wrote: post #93

femto113 wrote: post #85

There's a set of practices here in Seattle that I've come to call Skragile, which evinces the veneer of of Scrum, Kanban, and Agile, but embraces very little of the fundamental philosophies. The most distinctive characteristics: - daily standups (often one per day per team so multiple per person) - sprint based development cycles, often with retrospectives - fondness for the "as an X I want to Y" story - story points…

This is pretty typical elsewhere too (midwest US as a data point). Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds). It feels like we have come full circl…

The irony is, when I first saw Agile/Scrum, I thought of it mostly as a tool to provide discipline further up the chain rather than down.

User stories? Oh, a neat way to keep requirements general and open-ended so we can properly address how we're actually going to solve a user's problem. Surely it'll prevent PMs from over-specifying requirements that lose sense of true objectives.

2 week Sprints? Cool, estimates are hard, and now I never have to estimate more than 10 business days worth of labor.

Retrospectives? Great idea, we can finally do proper post-mortems and knowledge-sharing!

Scrum Masters? Wonderful, there's someone whose dedicated to running the process and making sure we have everything we need!

What I wasn't anticipating:

User Stories? But what about critical requirements that need to be prioritized that don't fit into "As an X I need Y"

2 Week Sprints? I now have so much technical debt a repo man is confiscating my laptop.

Retrospectives? This is always going to be 100% about how we didn't estimate correctly and not about far more important matters like: how these features didn't help our users, technical knowledge-sharing, and ticking-out technical debt.

Scrum Masters? Oh, you mean Project Managers?

Re: Scrum is fragile, not Agile

#130

Post by keithnz » Mon, May 27, 2019, 2:06 AM UTC

wpietri wrote: post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

yes, I too was involved with XP before it was under umbrella of Agile which got consumed by the Scrum borg.

I feel we kind of lost something where creating code/designs using strong feedback loops was a "first class citizen with royal honors" of the software development process. Scrum kind of makes it a sideline issue, a peon of middle management