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

81–90 of 329 posts

Re: Scrum is fragile, not Agile

#81

Post by closeparen »

brightball wrote: post #22
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 because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Scrum wins out at companies that did not exist in the waterfall era, staffed by developers and engineering managers who have only ever worked in startups. Similarity to existing process may explain a large part of the adoption in places that had existing process, but a lot of Scrum shops didn't.

Re: Scrum is fragile, not Agile

#82

Post by oisjdfoiwej »

Where this stuff really fails (IMO) is when execs throw together a half-baked structure around a project, and throw minimally qualified human resources and a few consultancy firms at it. Knowing that "shit rolls downhill", it's always the developers who end up sweeping up the mess working endless hours trying to make deadlines, ensuring everyone further up the hill looks good to their bosses, while praying that their project doesn't get terminated.

In my experience this seems to be an issue unique to enormous corporations. When I used to work at small / medium-sized companies this never happened.

Re: Scrum is fragile, not Agile

#83

Post by ScottBurson »

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 throughput will result in a clean codebase, that will maximize throughput and minimize latency.

Re: Scrum is fragile, not Agile

#84

Post by klyrs »

rileymat2 wrote: post #62
Aeolun wrote: post #61

Earlier quoted context omitted.

You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?

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.

Re: Scrum is fragile, not Agile

#85

Post by femto113 »

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 defined in terms of developer hours or days

- Kanban style "pick a thing to work on", even in sprints

- burndown charts

Seems nearly inevitable that when anyone here says "we need more process" they're looking to have more of one or more of the above. I essentially never hear anyone in project management say anything like "we need to build more prototypes" or "we need to streamline our deployment process" or any of the other concepts that would actually characterize a (lower case a) agile development process.

(edited for formatting)

Re: Scrum is fragile, not Agile

#86

Post by stevage »

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?

Re: Scrum is fragile, not Agile

#87

Post by rileymat2 »

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.

I have not worked in a scrum environment in a couple of years, but when we did it those items were not included in the story. They were part of a definition of done that the team did not really talk about publicly.

Refactoring stories were also rare, it was just sort implicit in the task, unspoken as part of doing it.

I'd imagine that is why they did not get cut.

But yes, management picked feature priorities, but left the implementation up to the team. So at any given time were were working on the "most important" thing from a business perspective.

Re: Scrum is fragile, not Agile

#88

Post by lewisf »

Redsquare wrote: post #50
chias wrote: post #40

Earlier quoted context omitted.

It's similar at my office. We also use it to let the rest of the team know on occasions when you're blocked on something.

Why wait until a meeting to air that you are blocked, just sort it out when you become blocked. Where is the agility?

Having dedicated communication time allows everyone to plan their dedicated focus or "deep work" time.

Re: Scrum is fragile, not Agile

#89

Post by smrtinsert »

Said it a million times before - I deal with way more process and paperwork using scrum than I ever did with waterfall. I'm not saying waterfall was an answer, but at the places I worked on it, it did a better job of staying out of my way.

Re: Scrum is fragile, not Agile

#90

Post by martin_drapeau »

The author had really bad experiences. SCRUM is super agile when done right. Change can be introduced during sprint transitions (reviews, retrospectives and planning) - never in the middle of a sprint. Doing so will kill moral and break the rhythm of the dev team.

SCRUM is meant to be owned by the developers - not management. Shame on companies that hijack and impose such process.

SCRUM gives dev teams rhythm with sprints. Allows them to deliver mini releases of functional software in 2-week increments (could be 1 to 4 weeks too - lenght should be decided during planning). The goal of a sprint is to be decided by the developer and doesn't have to be about the software. Can be about learning, improving as a team or helping team members to grow. Here are a few examples I've seen: - Measure 5 metrics in Kibana - Marie-Pier leads sprint review demo - Try self-merging PR's and measure the results - No more loose ends Of course, in parallel the team builds and delivers an increment of functional software.

The planning, review and retro rituals are paramount. SCRUM can only work well if those are well planned and executed. The retrospective is particularly important to allow the team to improve themselves. Its an opportunity to change their own process (i.e. change the definition of done).

Contrary to wide belief, story points are not part of SCRUM. Its a mechanism that can be used to gauge the size of work - it should be up to the dev team to decide whether to use them or not. Again dev teams should own that process - should not be imposed by management.

These lessons I've learned in the past two years thanks to an awesome SCRUM evangelist we've hired. I'm proud to say its changed our lives for the better.

Post reply on HN