Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

161–170 of 329 posts

Re: Scrum is fragile, not Agile

#161

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.

This is the overblown excuse people use to argue for their preferred changes, when really the environment or requirements usually don’t change, and when they really do then either it’s small and you should still stick to the plan or else it’s big and the need for change is so overwhelmingly self-evident that you don’t need things like Agile slogans to generate motivation or buy-in to change things.

Either way, harping on the idea of “but what if circumstances changed” is mostly just what corporate politicians do to subvert people demanding evidence for the requirement of changes.

Re: Scrum is fragile, not Agile

#162
post #154

Earlier quoted context omitted.

Why are your managers attending stand up? The Daily Scrum is the team's meeting. I swear Scrum is only fragile because no one reads the bloody book, or if they do they skim it or ignore it. From the scrum guide... "The Daily Scrum is a 15-minute time-boxed event for the Development Team." It is the team's event, if there are other people there it should be at their request. The guide goes on to say that.. "If others…

If something is self-organized, there is no need for all this ceremony and bullshit that comes with capital-A Agile or Scrum. You just shoot the shit and talk about what you're doing. Stand-ups and all the process attendant appears to be universally imposed from on high as a micromanagement technique, or because they were sold the idea as some kind of silver bullet by a talk or a snake-oil consultant.

I agree. Scrum is training wheels. If your team is mature and knows when to talk to each other then awesome, let the team do what works for them.

I feel like Scrum is for teams that suffer Stockholm syndrome from poor management and need to be taught how to human beings again.

Re: Scrum is fragile, not Agile

#163
post #42

Earlier quoted context omitted.

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

I understand that estimates are important and I give estimates. But recently in my company it’s fashionable to talk about “commitments” and I won’t give those. In my view this is just a way to get overtime and weekend work out of people once things fall behind so they meet their commitments. I commit to do my work as best as i can but I can’t commit to work overtime because of issues that are often out of my control.

Re: Scrum is fragile, not Agile

#165

Earlier quoted context omitted.

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

> "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."

> A witty retort may be in order

I don't think this will score you a lot of points.

Re: Scrum is fragile, not Agile

#167

Earlier quoted context omitted.

This is pretty typical elsewhere too (midwest US as a data point). Its popular because managers can implement it. Agile- the manifesto version- was intended as a way to re-introduce the notion of discipline that newer generations of programmers had lost (where previously they were engineers and scientists who wrote code, now people who code exclusively eithout other backgrounds). It feels like we have come full circl…

The irony is, when I first saw Agile/Scrum, I thought of it mostly as a tool to provide discipline further up the chain rather than down. User stories? Oh, a neat way to keep requirements general and open-ended so we can properly address how we're actually going to solve a user's problem. Surely it'll prevent PMs from over-specifying requirements that lose sense of true objectives. 2 week Sprints? Cool, estimates are…

The most salient truth about power is that it cannot be disciplined, except by greater power.

Here's the thing: I have been lucky enough to work with engineer-founders as my bosses for most of my career. You know what the downsides are? None. It's just pure awesome.

It's getting to the point that they're the only people I want to work for.

Re: Scrum is fragile, not Agile

#168

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…

I'm on a team that started doing Scrum a few months ago, and we're still figuring it out. To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?

It did not seem dragged out, it was just thorough, and reasonably un-rushed. It was somewhat tiring, but definitely worth it.

By the end of the planning meeting, we had a clear idea of what we were going to accomplish, and a reasonable amount of confidence that we considered all the tasks that went into our plan.

Because when a story was, e.g. "add addresses to the clients page", it was broken down, discussed, thought out, and agreed upon. The moments when I discovered, oh shit, this story will actually take 10 hours longer than I had allocated, and now I have to stay until 10PM two days this week to meet my committment. Because our story points were approximately an hour each, and almost every story was broken down until there were no tasks more than 3 points each, 1 or 2 preferred.

It was all thanks to our scrum-master/project manager, who had actually spent a lot of time learning about scrum/agile/kanban/etc, read many books on it, and most of all, was committed to doing it right.

I think our sprints were a bit longer than 2 weeks.

Re: Scrum is fragile, not Agile

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

AFAIC, the only thing that works with a fixed deadline is a variable scope. Which is basically a tenet of Agile.

The alternative is some sort of sub-iteration hybrid where you attempt to fix deadlines for much smaller units of work and constantly revise.

This is OK for some industries. But 2/3rds of a car doesn't quite sell...

Re: Scrum is fragile, not Agile

#170

Earlier quoted context omitted.

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

> "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."

They did, and I replied

"We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data."

Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.

Post reply on HN