End Scrum Now | Hacker News Reader

End Scrum Now

endscrumnow.com

37 pointspastafooyoung26 comments

> Hiding behind processes like scrum will not save you. Even in the best case scenarios, enterprise shops and startups are faking progress by breaking user stories into tiny little pieces or simply working stories over many sprints "are we there yet?", dragging out timelines for simple work to obscure the fact that the teams are lost, the business people are clueless, and developers are disinterested

This seems to be its own rebuttal. If no process can save a bad workplace, why is killing off Scrum going to make things better?

At the very least it would show that the team is willing to change. I work with one team that is absolutely convinced that work shouldn't be planned more than 2 weeks in advance. They have had a goal to produce a product for the last 2 years that there is practically zero progress towards.

But scrum doesn’t say “don’t make plans” it says “be prepared to change plans”.

You can (and should) still keep long term roadmaps, track progress towards long term goals and so on. A situation like the one you describe is one where you’d prescribe a methodology, be it scrum or something else, because the team seems to lack one.

Because, as they say, Scrum is used to mask the lack of progress, and so the underlying problem is not addressed. If you took away the curtain people would be forced to confront what's behind it.

If a troubled workplace’s response to its troubles is, “might as well do something, who cares if it works”, that’d at least help explain why it’s troubled.

That seems like a better plan than “let’s do nothing.”

I'm not a fan of scrum but.. wow this is a horrible argument.

There's so many things that aren't backed up with any facts. It's just a list of random Bad Things™, and somehow scrum gets blamed for it? I have no clue how developer mentorship being nonexistent, for example, has anything to do with scrum.

Hey, it's tough. Engineers need both autonomy and guidance to get things done, and the balance isn't easy to find. But just throwing false accusations like wage suppression doesn't fix the problem... I think the author just needs to find a new job.

> Unfortunately agile processes simply ... [prevent] others from realizing until its (sic) too late that you have failed.

Uhh, literally the whole point of agile is to realize as soon as possible if you have failed / are going off track. Either you're delivering value or you're not.

Sure that's the idea. And if something is broken each member has "agency" to fix it to make it work better.

In reality it's only the people who have been given clout can fix it. And some members are too inexperienced to know how to anyway. Also you generally can only fix your level, but if you're lucky provide input up to the next level. Often devs can't even do that because management is narrowminded or have no agency to make change.

If the rails have gone off two levels above you or higher, no amount of scrum can fix that.

Okay, so we end Scrum… now what?

I understand the frustration. Even as a manager I can feel some disconnect. This series of assertions is this person’s observations.

It seems both one-sided and purely deconstructive. Even if it’s right, does ending scrum now actually produce fixes to this list of complaints?

Why not “fix scrum now” and a series of adjustments? This reads like a sophomore engineer that’s disgruntled more than a seasoned engineer trying to fix broken process.

Again, it’s easy to agree with a lot of it, but fixing it is harder than just stopping.

Scrum is and has been a buzzword for a long time where its ideological constraints have rarely been realized in full (i.e. No True Scrumsman) but this article doesn't really suggest what to do instead.

Devs can't live in a vacuum, and a world where managers exists means that some itemized process which can estimate and organize planning and development will always be needed in the current heiarchy. Obviously whether that heiarchy is useful is a good question, but a different story altogether.

In my experience the problem with Scrum is that people are not able to implement it correctly. So maybe it's biggest flaw is that is not easy to understand for the people who has to follow it...

But I have to say that once I had a really good scrum master. He was extremely strict with telling the product owner and so on that a story can't go into the sprint if it's not 100% ready and also telling developers to not accept one story too much if they are not completely sure to finish within the sprint.

What happened is that product owner and other business people didn't like this guy because they felt he was stopping progress, but from my point of view, before him they were running in circles reworking the same features with things they forgot but they didn't realize. I felt totally the opposite. As a developer I was always finishing all my tasks without stress and high quality, reducing the amount of bugs and forgotten features, and I had time to help other teams, for instance the product owner himself, to complete their tasks better.

Guess what: This scrum master was an ex-developer

I would respond better to more reasoned arguments. This is largely a series of assertions.

Assertions that resonate with the experience of a large number of people, I imagine.

> Scrum ceremonies become more inane and waste development cycles

This is plain wrong. "Scrum ceremonies" have not changed since the introduction of scrum. Still the same: three roles (now called accountabilities), five events, three artifacts.

Scrum is about coordination, both within the team and between the team and those who pay it to build stuff. If everything is already well-coordinated, then by all means, stop scrum. Only it usually isn't.

Part of the problem is that many engineers need management above them. On the flip side most non technical people have a hard time managing engineers since you're basically managing someone who's work you can't evaluate/see.

At Stream our lead and director level hires have to be technical/ actually contributing code. I still definitely see some of the issues this developer complains about though. It's hard to avoid.

I don't think all of them are scrum's fault. Basically, this sounds like a failed scrum. There is succeeded scrum sample as well. Scrum is never easy. Just like developers get certified, scrum master certification is just a paper. Need years and years of experience to get it right.

> Basically, this sounds like a failed scrum.

Any time someone points out a process is bad, it's possible to say 'well you're not doing it properly' rather than addressing why people may so often end up not doing it properly.

It’s a good point but I think there isn’t a better answer. Teams that fail miserably doing scrum would fail in any process. Software development is fantastically difficult. Doing it well is reserved for a small minority of teams and no process will save the others. What scrum offers is the early exposure of failure.

This sounds a lot more like someone who hates their job/workplace and hasn't yet figured out the real reason. Pretty sure it's not Scrum.

This needs an update now that the hyper enterprisey SAFe has joined the fray: top-down agility still is the perfect anti-tautology!

> Teams produce less working code

I write code for living, and I want to produce as little code as I can. That's also part of the agile principle, produce what is needed.

> Scrum ceremonies become more inane and waste development cycles

The complexity of a team is greater than just its output. I don't know the context of the ceremonies, but sometimes reflection on what has happened is important, and definitely the planning part sound important.

> Lower quality code is produced, more slowly

Ummmm what? There might be an argument to be made about not having a design document which maps out the entirety of project but code quality is based on best practices, testing etc.

> Software engineers enjoy less and less career satisfaction

Really! This one is hard to digest, if you expect satisfaction to come from external sources then that's going to be a problem. But what is career satisfaction, I have not worked for one company where someone is satisfied by all the processes.

> Product knowledge is lost over time > Process knowledge is lost over time

Yeah that's a general problem, for all types of project and product management.

> Developer's wages are being suppressed by forcing them to report to low paid laymen with Scrum certification

At least it's not an argument blaming offshoring.

> Scrum planning and grooming never produce anything close to predictable velocities or deliverable dates even after years of scrum on the same team

I doubt even almost all projects pass the three tiers of development, on time, on cost, bug free. This is not unique to scrum.

> Scrum masters who are mostly unqualified laymen, treat developers defensively and increasingly with hostility

Given the tone of the site, I see hostility is no unique to scrum masters :)

The majority of the rest are not failings of scrum, rather process failures. If you have a Scrum master who is writing tickets or not enforcing ticket structure which leads to those tickets missing vital information, you can point your finger straight at the scrum master. I had this situation with a product manager and after a cordial conversation, the tickets change, then they went back to not writing them correctly. That was not a failure of scrum.

This article is bad.

but it makes some good points.

What would you consider there a good point?

> Managers become ghosts and do not work with developers or really do much of anything

This is probably the only good point of the article :-) Managers aren't a part of the scrum framework; so if scrum is running smoothly, managers gradually disappear from the scene. I'd say it's a feature.

Reply on news.ycombinator.com