Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

141–150 of 329 posts

Re: Scrum is fragile, not Agile

#141
post #31

Earlier quoted context omitted.

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…

> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…

What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?

Re: Scrum is fragile, not Agile

#142

Earlier quoted context omitted.

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

> Commitments and sprints become terribly destructive over time. Could you elaborate?

Yep. :)

https://www.brightball.com/articles/reality-driven-developme...

Re: Scrum is fragile, not Agile

#143
post #31

Earlier quoted context omitted.

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…

The biggest problem with Scrum is it lacks any sort of design phase. You do the minimum. Oh, it doesn't work quite right? We'll fix it in the next sprint... The "spiral" model is closer to a true iterated waterfall. I've seen it used successfully in more mature companies.

You're confusing "investing in design" with "having a design phase". I agree many Agile teams underinvest in design. But so do many non-Agile teams. The problem isn't the lack of a formal phase. The problem is not taking it seriously.

Re: Scrum is fragile, not Agile

#144
Although I have remained sceptical of Scrum, I do find it a bit strange that many of the negative comments about Scum here seems to be related to not doing Scrum (The old, you are not doing Scrum properly). All the talk about managers, and being told what to do in a sprint etc. None of that sounds like Scrum to me. Isn’t the whole idea of Scrum about self organising teams (?), independent of management etc. All you have is a Scrum Master to facilitate the process, and a Product Owner (part of the team) who prioritises the backlog because that role has an understanding of what is needed to solve the problem at hand (in terms of functionality needed).

Re: Scrum is fragile, not Agile

#145
post #31

Earlier quoted context omitted.

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…

> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…

This. I've run programs that purport to be agile but the work input stream was waterfall and disconnected from the means of output so it was really timeboxed waterfall, unfortunately my management did not agree to re label. You know it is real Scrum if it is painful for the business team and they come to realise that now it's software all the way down.

Re: Scrum is fragile, not Agile

#146
I searched the entirety of the Scrum Guide (https://www.scrumguides.org/scrum-guide.html) and could not find a single reference to "agile". And a quick Google search about the origins of Scrum reveals:

In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.

Re: Scrum is fragile, not Agile

#147
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

Totally. Although this has long been a problem.

My dad started developing in the late 1960s. He did a lot of in-house software, mainly manufacturing and insurance systems. His approach was to go out and see something in use, talk to the people using it, go back to his office, write something, release it, and go talk to the people again. He'd do that loop in as little as a couple of days.

Today we'd call that obviously agile. But both back then and now, higher-ups wanted more "control", by which they meant feelings and appearance of control. Which caused longer feedback loops. Which made things more out of control, which required more process and even longer feedback loops.

I think we have the same struggle today, and I have no idea how to get out of it.

Re: Scrum is fragile, not Agile

#148
post #26

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

First of all, most issues with process issues are more a reflection of the organization and what drives them than the process. I would say you should start talking about, 'Our process' instead of 'Scrum'. >These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I…

> Scrum master should be a team member and rotated along the team.

I don't agree. For us the scrum master is a fixed position who has as a responsibility to advise the teams on how to fix problems with their processes or to help build these processes in the first place. This works very well for us, because the scrum master is explicitly only an adviser.

Meaning I, as a team lead, do not have to do what the scrum master says, but I always have someone experienced with scrum who I can ask when problems arise or when the team wants to change the processes.

Re: Scrum is fragile, not Agile

#149

Earlier quoted context omitted.

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…

My favorite team experience was scrum done "right". Standups were run by a scrum master who was the most experienced engineer on the team- programming longer than I've been alive type of guy.

Probject managers and product owners were kept at arms length in the sense that they didn't dictate how, what or when we did what we did. They translated the business requirements and timelines into something we could understand and react to.

Somehow, all of that turned into two week sprints that felt sustainable... At least until the company bought out another company, and everything went downhill. That, however, is a story for another time.

Re: Scrum is fragile, not Agile

#150
post #60

In my current team, we post our daily status on a slack channel: what we do yesterday and we are going to do today. We try to keep to one or two points. We have remote people so that works out well. Standup is optional. On Monday meetings, each person tell one thing that we are going to do. Sometimes it is two things but the point is to focus.

This is the way it should be.

Meetings should only be between business / leads to get scope onto canvas.

If I'm blocked I'll seek out the person who can most help me. I can easily find 5-10 minutes to write out a summary, but on my terms when I'm not in coding mode.

Now, I'm freelancing, likely to be team lead for the company assuming they get financing - and I keep taking notes and reading ways to organize better. We have a ton of work to do, it's a financial mobile app that has 0 tests on the api (I'm single-handedly running the API development Laravel + vue (for some web views)). Money is tight so I'm the only dev on web side and we have 1 ios dev.

The hope is to be full-time at this by Christmas w/ a 6 figure salary (my first +6 figures).

Post reply on HN