In some cases having a formalized process/methodology helps to appear professional and hide the fact that nobody knows exactly what they're doing. I've seen it it some place - very serious software dev company delivering very serious medical software, but in fact the whole team was just faking it and trying to keep up the professional image. The developers were random people without business domain knowledge, managers were managing the work without understanding it, analysts were producing some documents that nobody understood, customer approved some scopes hoping that the specification is actually what is needed (but in vain). The team was assembled from contractors, and people rotated quite frequently so that there was no chance for them to acquire the domain knowledge necessary to talk to the customer. It was just painful to take part in it, but took me some time before i realized in fact everyone is just pretending to understand what's going on. Endless approvals and multi-step procedures required for medical stuff just made the whole thing impossible to understand and smeared the responsibility so broadly that it was guaranteed there's no single person that knows too much.
Scrum is a cancer
171–180 of 486 posts
Re: Scrum is a cancer
#172Some of this is due to Scrum but other parts of it would still exist in these companies even if they changed to Kanban. I think the problem is the kinds of companies that have these processes can't find an alternative. The companies I've worked at where it was like this were all sales-driven enterprise software where deadlines are the focus and being able to tell a customer it'll be there in X months was viewed as critical. So they put all of these processes in place to make sure they can consistently hit deadlines even if it means slowing everything down to a halt. It still doesn't work that well but just removing the process isn't going to work without changing how the rest of the company operates too.
Re: Scrum is a cancer
#173I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement. The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
I'm also very surprised by what the overall thread is saying.
Scrum and the agile movement in general have been a revolution for the better in management and organization, in my point of view.
Re: Scrum is a cancer
#174Six of the nine points is about estimates and I agree. And depending on who you ask estimates is or is not part of Scrum, but that doesn't really matter... you shouldn't be spending too much time of them and if your organization requires detailed estimates they simply don't understand "agile" and they are doing "Agile". The absolutely worst thing that I've experienced was the "story point budget negotiation" ... that is not how any of it works.
Re: Scrum is a cancer
#175I'm going to get blasted for this, but you *are* doing scrum wrong. Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong. Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have giv…
Agree, but the warnings are for management, not for you. What do you care whether something's finished? Shoulda hired more interchangeable devs or lowered the expectations.
Re: Scrum is a cancer
#176Earlier quoted context omitted.
This, and more. Like it or not,the incredible success of software made it an industrial affair, the way clothing industry went 200 years ago - from highly skilled artisans creating unique beautiful designs tailor specifically to their customer to cheap patterns industrially printed. Its just that the printers are still human.
So sweatshops basically? Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
Yeah, very comfortable sweat shops for highly paid manual laborers. Why do you think open seating plan exists?!? Open plan is the default layout of a standard sweatshop.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
Re: Scrum is a cancer
#177I'm going to get blasted for this, but you *are* doing scrum wrong. Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong. Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have giv…
Not only I'm not blasting you but also I'm right there with you. I've always said that Scrum doesn't fix problems, but it makes them more evident so you can fix them. Teams that don't realize this are going to be unhappy about Scrum, but in my opinion they wouldn't be happy without. Often the problems are one of these: - Focusing on estimates. In scrum, a team doesn't really need any estimates beyond planning what th…
Sorry, but that's a catch-all defense. You're either doing too much Scrum, or not enough, and if it's not working you're doing it wrong. But the Party is always right, no matter what! Read our manifesto and attend some certificated training.
Re: Scrum is a cancer
#178Agreed, however;
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum.
> Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
Out of all the bullshit that makes up Scrum and (what has become) "Agile", this is the one that clogs the toilet. I can imagine a world where this idea of "complexity, not time" is done properly, but it's not this one.
Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can't tell it's part of a process, because it's all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
Re: Scrum is a cancer
#179The worst part of Scrum/Agile is that you formalize everything. Reducing technical debt, improving CI/CD, research and innovation sprints..
Oh, you fixed a typo? Where's the ticket for that?
Until, of course, the things you want to improve are never in the sprint and you have no free day to tackle anything you want (and the project needs), ever.
Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
Re: Scrum is a cancer
#180Earlier quoted context omitted.
If you don't already have a clear spec for what your code needs to do, it's essentially doubling what you need to code for no real gain.
I'd argue the opposite: If you already know _exactly_ what your code needs to do, you can "just implement it". I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
All of the methods mentioned are based on a reasonable core. It muddles the waters and make the snake oil marketing - the "this is the cure to it all" discourse - harder to dismiss. Testing is good. Planning is good. Discussing the project is good. But these things are beside the point of op. The point is, these cargo cults are designed to make consultants money. Now they have a lot of inertia because people grow up on it.
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.