Hacker News new | past | comments | ask | show | jobs | submit login

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 won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.

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

You can scream "That's not actually Scrum" untill the day you die. It doesn't change the fact that that's how it is perceived and done in almost every place that says they do Scrum.

A sibling comment to yours made essentially the same point, and I had already addressed it, before you posted your comment: https://news.ycombinator.com/item?id=20020206

What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?

> What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"?

About the same percentage as that of “Agile” software development shops that put people and interactions above processes and tools.

OTOH, at any place that is considering implementing either, there are decision makers who can influence (or in the case of Scrum more than Agile, authoritatively direct) whether or not that's the case, so for them, at least, it's worth distinguishing between problems with Scrum as prescribed and problems which often occur because decision-makers decided to ignore key parts of Scrum-as-prescribed.

Most nominally "Agile" shops are in effect doing Scrum, so I'm not sure that answer helps your case. Either way, it sounds like we agree the "good Scrum" shop is at best rare.

Given that, I think it's worth considering that the problem is Scrum. Especially given that Scrum is not just a process, but an organization and an army of "certified" people that sell services.

When something generally doesn't work for its stated purpose but keeps making money, I think it's worth asking what its real purpose is. E.g., things like crystals and psychics. As Eric Hoffer wrote, “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”

> Most nominally "Agile" shops are in effect doing Scrum

No, most nominally Agile shops are also nominally doing Scrum, but actually doing not-Scrum in a not-Agile context, largely due to sabotage of both core principles of Agile and foundational elements of Scrum by management.

It doesn't matter what name and superficial ritual you put on the process if it's all window dressing over top-down disempowering command-and-control by persons who are neither doing the work nor experts on the work.

Which isn't to say that the Agile and Scrum bodies of work aren't part of the problem: neither really addresses as a key point how the team effectuates ownership of process and how interaction with management works, which means those gaps get filled in (or rendered moot, in the first case) in ways which compromise what those bodies of work do prescribe because.

Lean, which comes from basically the same perspective (while they don't cite exactly the same values as expressed in the Agile Manifesto, being Lean essentially implies being Agile and vice versa) and is a good body of knowledge to draw from alongside Agile, is better in this regard, and so places nominally drawing on Lean seen to be more likely to be doing what they say, because Lean doesn't leave as much of the core vital parts without good guidance.

This is the great con of scrum certification — you can always point to some team and say “well that’s not the official version of scrum”

Which is a really impressive con. Generally the point of certification is to make clear you're getting the official version. E.g., doctors and lawyers self-police because they know it's harmful to have quacks running loose. But somehow Scrum has been able to keep making money despite not bothering with that.

This. I've run programs that purport to be agile but the work input stream was waterfall and disconnected from the means of output so it was really timeboxed waterfall, unfortunately my management did not agree to re label. You know it is real Scrum if it is painful for the business team and they come to realise that now it's software all the way down.

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

This process adjustment usually means "sorry about your vacation" and/or "you aren't doing enough overtime".

Yes, if external actors rather than the self-organizing teams own the process, that is probably the first response, but that won't actually stop the buildup of tech debt and the velocity impacts, though it may produce a one-time, non-repeatable improvement, so even in that case if someone (even the wrong actor) is monitoring velocity and doing process improvement, there will be an impetus for further change.

(Of course, if the wrong actor is monitoring velocity and controlling process, then the team has an incentive to mask the effect of tech debt but continuously adjusting estimates to maintain the illusion of constant velocity, a d avoid the first bad response, or, if that opportunity is missed, to avoid the subsequent external interventions.

>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 senior, I've just gotten more brazen about doing this less sneakily.

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.

There are many 20 years and older code bases currently. But if you start a new code base today it might get rewritten many times in the next few years because software users no longer have the power to stay on an old version due to the SaaS paradigm.

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.

It's like "build one to throw away", in that the goal is to rapidly explore the feature space and discover useful features, but what actually happens is that it's a trap and you won't throw away something that works no matter how poorly implemented.

absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product.

The effective strategy is to build an oblique, fatally limited prototype, which can not possibly be mistaken for a shippable product. The bad prototype can only be used to test the hardest parts of an idea and must have major holes in it with no way of filling them. It should also have a largely fixed timeline to ensure it is put to bed before it gets "hamstered" into the shipping product.

absolutely. If you ever see a group afraid to produce a prototype, it's because they're afraid management will try to ship it as a final product.

I once had a manager who, on the subject of upper management wanting to ship the prototype, would say “the difference between dev and prod is one letter.”

You're confusing "investing in design" with "having a design phase". I agree many Agile teams underinvest in design. But so do many non-Agile teams. The problem isn't the lack of a formal phase. The problem is not taking it seriously.

You get what you measure and Scrum has no measure at all for design. I’m now curious to see some projects that Ken Schwaber worked on.

I'm certainly not defending Scrum. But I think one of Scrum's big problems is relying on proximate measures rather than actual results. It values output much more than outcome. So I think the way to get good design isn't to try to measure design. It's to release early and often, making sure that products fulfill their purpose.

I think our whole industry is full of proxies for the things we actually care about, which is for instance why we rant so often about the hiring process.

For another example, look at what we talk about with Clean Code or SOLID principles. We have that old joke about the two hardest things are naming things, cache invalidation and off by one errors. I think the fourth hardest one is resolving merge conflicts.

You work carefully on code for weeks or months and then in one fell swoop it all gets broken when you aren't looking at it anymore. It's really bad for morale.

If you read through all of these Best Practices with the notion that merge conflicts are dangerous, then you start to see them as designed to keep conflicts from happening. Putting related code together isn't just about reading comprehension. It's also about keeping unrelated code apart. You and I can work on unrelated stories without ever doing a 3 way merge.

And if you look at merges as the problem, you start doing things like alphabetizing data structures that don't have a strong cohesiveness to them because then when you and I add a feature to the same data structure, we aren't both modifying the bottom of the file. I put something under T and you put it under G.

To put this another way, if in some perfect future someone invented a merge tool that never screws up, so that we only get merge conflicts when two people are accidentally working on the same feature/bug, we might start to question all of these practices as overwrought.

Yes, you're correct... I didn't mean a "formal" phase, so much.

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

It doesn't lack a design phase. Where do you get this information from? It isn't explicitly prescribed, but no one prohibits you to make designs.

Experience. I've been developing software for 20+ years. In practice, due to the nature of agile / scrum, design is very minimal or thrown out the window entirely. It encourages short term thinking. Rarely is anything beyond the "current sprint" considered.

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed.

Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

All straight out of the TDD playbook.

A lot of devs trap themselves by insisting they can write the tests after. Once managers know the code exists they want to use it, or move on to the next thing people are breathing down their necks for. And code written without tests is difficult to test so becomes a self fulfilling prophecy.

In fact it’s such a reliable mechanism for self sabotage that I look at carefully at people who bring this on themselves and try to figure out if it’s naïveté, learned helplessness, or malice.

As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.

> if we're going to think of ourselves as professionals

We need to unify around these principles, possibly revoke memberships for unprofessional behavior. One dev getting himself fired changes nothing..

I'd love to see that kind of organizing happen.

But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward.

I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.

Scrum is unsuited to actually building a decent framework for you application.

We tend towards 4 or 5 sprints in which nothing is completed, only to suddenly have a flood of completed things the next.

Then that's not an Agile process. That sounds more like mini-waterfall.

It's perfectly possible to deliver small units of work weekly. One still gets frameworks while doing that. It's just that the work of making the framework happens over time, not up front. Which is good, because good designs are based on good information, and the beginning of the project is when you have the least information.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact