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

291–300 of 329 posts

Re: Scrum is fragile, not Agile

#291

Post by mmcnl »

icedchai wrote: post #49
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…

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.

It doesn't lack a design phase. Where do you get this information from? It isn't explicitly prescribed, but no one prohibits you to make designs.

Re: Scrum is fragile, not Agile

#292

Post by mmcnl »

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…

This is terrible but has nothing to do with scrum. Poor management won't magically disappear after adopting scrum.

Re: Scrum is fragile, not Agile

#293

Post by mmcnl »

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…

What answer are you expecting? Your example indeed makes no sense, but it has nothing do with scrum and has everything to do with clueless people do stupid things. Do you expect this guy will suddenly do only sane logical things when using something other than scrum? I expect not.

Re: Scrum is fragile, not Agile

#294

Post by mmcnl »

Honestly, the comments on this thread baffle me. Endless complaining about scrum and everyone who is not a developer is apparently clueless about software. Is this an adequate reflection of reality? This doesn't seem like a very mature attitude. Scrum is a simple framework with only three roles, the development team being one of them - so if the process fails you are (partly) to blame for it yourself as well. Take responsibility!

What's the better alternative? What have you been doing to make things better? The answers to these questions as much more interesting than endless complaining.

Re: Scrum is fragile, not Agile

#295

Post by mmcnl »

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…

There is no manager role in scrum, so not sure if this has anything to do with scrum.

Re: Scrum is fragile, not Agile

#296

Post by icedchai »

mmcnl wrote: post #291
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.

It doesn't lack a design phase. Where do you get this information from? It isn't explicitly prescribed, but no one prohibits you to make designs.

Experience. I've been developing software for 20+ years. In practice, due to the nature of agile / scrum, design is very minimal or thrown out the window entirely. It encourages short term thinking. Rarely is anything beyond the "current sprint" considered.

Re: Scrum is fragile, not Agile

#297

Post by wpietri »

hinkley wrote: post #287
wpietri wrote: post #143

Earlier quoted context omitted.

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.

You get what you measure and Scrum has no measure at all for design. I’m now curious to see some projects that Ken Schwaber worked on.

I'm certainly not defending Scrum. But I think one of Scrum's big problems is relying on proximate measures rather than actual results. It values output much more than outcome. So I think the way to get good design isn't to try to measure design. It's to release early and often, making sure that products fulfill their purpose.

Re: Scrum is fragile, not Agile

#298

Post by wpietri »

Chris2048 wrote: post #252
wpietri wrote: post #191

Earlier quoted context omitted.

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.

> if we're going to think of ourselves as professionals We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..

I'd love to see that kind of organizing happen.

But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward.

I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.

Re: Scrum is fragile, not Agile

#299

Post by hinkley »

wpietri wrote: post #297
hinkley wrote: post #287

Earlier quoted context omitted.

You get what you measure and Scrum has no measure at all for design. I’m now curious to see some projects that Ken Schwaber worked on.

I'm certainly not defending Scrum. But I think one of Scrum's big problems is relying on proximate measures rather than actual results. It values output much more than outcome. So I think the way to get good design isn't to try to measure design. It's to release early and often, making sure that products fulfill their purpose.

I think our whole industry is full of proxies for the things we actually care about, which is for instance why we rant so often about the hiring process.

For another example, look at what we talk about with Clean Code or SOLID principles. We have that old joke about the two hardest things are naming things, cache invalidation and off by one errors. I think the fourth hardest one is resolving merge conflicts.

You work carefully on code for weeks or months and then in one fell swoop it all gets broken when you aren't looking at it anymore. It's really bad for morale.

If you read through all of these Best Practices with the notion that merge conflicts are dangerous, then you start to see them as designed to keep conflicts from happening. Putting related code together isn't just about reading comprehension. It's also about keeping unrelated code apart. You and I can work on unrelated stories without ever doing a 3 way merge.

And if you look at merges as the problem, you start doing things like alphabetizing data structures that don't have a strong cohesiveness to them because then when you and I add a feature to the same data structure, we aren't both modifying the bottom of the file. I put something under T and you put it under G.

To put this another way, if in some perfect future someone invented a merge tool that never screws up, so that we only get merge conflicts when two people are accidentally working on the same feature/bug, we might start to question all of these practices as overwrought.

Re: Scrum is fragile, not Agile

#300

Post by forgotmypw »

nitely wrote: post #226
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…

7 hours of meetings? did people show up the next few days for work?

Yeah. It was a bit tiring, but also fun. I think it helped that we all liked each other.
Post reply on HN