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

101–110 of 329 posts

Re: Scrum is fragile, not Agile

#101

Post by dominicl »

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…

Agreed, it feeds the existing power structures. And it did hit at the right time when over-communication is not only appreciated but everything else is seen as intransparent and potentially suspicious. "You don't even know what your team is doing?" - is the best way for middle-management to pick on each other. So in order to never get into that situation daily standups, slack, jira, basecamp all these "transparency tools" are welcome as they offer defense for this manager.

Does anyone know if there is an anti-movement to that over-communication trend? Something along the lines: "The only way to go fast is to go well", * Plan * Honor the flow * Adjust

Re: Scrum is fragile, not Agile

#102

Post by AngeloAnolin »

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 attribute failure to the process because it is demeaning to put the blame on people when established best practices can receive the finger pointing.

Stop the notion of being nice to the lack of skills of people. Hiding behind being nice does not resolve the issue but rather propagates it. Fix the issue by providing the grounds for people to learn and become productive.

Re: Scrum is fragile, not Agile

#103

Post by mlthoughts2018 »

jrochkind1 wrote: post #78
mlthoughts2018 wrote: post #27

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.

I think the key motivation of agile is the recognition that the plan made in advance is often not right . If completing "the plan" is seen as success, then of course sticking to the plan is the best way to success. But if maximizing business/user value is the success, then "no plan survives first contact with the enemy." (I don't like "the enemy" concept, but this is a famous quote that gets across the concept). And…

This is just not accurate. The types of changes thrown in after early requirements gathering are most often coming from product managers and executives, not from customers and not driven by genuine feedback or budget constraints, etc.

“Sticking to the plan” does not mean rigidly enforcing zero changes, but rather means keeping a commitment to the general scope and direction that was mapped out. Compromises should require extraordinary hard evidence before being accepted.

This is really why Agile as a general set of guidelines is so easy to subvert and ends up being a misused tool in most every situation where Agile is deployed (Scrum of otherwise).

Project management guidelines need to start out by specifying a way that quality is strictly disallowed from being subverted by competing interests that lobby for changing the plan.

If a set of software project management guidelines doesn’t start out with an unchallengeable quality-above-all-else mandate that creates policy barriers to the natural entropy of different interests trying to lobby for why their preferred change has to be made, then it’s doomed to just get politically subverted.

Doesn’t matter if it’s Agile, Waterfall, extreme programming, whatever.

“Sticking to the plan” in the sense of setting up preemptive, high-cost barriers to anti-quality modifications to what was agreed is _the_ thing.

Re: Scrum is fragile, not Agile

#104

Post by bartimus »

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…

> User Stories are supposed to be forecasts, not commitments.

Indeed the commitment is supposed to be with the sprint goals. I've seen this vital aspect of scrum getting overlooked too often.

Re: Scrum is fragile, not Agile

#105

Post by mixmastamyk »

xyzzy_plugh wrote: post #54
anon1m0us wrote: post #32

Earlier quoted context omitted.

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…

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."

Re: Scrum is fragile, not Agile

#106

Post by jpollock »

Whenever I've used scrum, the developers set the estimate and task breakdowns. We even had the developer _doing_ the work provide the estimate. It's not really fair to have someone else estimate your work, it doesn't breed commitment either. We did sanity check things - sometimes an estimate would seem big and everyone else would ask why. The answer was either we had missed something (typically), or (rarely) the estimator misunderstood the task and thought it was something bigger.

At the end of each sprint/cycle we shared estimate vs actual effort, to improve our ability to make a good estimate and set an overall velocity.

On my first Scrum/Agile project, there were complaints of overwork the first sprint. Then I pointed out that we were the ones setting our own estimates, setting the pace and causing our own problems.

After that, the estimates got reasonable. We stopped playing "Name that Tune" with our estimates and the project settled down.

Re: Scrum is fragile, not Agile

#107

Post by dragonwriter »

barrkel wrote: post #31
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.

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…

> Scrum is iterated waterfall.

No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iterations.

> munching through backlog items fed to them by product managers.

That's...not actually Scrum, as it implies that either the role of Product Owner is taken by a PM outside of the Scrum Team or that that the Scrum Team is not self-organizing, either of which is a significant (even if common) deviation from Scrum.

> the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future

Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team’s various inspection and process adjustment points.

OTOH, if the Scrum Team is properly cross-functional and self-organizing instead of having a non-team-member imposed as Product Owner, then including appropriate restarting as components of completion of relevant backlog items shouldn't be a problem.

Re: Scrum is fragile, not Agile

#108

Post by binaural »

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.

I completely agree here. Instead of understanding the volatility of the requirement(s) and designing for that, we refactor and react.

Re: Scrum is fragile, not Agile

#109

Post by mempko »

AngeloAnolin wrote: post #102

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.

Re: Scrum is fragile, not Agile

#110

Post by crispyambulance »

AngeloAnolin wrote: post #102

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…

    > Stop the notion of being nice to the lack of skills of people.
Projects don't fail because people are "too nice".

Projects staffed with fully qualified people with hardcore skills fail too. And projects staffed with utterly under-qualified people sometimes do just fine.

The thing is projects succeed or fail for many different reasons, usually multiple reasons operating in concert.

I think the best approach is not to be dogmatic about process and to recognize that "pointing fingers" rarely resolves anything, regardless of whether one is pointing at the process or the people.

Post reply on HN