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

181–190 of 329 posts

Re: Scrum is fragile, not Agile

#181

Post by alexashka »

anon1m0us wrote: post #32
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.

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…

It's easy to say something is shit.

The tricky bit is having a solution and implementing it.

Having something well thought out is hard work. Is hard work rewarded? Is initiative to even try rewarded? I'd say the answer is no.

The answer becomes yes in small teams that are given time, freedom and resources, or in times of crisis (same thing as small team really, minus the time bit), as far as I can tell. Otherwise, most people's natural tendency (including me) is to phone it in. We'd be wise to let people in software development and many other professions that are not manual labor, to switch careers after 30-35 if they haven't done anything worthwhile by then.

Working with people who have to phone it in for the next 30 years and know it is modern day hell for anyone with an iota of ability.

It's permanent compromise and insincerity, or being an outcast that's temporarily tolerated for doing 5-10x the work of the person next to you.

Re: Scrum is fragile, not Agile

#182

Post by MartinCron »

barrkel wrote: post #46
drngdds wrote: post #39

Earlier quoted context omitted.

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. Well there's your problem. How is that inherent to scrum?

Because it's a sprint . You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.

“Sprints” are, pretty much by definition, a non-sustainable pace.

Re: Scrum is fragile, not Agile

#183

Post by bitwize »

The aim of Scrum, and other methodologies tagged Agile, is -- near as I can tell -- to emulate a good programmer with a team of mediocre programmers. Not that all developers working on Agile teams are mediocre programmers, only that the business wants to achieve good-programmer results while still being able to leverage the wider talent pool and lower risk and cost offered by hiring mediocre programmers, so it tends to adopt formalized processes designed to work well with them in the hopes that following the process will make them achieve good results. The process is a formalization of the relationship a good programmer has with their client, which is known to produce good results; therefore, the process must also produce good results by definition (and any failure to produce good results can immediately be blamed on lack of adherence to the process).

Unfortunately there ain't no such thing as a free lunch, and when you emulate you necessarily incur overhead, which can be prohibitively large if you're emulating something powerful -- plus, if you have actual good programmers on your team, they will either quit or start emulating mediocre programmers to remain compatible with your mediocre-programmer process. Either way, you lose the benefits of having them.

Re: Scrum is fragile, not Agile

#184

Post by ako »

ScottBurson wrote: post #140
marcosdumay wrote: post #127

Earlier quoted context omitted.

The rationale is that if you minimize latency, throughput has to be maximum too, so optimizing latency is enough. In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.

> The rationale is that if you minimize latency, throughput has to be maximum too Exactly. And it's quite wrong even without taking the growth of complexity into account — as every engineer knows, or should know. Getting every task done as quickly as possible requires a lot of context switching, which is murder on throughput. When you add in the effects of complexity growth (aka technical debt, though I think "comple…

There's pretty good theory behind the idea of minimizing latency to improve throughput. One of the better books on this is "Managing the Design Factory", and a followup called "The principles of product development flow".

These books are not about software development, but of product development in general. The first one actually predates agile, published in 1997.

Core idea is that minimizing the size of the tasks is the best way to improve productivity. Not getting it done as quickly as possible, but to decrease the size.

Remember that product development (new, innovative, uncertainties) vs product manufacting (repeatable), is not a new problem, and not unique to the software industry. There's a lot to learn from product development in other industries.

Another interesting read is "The Toyota Product Development System: Integrating People, Process And Technology" which talks about ways of making product development predictive, and less risky.

It's interesting to see how little software is used to improve the process of software development. Other industries use a lot of software (cad/cam, visual modelling, testing, impact analysis) to improve efficiency and quality of product development. Software for product development is a huge market.

Re: Scrum is fragile, not Agile

#185

Post by sopooneo »

maxxxxx wrote: post #163
sopooneo wrote: post #114

Earlier quoted context omitted.

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.

That makes perfect sense. And I applaud your push against a practice that does seem to be pushing devs for unpaid overtime. You're right.

Re: Scrum is fragile, not Agile

#186

Post by jeandejean »

That's a bit of an easy critic of Scrum on its literal sense rather than a critic on what doesn't work or isn't agile or is fragile. I've seen Scrum badly and imperfectly implemented everywhere I've been, yet I think this is preferable as having a strict interpretation of its principles and processes. I don't care actually if Scrum is intrinsically not agile (or Agile): I think what matters and is actually what's happening is people adopting Scrum with agility.

It has good principles like backlog, sprint and daily meeting. If teams only pick one of those or anything else and that it help them, great! By the way holding solely Scrum accountable for failures is narrowing down the analysis to only one part of all things that can go wrong and have nothing to do with Scrum. That's a cognitive biases concentrate.

Re: Scrum is fragile, not Agile

#187

Post by feviskus »

femto113 wrote: post #85

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…

you just described perfectly how scrum works at my company in Germany.

Re: Scrum is fragile, not Agile

#188

Post by seer »

sopooneo wrote: post #114
maxxxxx wrote: 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…

One manager I’ve worked with had the brilliant notion of “x2+1” time of what the dev says.

Anecdotally this has worked out remarkably well throughout my career - from single dev to cto - even stuff that I _new_ was going to take for example 2 days, if done properly ended up in like 5.

Didn’t matter if I was doing the estimate or someone else. At some point I just gave up and started doing the “my gut says 3 hours, so it must be 7 hours of work then, and send that up the chain. That cheeky “+1” had saved my ass more times than I can count.

Re: Scrum is fragile, not Agile

#189

Post by wpietri »

tootie wrote: post #132
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 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…

I have almost never seen Scrum sold as magical by developers. Executives? Yes. Consultants? Yes. But developers?

I agree that fixed-scope contacts cause a lot of problems for Agile approaches. However, they also cause a lot of problems for non-Agile approaches. If I have to deal with supposedly fixed-scope situation, I'm going with and Agile approach.

There are two basic cases. One is that scope is truly fixed (which is rare). In that case, having a new releasable version every week with highest-priority features first is excellent risk management. When the date comes, you'll have something to ship. You also get to continually validate and improve internal processes, so you're more likely to be using the time available effectively.

The other is that scope was fixed in the contract but is in practice variable. So every week you deliver something to the customer. Every week you build trust. And every week you encourage them to do tests, deploy early, anything so they start getting value. At that point they get user and business feedback, and come to you with changes. That's the point where you start shifting from fixed-bid to time-and-materials. Maybe you keep to the same budget, but now they're getting more for their money. Maybe they look at the backlog and say, "Wow, there's still lots more value to deliver, let's keep going."

Re: Scrum is fragile, not Agile

#190

Post by nitely »

codesnik wrote: post #91
addicted wrote: post #44

Earlier quoted context omitted.

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature). 1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right. What seems…

Sometimes I find myself so stressed out by the standup, I basically doing nothing the rest of the day. Also I have a habit now to get up early and try to do yesterday's portion of work in an hour or two before standup just to report it. I completely stop thinking in time periods wider than sprint, and I thought before that was my strength. Worst thing, the process forces an idea that my struggle with it is, basically…

You are not alone. Meetings just suck all the energy out of me.
Post reply on HN