Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

Post reply on HN
Print view View original

271–280 of 329 posts

Re: Scrum is fragile, not Agile

#271

Post by TuringTest »

fnord123 wrote: post #245
tootie wrote: post #132

Earlier quoted context omitted.

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…

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

aka WaterFail

Re: Scrum is fragile, not Agile

#272

Post by TheOtherHobbes »

BoiledCabbage wrote: post #215
asplake wrote: post #206

Earlier quoted context omitted.

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…

"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'…

This logical fallacy is sometimes called No True Agile.

Re: Scrum is fragile, not Agile

#273

Post by dragonwriter »

Sammi wrote: post #224
dragonwriter wrote: post #107

Earlier quoted context omitted.

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

You can scream "That's not actually Scrum" untill the day you die. It doesn't change the fact that that's how it is perceived and done in almost every place that says they do Scrum.

A sibling comment to yours made essentially the same point, and I had already addressed it, before you posted your comment: https://news.ycombinator.com/item?id=20020206

Re: Scrum is fragile, not Agile

#274

Post by dragonwriter »

HelloNurse wrote: post #238
dragonwriter wrote: post #107

Earlier quoted context omitted.

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

> Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team’s various inspection and process adjustment points. This process adjustment usually means "sorry about your vacation" and/or "you aren't doing enough overtime".

Yes, if external actors rather than the self-organizing teams own the process, that is probably the first response, but that won't actually stop the buildup of tech debt and the velocity impacts, though it may produce a one-time, non-repeatable improvement, so even in that case if someone (even the wrong actor) is monitoring velocity and doing process improvement, there will be an impetus for further change.

(Of course, if the wrong actor is monitoring velocity and controlling process, then the team has an incentive to mask the effect of tech debt but continuously adjusting estimates to maintain the illusion of constant velocity, a d avoid the first bad response, or, if that opportunity is missed, to avoid the subsequent external interventions.

Re: Scrum is fragile, not Agile

#275

Post by icedchai »

wpietri wrote: post #143
icedchai wrote: post #49

Earlier quoted context omitted.

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.

Yes, you're correct... I didn't mean a "formal" phase, so much.

Re: Scrum is fragile, not Agile

#276

Post by chimprich »

doomslice wrote: post #64
dragonwriter wrote: post #36

Earlier quoted context omitted.

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room It is central to the idea of the daily standup is that it is one team . > Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board. If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for shar…

> As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly. The powers that be at my work decided that “sprint predictability” is the most important metric here. This means that if we pull in stuff near the end of the sprint but don’t finish, predict…

If you're trying to do scrum properly, you shouldn't be consistently finishing work early. That implies you're overestimating stories.

When you do finish a bit early I've not normally found it a problem to find some small bits of tech debt, research, or admin work to fit in before the end of the sprint.

Starting work on stuff from the next sprint is not ideal because it'll throw your estimates off for the next sprint, plus you don't actually know for sure what is going into the next sprint.

Re: Scrum is fragile, not Agile

#277

Post by wbronitsky »

I’m quite amazed by the lack of substance in this article. It takes potshots at certain ideas and processes, without managing to explain these potshots, or even coherently explain the ideas and processes. It is a flimsy opinion piece with no substance, but a clickbait title so everyone ran here to comment.

What a virtuous cycle

Re: Scrum is fragile, not Agile

#278

Post by epage »

MartinCron wrote: post #182
barrkel wrote: post #46

Earlier quoted context omitted.

Because it's a sprint . You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.

“Sprints” are, pretty much by definition, a non-sustainable pace.

Agreed. I regularly ask "Why are we running a marathon in a thousand sprints?".

Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for "high velocity". There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.

Re: Scrum is fragile, not Agile

#279

Post by LifeLiverTransp »

nine_k wrote: post #160
keypusher wrote: post #153

Earlier quoted context omitted.

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 hybr…

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…

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

Re: Scrum is fragile, not Agile

#280

Post by wpietri »

dragonwriter wrote: post #211
wpietri wrote: post #141

Earlier quoted context omitted.

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?

> What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? About the same percentage as that of “Agile” software development shops that put people and interactions above processes and tools. OTOH, at any place that is considering implementing either, there are decision makers who can influence (or in the case of Scrum more than Agile, authoritatively direct) whether or not th…

Most nominally "Agile" shops are in effect doing Scrum, so I'm not sure that answer helps your case. Either way, it sounds like we agree the "good Scrum" shop is at best rare.

Given that, I think it's worth considering that the problem is Scrum. Especially given that Scrum is not just a process, but an organization and an army of "certified" people that sell services.

When something generally doesn't work for its stated purpose but keeps making money, I think it's worth asking what its real purpose is. E.g., things like crystals and psychics. As Eric Hoffer wrote, “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”

Post reply on HN