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

191–200 of 329 posts

Re: Scrum is fragile, not Agile

#191

Post by wpietri »

anon1m0us wrote: post #34
barrkel wrote: 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…

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed. Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.

Re: Scrum is fragile, not Agile

#192

Post by ddebernardy »

ravenstine wrote: post #66

Has anyone ever tested whether Scrum or Agile actually work better than "Waterfall" for software development?

Agile works fine, if you ignore the Scrum hocus pocus. Stick to basic project management principles (work on one project at the time, wrap things up before moving on to the next project, set aside a bit of time for unrelated work) with the stakeholder put at the center of what you're up to.

The problem with Scrum is that it's usually (always?) implemented as serialized waterfall projects with completely arbitrary looking deadlines (i.e. the sprint's length). All too often things get sort of done but not done quite as well as everybody would be happy with. It's stressful for everyone involved and, insofar as I've seen it used, it makes accumulating technical debt even more likely than more traditional waterfall projects.

Re: Scrum is fragile, not Agile

#193

Post by wpietri »

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…

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.

Re: Scrum is fragile, not Agile

#194

Post by myspy »

Scrums point for me is to prepare your development time. Talk about the issues, prepare the issues, ask the client, make a mock-up and then implement in code.

Usually it's hack together something and see if it sticks, which is awful.

Re: Scrum is fragile, not Agile

#195

Post by mempko »

perl4ever wrote: post #111
mempko wrote: post #109

Earlier quoted context omitted.

Yes! One thing I don't see people mention is that Scrum requires that everyone on a team to be competent. It's for teams that are already great that want to be even greater. It's not for teams with inexperience and incompetence. My guess is many people are afraid of scrum because it may out them as incompetent.

I'm not saying you're right or wrong, but "many people are afraid of scrum because it may out them as incompetent" sounds like the cliche of "X cannot fail, it can only be failed"

Yes, it does sound like a cliche. However, the point of scrum is to find problems that get in the way. Through the process, it's clear who knows what they are doing and who doesn't.

Re: Scrum is fragile, not Agile

#196

Post by edsykes »

just to offset a bit about scrum being bad: I have used SCRUM over 15 years to run teams and it worked. Most of the problems I am hearing on here are culture problems and no process can fix that. Regarding planning, a day per scrum is normal - sometimes longer, you have to use your judgement to determine when to move from design to implementation. Also, heavy use of spiking stories to learn enough to create the right design is important

Re: Scrum is fragile, not Agile

#197

Post by fabioborellini »

maxxxxx wrote: post #42
clumsysmurf wrote: post #3

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…

I passionately hate being asked for "commitments". If it's stuff of any reasonable complexity or novelty I will have no idea how long it will take and therefore can't make any commitments. The only thing I can commit to is to make sure that people don't waste time and work towards the goal. The problem is that management has no problem wasting a lot of time with useless meetings or not committing to the final feature…

Even better is being told to commit by the Scrum Jesus (who does not even try to understand the business domain or engineering issues, since he's getting hired for being the Scrum Jesus) to stories with no one available for even defining or discussing them. Our story might have been just a word someone saw at a trade fair.

Then, two weeks later, being asked why I did not complete what I committed to.

Re: Scrum is fragile, not Agile

#198

Post by munchbunny »

keypusher wrote: post #153
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…

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…

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.

Re: Scrum is fragile, not Agile

#199

Post by Bombthecat »

anon1m0us wrote: post #32
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.

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many…

Because Tech debt and I reading messy code base never happened in waterfall...

The problem is always : features and customer request over bug fixing or design fixes.

The system, project type does not matter. That's why some PO recommend 10 percent allocation to devops / ops, 10 percent to improving code base . And "no bug survives the Sprint" philosophy. And what is left,is you next feature or customer request.

Re: Scrum is fragile, not Agile

#200

Post by tannhaeuser »

clumsysmurf wrote: post #3

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…

> nobody says much of importance, and just parrots what is already on the Jira board

Worse, the moment anything of interest gets being discussed, SM stops it, saying "let's take this offline" (in German-speaking projects at least, where there's a tendency to use English words to really say nothing at all). Which brings us to

> any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen

MBAs have identified and captured the role of a Scum master (sic!) to comfortably represent a project towards management, without the responsibilties of a project manager (I'm just moderating the project), yet with an instrument to turn time-based freelancing and employed work into a fixed-price deal through commitments/forecasts.

Post reply on HN