Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

111–120 of 329 posts

Re: Scrum is fragile, not Agile

#111
post #109

There have been a lot of software development methodology but one thing that's been overlooked a lot is the competence of the people doing the execution of the project. I am talking not just about the developers / engineers who are building the product but everyone across the pipeline - product owners, business stakeholders, process specialists, business analysts, project managers and just about everyone else. People…

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"

Re: Scrum is fragile, not Agile

#112
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?

Generally if things can get unblocked as you go, that's better, and so this isn't particularly common. But sometimes you need your manager to go kick down a door for you and it's a handy time to let him know. Sometimes it's more benign and it's just easier to ask the group in person when everyone's together sipping their coffee together than it is to fire off a bunch of Slack messages or a group email or whatever.

And to be clear, when I say "blocked" I'm not talking like "I can't get any work done until X", I'm more talking like "this particular avenue needs X to happen before I can continue it, so I'm shelving it for now and doing something else until we can get it resolved." If you find yourself in the former case, something has already gone horribly wrong that should probably have been resolved days ago.

Re: Scrum is fragile, not Agile

#113
post #55

Earlier quoted context omitted.

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

I love these commitments. When my Scrum leaders asks me why we didn’t finish what we ‘committed’ to doing these two weeks I want to strangle him (nothing personal, I do otherwise like the guy :P). The terminology is so incredibly developer hostile.

Which is why the scrum handbook went with the term forecast instead. Many years ago.

Re: Scrum is fragile, not Agile

#114
post #42

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…

If you can say more than a minute, but less than a decade, you've already got SOME idea of the timeframe for a task. Granted that sort of estimate would get you called to HR for insubordination. But can you pull the bounds in from either direction at all?

I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preference is to ask devs for just the tightest bounds to timeframe they're actually comfortable with, then estimate based on that and pass up the chain. I consider it to be on my shoulders if things take longer than I communicated upwards.

Re: Scrum is fragile, not Agile

#115
This is very light on specifics? What, exactly, is fragile about Scrum? Where does it break down, and what can I do to prevent it from breaking down?

Without that info, this just feels like buzzword bingo, a la "What should I write about to stir the pot today?"

Re: Scrum is fragile, not Agile

#116

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

Waterfall was terrible in many ways but it seems to me for all the problems with that methodology that "agile" has fixed it has created at least one new one, and often more.

Re: Scrum is fragile, not Agile

#117

Agile itself is pretty bad too. “Responding to change over sticking to the plan” is pretty much the single biggest reason why I see projects fail.

The problem is that if the environment or requirements have changed and you don't take account of that then you may have a successful project delivering a product that is no longer relevant.

Re: Scrum is fragile, not Agile

#118

Earlier quoted context omitted.

>I think it works well enough, for a few years. "Fortunately," hardly anyone in Silicon Valley plans to be working on the same codebase in a few years. There's a good chance the problem space won't be relevant anymore by then, and on the off chance it's still funded, the new team will rewrite it whether or not it's good. >sprints are too short for devs to sneak refactoring into the schedule. As I've gotten more senio…

Is the Silicon Valley representative of software development though ? Because on the other hand we have professors telling us that the average (surviving?) software lifetime is 20 years...

This is just intuition but I suspect that the lifetime for software is u shaped. Much of it is very short lived but software that lasts more than 1-2 years is very likely to live for a decade or more.

A lot of 6 month old code gets thrown away either because its been rewritten or because it didn't achieve its stated objective. Meanwhile a bunch of companies are relying on systems that were first created in the 90s because that software achieves its objectives and the cost justification for a rewrite isn't there.

Re: Scrum is fragile, not Agile

#119
post #15
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 IMO because it's an awesome word and conjures up subliminal images of brute force pushing obstacles out of the way, bringing success to the team. Execs can relate to it without even knowing what it is.

Scrum won out because it's basically feudalism. It's great for those in the upper echelon.

Re: Scrum is fragile, not Agile

#120
post #86

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?

At least the discussion in the comments is better argued.
Post reply on HN