Scrum is a cancer

https://twitter.com/svpino/status/1695806027256475777

by curiousgeek • 3 years ago

324 467 3 years ago

twitter.com

billy_bitchtits• 3 years ago

My company bought into the SAFe bullsh*t and it’s awful.

j456• 3 years ago

Is there an alternative anyone would recommend.

It might not be the best question to ask given the complexity of the software and experience/culture of the team.

rhaway847732• 3 years ago

Personally, I think SAFE or Agile/Scrum are good starting points.

The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.

The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.

The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.

davidhyde• 3 years ago

It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer.

Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.

convolvatron• 3 years ago

This is a very unsatisfactory answer - but you have to grow a culture. Working with people to match their personal goals with organizational goals. High degree of mutual trust. Cooperative design. Group ownership of the codebase and rotating responsibilities. Lack of 'magic knowledge'. Sufficient infrastructure development to reduce rote workload on developers.

All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.

That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.

cpeterso• 3 years ago

There is no best approach, but this article highlights some common aspects from a survey of 100+ tech companies’ approaches to project management:

“How Big Tech Runs Tech Projects and the Curious Absence of Scrum”

https://blog.pragmaticengineer.com/project-management-at-big...

bonestamp22• 3 years ago

We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today.

It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.

Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.

This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.

We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.

crdrost• 3 years ago

I developed an alternative called “Hot-Potato Agile” while at Google. I got buy-in to try it, but then was laid off in January just before we could start. So if you have a team that likes sprint cadence but hates the scrum busywork and is open to an experiment, let me know! I still want to flesh out this thing’s rough edges.

rhaway847732• 3 years ago

Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”

readyplayernull2• 3 years ago

Anecdote: When Intel's stock kept falling early this year they had to quit SAFE to speed up development... a bird said.

ww520• 3 years ago

I look at the typical SAFe framework and laugh. https://scaledagileframework.com/wp-content/uploads/2023/03/...

SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.

Consultants love it!

brucenanner• 3 years ago

I know for a fact engineers on my team that called me crazy for thinking scrum is snake oil sold to management will upvote this.

psunavy035• 3 years ago

Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere.

Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.

I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.

alphazard• 3 years ago

Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.

If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.

Tehdasi• 3 years ago

They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.

They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.

psunavy035• 3 years ago

This is like complaining that because the shittiest sports team you follow doesn't win that playing that sport well is ipso facto impossible.

tasubotadas5• 3 years ago

The guy in the Twitter pretty much mentions every red flag implementing scrum.

What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?

idlewords• 3 years ago

This is a No True Scotsman argument. The guy enumerated a list of ways scrum failed in his experience; it's always interesting to hear honestly about failure modes from people who have actually used something a lot in their work.

psunavy035• 3 years ago

It's interesting to hear about failure modes, and anyone whose job it is to teach stuff like this is interested in hearing about failure modes. It's the taking of one person's experience and extending it to encompass everything that's wrong.

Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.

But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.

theshrike7911• 3 years ago

The same thing works the other way. People see and experience shit Scrum and then they No True Scotsman it to mean that all Scrum must be shit.

It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.

The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.

ipaddr2• 3 years ago

Are you a scrum master and feel personally slighted that the popularity is slipping?

psunavy035• 3 years ago

And there's the typical internet argument!

"I disagree with you and here's why!"

"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."

boppo1• 3 years ago

How do I avoid this in my career?

yesbut3• 3 years ago

Call it out as BS when it comes up in discussions. Spread the word. Stop going along to get along.

tacitusarc2• 3 years ago

In a large organization, this will change nothing. All you can do is be in a trusted position with upper management, and spend your political capital to prevent it. Even then, it may not work if some exec has implementing it as a goal to help their prestige/career.

semireg• 3 years ago

I’m a solo consultant and have had many good client relationships based on agreeing on deliverables. To summarize according to the old “pick two” adage of delivered-fast, works-to-spec and cheap: I’m fast, reliable, and expensive. I deliver high value and I’m always available to answer questions.

Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.

So there’s another way to avoid agile and scrum: solo entrepreneurship.

Good luck!

amai2• 3 years ago

Become a data scientist. They don't do Scrum.

Racing0461• 3 years ago

agile is fine (ie delivering features incrementally) but the scrum process around it is useless.

zug_zug• 3 years ago

Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.

The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).

You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.

knodi123• 3 years ago

Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.

dopidopHN• 3 years ago

I had a team with a shadow backlog. Fun times

holistio• 3 years ago

I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.

foogazi3• 3 years ago

Our team gets publicly dinged if we "carry over" tickets between sprints

This is not part of scrum

jatins• 3 years ago

You'd be surprised at how many places this is.

At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!

[0] Just writing that sentence makes my eye twitch

hiyer• 3 years ago

It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either: 1. The team is not breaking down tasks granularly enough, or 2. They're not estimating tasks correctly

Practically, it means nothing of course.

Camisa• 3 years ago

Great time to tackle some tech debt

marcus_holmes5• 3 years ago

Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.

hereforcomments• 3 years ago

I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.

marcus_holmes5• 3 years ago

This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?).

It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.

We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.

Such a waste of time and talent.

tamimio5• 3 years ago

I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.

That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.

some_guy_in_ca• 3 years ago

As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.

tuckerconnelly• 3 years ago

From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.”

I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.

[1] https://tuckerconnelly.com/management-leadership

PartiallyTyped2• 3 years ago

Our team is the only one not doing “scrum” or estimates or shit. Our team is the only one far ahead because we don’t waste our lead engineers’ time and allow them to move at their own pace (that means very fast). I just have 15 minute dailies with the other senior and the manager to stay in sync.

jdougan• 3 years ago

While I too despise Scrum, the causation could be runming the other way: the Bosses that have a better team could be more likely to let them run without major pressure.

intelVISA3• 3 years ago

No love for Scrum but this is the more likely explanation.

A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value.

Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.

marcus_holmes5• 3 years ago

The people who implement Scrum are insecure managers. They don't understand the development process, don't trust their staff to just get on with it, and need constant reassurance that their project/product is making progress.

So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.

koonsolo• 3 years ago

44 yo dev here. What I've seen from managers is that "letting go" is more of a personal trait than an external force.

Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.

SergeAx• 3 years ago

What if the boss gets a wake up call from bank, saying they are out of funds to pay team salaries, first?

guytv• 3 years ago

During a certain phase of my career, I was part of a company that extensively used the Scrum framework.

My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.

This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.

baal80spam4• 3 years ago

I re-read Peopleware this last weekend. It's one of my favourite books on the topic of software management. There are chapters that are not very useful for the $current_year (eg. regarding telephones or office furniture) but overall it's a fantastic piece on human interactions in the industry.

disintegore• 3 years ago

Scrum gives me the same impression as liberal economics. An intellectual tradition centered around quantifying things that can't reliably be quantified, as well as projecting incomplete models on top of reality in service of economic interests and insisting that they are correct.

drpixie• 3 years ago

Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.

Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)

Just stay away from it, if at all possible.

daliusd• 3 years ago

Putting Agile and Scrum in the same bucket is right only if you know only waterfall in your comfy corporate/government job

computerdork2• 3 years ago

agreed, Agile and Scrum are not the same, and if you read person's followup comments, even he says "he believes in Agile" but hates Scrum.

Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.

alex_lav• 3 years ago

If you're in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you've already lost.

3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.

tacitusarc2• 3 years ago

If you’re going to have lots of unnecessary meetings, it’s important to keep them short or no one will have time to do work.

gorgoiler• 3 years ago

Clever management technique in a shop full of blunt knives will only get you so far.

With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.

Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.

ggm• 3 years ago

Scrum puts "feel good" limits around the unknown qualities of time-to-complete and "divide and conquer"

You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.

Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.

I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).

Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.

dancemethis2• 3 years ago

Then the individual goes on the dumber-than-life anti-communist rant. I love how he tries to create a bunker with "if you disagree you're into Scrum".

I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.

Hamuko• 3 years ago

The individual was born in the unitary Marxist–Leninist one-party socialist republic of Cuba and lived there for a bit under three decades. He might have some expertise on the topic.

gedy3• 3 years ago

I agree it's rarely "done right", but I've been in career long enough that waterfall was still common early in career and horrible crunch time targeting some date at end of 9-12 months projects was inevitable - Scrum was a total breath of fresh air back in 2005-2006 and saved my sanity.

Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.

I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.

gedy3• 3 years ago

I should clarify: we had one of the early Scrum guys (Ken Schwaber) come in and train devs, QA, UX, and management - so there was little room for people to hide behind random interpretations of "agile" and it really helped us to start out correctly.

theshrike7911• 3 years ago

"pushing devs to overcommit to each sprint"

Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.

If your sprints continuously fail to deliver, then you need to decrease the team's velocity.

gedy3• 3 years ago

Yeah it was really messed up - their "velocity tracking" was so they could make sure devs committed to at least as many points as the last sprint, even if they didn't finish the last sprint.. I only lasted there 4 months before I quit.

mwint• 3 years ago

I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams.

I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process.

Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.

Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”.

But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.

I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.

But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.

xyzelement• 3 years ago

I agree with this. In my experience: these "rituals" are a way to force the conversations that a "senior" - in your terminology - dev would naturally have.

beardedwizard3• 3 years ago

I really appreciate this take and the sibling comment. Exactly. See what good is there, move on about the rest.

lafar65032• 3 years ago

But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? I dont know Scrum to comment on it, but many management methods converge to 'appear that work is done all the time even if it's just meaningless bureaucracy, make everything slow and inefficient, but manage the expectations - so customer is moderately disappointed all the time but there are no catastrophic failures. And make sure there are no red lights on the dashboard, ever.'

theshrike7911• 3 years ago

I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.

The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.

You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings.

Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.

But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly.

A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.

wqtz• 3 years ago

I have been taking a closer look at project management and product management in the last few months. Coming from the programming side, I thought technical product manager rule the world, and thought everything that is technically led is glorious.

Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong.

Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.

About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas.

---

He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.

ddalex2• 3 years ago

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.

dilyevsky5• 3 years ago

Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders.

And turnover you will have! =)

Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.

Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.

jjav• 3 years ago

> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them.
The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.

It's harder than finding uncaring juniors, sure.

But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.

In silicon valley money, you'll need to pay those uncaring juniors about 150K.

I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.

If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.

tamimio5• 3 years ago

The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.

That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.

Foobar8568• 3 years ago

I would fully agree with your point if I weren't regularly in daily were nobody listen to what being said : e.g. discovering by themselves what was said the previous day/week as it was a new piece of important information to share.

nivertech• 3 years ago

https://news.ycombinator.com/item?id=37134050

Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.

touisteur• 3 years ago

I'm also wondering whether using Scrum somehow makes your team become this dysfunctional COBOL programmer team...

poulsbohemian2• 3 years ago

So funny thing... about twenty years ago I was managing a project with Cobol developers on one side, and this web thing on the other. And we had a bunch of business people convinced we were all stupid and lazy, so they wanted to force us to do this scrum thing. We would do things like a daily standup with them in order to go through the motions, and then we'd have the real meetings once they left us alone. Because the problem wasn't that the Cobol programmers were dysfunctional, it was that the business refused to actually listen and understand anything - they just wanted to make edicts, even when they didn't understand the regulations or processes in their own business (this being a highly regulated industry...). I pulled off what was perhaps the first project in that company's history that got delivered on time and met its requirements (and it was a big flipping deal of a project...) and the business people took credit for it and I got overlooked for promotion and life went on.

thunderbong• 3 years ago

The reply to that comment is also valid, IMHO

lowbloodsugar• 3 years ago

99.9% of “Scrum” you’ll come across in the wild is cargo cult. People performing the ceremonies with no fucking idea why, in the hope that the giant eagles will come from the sky bringing gifts.

Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it.

So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail.

Scrum is a fantastic canary.

shortcake27• 3 years ago

I once worked at a place that did Scrum for the exact reasons you mentioned.

Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did.

We also had our work planned out 6-12 months in advance.

It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.

travisgriggs• 3 years ago

Ok, this totally resonates. What I want to know is how I find a place to hang out with those 5 other devs.

I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.

andrei_says_• 3 years ago

I love https://basecamp.com/shapeup approach - tiny teams with high independence and sufficient domain knowledge working in six week periods to deliver features.

And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O

littlestymaar• 3 years ago

taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.

Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers.

Most of us here are not in that category. […] For us, […] is useless.

It's not just useless, it's actually harmful.

But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision

But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run.

They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.

PeterStuer2• 3 years ago

It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys.

It is an assured loss for all.

Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.

kelseyfrog• 3 years ago

The Netflix Culture deck[1] acknowledges that this strategy requires "top of market compensation." What percentage of organizations have the ability to pay top of market compensation? The answer to that is the reason why the strategy doesn't generalize.

1. https://igormroz.com/documents/netflix_culture.pdf

poulsbohemian2• 3 years ago

taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them

That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.

The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.

Shorel• 3 years ago

The thing is, IMO, everyone has a hiring problem.

It is very easy to hire one bad player, and he takes the team down, and (in most jurisdictions) it is hard to lay them off.

The reason is, no one who knows what it is required, wants to do the hiring.

EVa5I7bHFq9mnYK• 3 years ago

I have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.

rightbyte3• 3 years ago

Ye God I hate "chain of command" places. "Need to know basis" is the most toxic leadership type there is. Since my conscription it instantly makes my blood boil.

You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.

mkl95• 3 years ago

I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.

If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.

jillesvangurp• 3 years ago

Been on both sides of the equation as well over the past three decades. Two observations.

1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky.

2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry.

My strategy for containing this madness:

1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles.

2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it.

3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall.

4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working.

5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high.

6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient).

7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.

binary132• 3 years ago

Most companies want to minimize salary while managers and directors are highly incentivized to maximize headcount. It’s very perverse.

kelnos3• 3 years ago

But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.

I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.

I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.

hugozap• 3 years ago

I've personally never been in a project where I've felt that the team was doing well thanks to scrum but in spite of it.

foogazi3• 3 years ago

Scrum is not for developers; it's another tool for managers to feel they are in control.

Bad managers would certainly like to do this but this is not what scrum is about

throwaway4good• 3 years ago

So what is an alternative process?

u801e2• 3 years ago

Kanban is one alernative[1]

[1] https://en.wikipedia.org/wiki/Kanban_(development)

baal80spam4• 3 years ago

My question is - how DO you convince management to let you try Kanban?

We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".

Denote67372• 3 years ago

Spoken like a true scrum master.

You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.

wtcactus• 3 years ago

You absolutely do. If you are going to critique something, be sure to present what's in your view a better alternative, otherwise what's the point of complaining about a way of doing things other than being negative?

computerdork2• 3 years ago

I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile."

Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.

hliyan• 3 years ago

I once blew a team's mind by this simple demonstration:

1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references.

2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.

_19qg• 3 years ago

https://agilemanifesto.org/principles.html

Read through the principles and then find out how it maps to scrum.

Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.

continuous delivery of valuable software
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

That's a sprint in Scrum.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)

and so on.

hw• 3 years ago

I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.

Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’

theshrike7911• 3 years ago

This is the correct answer.

Different teams get by with different amounts of Scrum Processes.

Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.

When the team gets better (and there isn't much turnover), you can relax the Processes.

I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)

telltruth• 3 years ago

Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during those days was XP or eXtreme Programming.

Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.

Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.

This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.

I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.

The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.

So exercise caution!

raister• 3 years ago

Their most aggressively marketed prescription was scrum.

I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.

smaudet• 3 years ago

I think even a tier-1 team could make it work for them, but the key is they would make it work for them (make it their own process).

Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).

The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).

But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.

avinassh• 3 years ago

What's wrong with TDD

HideousKojima• 3 years ago

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.

rightbyte3• 3 years ago

It is dogmatic.

mpweiher• 3 years ago

Er, no.

First, Scrum is not XP. Huge difference.

Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).

Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.

Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]

The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.

[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...

replyifuagree5• 3 years ago

The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company.

Nailed it.

anticristi• 3 years ago

Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let's do it first and fix it later. Later never comes.

I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.

Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"

Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.

beardedwizard3• 3 years ago

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

tasubotadas5• 3 years ago

The guys here come to the scrum retrospectives, stay silent the entire time, and then complain that scrum sucks.

beardedwizard3• 3 years ago

Too true, seen it so many times.

beebeepka• 3 years ago

Or maybe they have tried speaking out, only to be chewed and digested for daring to raise their voice. Life is not black and white

marcus_holmes5• 3 years ago

Tried saying "this process sucks, can we do it better?". Was told that Scrum is what all organisations use, there's nothing else (except Waterfall), and that this is "best practice".

The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.

ahtihn2• 3 years ago

I think Scrum done well works rather well but retrospectives tend to be a lie.

Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.

If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.

Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.

Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?

Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.

xedrac2• 3 years ago

I've spoken up in many retrospectives, but when nothing changes, it's hard to take them seriously. What's the point of a retrospective if your feedback is simply discarded?

xedrac2• 3 years ago

I'll be the first to admit that managing a complex project's timeline is not a skill of mine. All I know is that the franken-scrum monstrosities that I have been subjected to in various organizations have all had a very negative impact on my morale and productivity. The problem I see is that the the business will want to make tradeoffs that the developers may not like. How you reconcile the two without hurting morale is the challenge. I left my last company largely because their version of scrum was sucking the life out of me.

RayFrankenstein5• 3 years ago

My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.

And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.

mrfumier• 3 years ago

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.

tamimio5• 3 years ago

then take the good from the bad as a source of constant improvement.

I worked as an engineer, PM, and a manager, when I was an engineer and scrum was applied wrongly, I tried to communicate for that “continuous improvement”, but that only works with an actual leaderships that listen, 99% of your middle management are just power hungry folks that are kept in their positions to take the shit instead of senior managements, when I worked as a PM however and tried to customize those agile tools per project and per team personalities too, everyone was happy, projects got delivered and things worked as expected. In 90% those situations you can never blame the engineers, look at the work environment as a workshop, the guy working in that shop is the PM and the tools are your engineers, ultimately that guy is accountable for the success or failure to deliver that work, if you start blaming the tools you have in the workshop, then you are the incompetent one, simply put.

makstaks• 3 years ago

I have delivered successfully projects using Scrum, but we were fortunate that our Scrum Master was well trained and a senior engineer. Our CTO also let us figure things out, and helped us when we were blocked. He was genuinely concerned with the team having a balanced workload, ensured we deliver user value and our software was of high quality. Story points were not used as performance metrics but a tool to help provide stakeholders with some estimation, but only when our velocity became stable. Overall, our process was light-weight, we spent most of our time coding, and we pushed hard to deliver value to the user. If we fell short, we learned from it, no blame, just learned.

Denote67372• 3 years ago

I work for a web dev firm in the infrastructure team.

They are trying to apply scrum and agile to us. It is not working.

I've been told ot to work on anything without a ticket. Outages have gone up.

It's a disaster.

CodeCompost• 3 years ago

Any good alternatives?

g9yuayon• 3 years ago

I'm not sure if a process can be a cancer. Instead, an institution that uses processes, Scrum included, to hide their ineffectiveness and inefficiency is.

braza• 3 years ago

Removing the OP energy of "enrage to engage", I think there's a room for a more nuanced position.

It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment.

However, after 22 years of Agile/Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.

joos3• 3 years ago

To read without logging in to Xitter: https://nitter.net/svpino/status/1695806027256475777

tasubotadas5• 3 years ago

It's sad that posts like these get so many points.

A sad take that's based on a sad experience with a great framework.

strictnein• 3 years ago

Anecdotes #6 and #7 in their list is a real indicator of something bad, wholly unrelated to Scrum.

#6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
#7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.

emilio1337• 3 years ago

Assume you need to build a chair. You barely have seen a chair in you life. You would naturally start naively with a first approach. That will fail to carry a person at first. But as your approach advances you’ll gain experience and eventually you will build the chair after some while.

That is my understanding of what people name scrum or agile. A management harness with fancy words. The real benefit is when you let people do their work, gain experience and make them self organize their problems.

davidw• 3 years ago

I don't have a lot of strong feelings about 'process' stuff, but boy do I loathe self-important sounding talk like "ceremonies". I was explaining some work stuff to my mom, who knows BS when she hears it and I could practically hear her eyes rolling over the phone when I mentioned how they had started calling things "ceremonies" at work.

Things like weddings, graduations and funerals are important moments in life that cultures all over the world honor with ceremonies of some kind. Your quick morning meeting to discuss what you're working on isn't a @#(#(#( "ceremony".

superfrank2• 3 years ago

I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints".

If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.

I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.

PloufPlaf12• 3 years ago

Thanks for pointing this and I don't believe this is a minor point. I'm managing multiple teams - I was a developer - and I consider the "long" time perspective as a product quality technically speaking and also the team health. And a sprint is not compatible with those two last points where at the end of a sprint everybody in the team rush to deliver the user story and everybody is exhausted or tired...

RayFrankenstein5• 3 years ago

From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README....

“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.

I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.

I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.

I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...

RayFrankenstein5• 3 years ago

Another from “Agile In Their Own Words”

“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832

knallfrosch4• 3 years ago

Bonus points for starting and ending sprints with meetings instead of work :)

lispm• 3 years ago

If the word (sprint) is a problem, then change it. Call it "iteration", "segment", whatever.

Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...

A software development project of several months is not a Marathon.

I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.

superfrank2• 3 years ago

I agree that a word is just a word and it can easily be changed. That's why I called it a minor issue. I think my issue is more that if we have a framework where part of the framework is named after something that is not unsustainable long term, it makes me question the goals and intent of the people who created it. I have to ask myself, "are we using this in an unintended way".

It's like if you came to my house and asked for a towel and I went, "oh yeah, use my butt towel". Just because it's called a butt towel doesn't mean it's actually got anything to do with a butt, but you're probably going to be a bit uncomfortable until you understand why I'm calling it that.

sharkbird2• 3 years ago

Completely agree, it has always bothered me as well. To me it (strongly) implies rushing, and I don't believe that constantly keeping your team in a stressful state where you are always rushing or 'sprinting' towards the next goal is a good sustainable long-term strategy.

mindaslab• 3 years ago

Someone has the courage to speak h truth. I have to finish work within a deadline, or it would look ugly, and I am trying to work today with ill health.

Why doesn't Scrum be a thing for humans? I feel like I'm a robot who has to be predictable all the time.

ivraatiems3• 3 years ago

I'm honestly surprised to see a post with a vitriol-to-insight ratio so bent in favor of vitriol getting such a positive response. I think the poster here is way, way off mark.

It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evidence that he is. (And yes, I get that this post is just a 'vent', but 'just venting' content is not usually the sort of thing I expect to see make the front page of HN.)

I have been on multiple teams, including my current one, where Scrum has been a massive success (as measured by products shipping on time and in-spec with positive reception by customers, as measured by the company making money off my work, as measured by my own and my team's performance assessments relative to my org). Absolutely none of the following happen on my team, or on any team I've been on where things were working in those terms:

We spent more time talking than doing. We spent more time estimating story points than writing software. We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." We paid people who told us whether we were "burning down points" fast enough. We brought professional Scrum trainers. We paid people from our team to get certified. We spent years [continuing to try things that didn't work].

Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum "right" or at all. I've been on three teams in my current organization and five+ teams overall that used Scrum over a period of more than eight years and while all of them had issues, none of them did any of the above. I'm sorry this person has had so many bad experiences, but at a certain point, you've got to ask whether your attitude and approach are part of the problem. I see a lot of things in this person's attitude that make me think they could be.

For example, he makes comments where he just whines about not liking terminology, like:

1. They tried to convince me that Poker is a planning tool, not a game. 5. I had to use t-shirt sizes to estimate software.

He also phrases sentences which are not arguments (or at least, are not really relevant without some explanation) as though anyone should understand why he's mad:

3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

and then finally, spends lots of time asserting (with no evidence) things like:

[Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.”

while simultaneously talking down anyone who tries to suggest he's maybe, legitimately not understanding Scrum.

If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn't work. It was probably never going to.

By the way, this person offers a service where you can pay him to present "learnings" about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See https://www.svpino.com/

RayFrankenstein5• 3 years ago

Testimony from dozens upon dozens of developers that think that scrum is useless, toxic bullshit:

https://github.com/rayfrankenstein/AITOW/blob/master/README....

ivraatiems3• 3 years ago

Data from lots of people who think Scrum is great and love it:

https://www.parabol.co/resources/agile-statistics/#agile-eff...

It's the Internet. You can find a few thousand (or few million) people who love or hate anything.

What's your point?

nvm0n22• 3 years ago

I think the biggest risk to scrum as a methodology is the fact that when it so frequently fails, its defenders constantly fall back on "but that wasn't true scrum". Like, that's 90% of all the posts here defending scrum. Yet the things this guy describes are recognizable to many of us, perhaps it's an extreme case but not that extreme.

pas2• 3 years ago

there's a very strong selection bias. we don't really hear about the cases where a team does so-so sprints, it's not great agile/scrum/paganism, but the product evolves, development goes in an okay-ish manner, and there's just not much to talk about.

the whole structure gives enough support, retros surface problems and give sufficient pushback against "features only, no bugs" management style, sprints gave some sane cadence to both devs and product, daily status checks help to detect folks who are stuck, "refinement" forces both sides to actually commit to some kind of written stuff, and "grooming" provides much needed priorization and black comedy relief as the team tries to come up with a non-pedo expression for the activity.

of course, there are valid criticisms of scrum/agile. mostly that it fails to teach developers to realize their need to set boundaries with regards to interaction with "the client", aaand that most managers and projects are non-ideal, underfunded, and devs should leave it, and look for better ones (even with possibly lower pay).

Spiwux• 3 years ago

I'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 given a middle manager will be missed.

You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.

Nearly every single point in that tweet just screams bad management and bad engineers without any agency.

sklivvz1971• 3 years ago

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 they will do in the next two weeks. Planning poker, story points, estimations are just a means to that end. If you don't like them, don't use them.

- Focusing on ceremonies without understanding how to use them (or when to drop them!). I haven't done stand ups in years. I use online tools like geek bot. Retrospectives are just as useful as the number of problems you actually solve after they are pointed out. Planning is only useful if it produces teamwork, if the engineers all work in 1-person silos, it becomes a joke.

- Not understanding that Agile > Scrum. If you think you can be more agile without some parts of scrum, drop the parts you don't need. Being able to change the rules of the game in-flight is part of agile (and of scrum).

knallfrosch4• 3 years ago

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.

musicale2• 3 years ago

bad management and bad engineers without any agency.

bad management destroys agency

knallfrosch4• 3 years ago

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.

lelanthran2• 3 years ago

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 given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint.

I don't know how you can use both "sprint"[1] and "sustainable" in the same post with a straight face.

[1] A sprint, by definition, is an unsustainable burst of speed. The word "unsustainable" is literally in the definition.

vincentkriek• 3 years ago

This is turning into a discussion about naming, which is important. I think the sprints are maybe wrongly worded, but I struggle to find a better term.

User stories are not actual stories with a plots as well, but the idea makes sense

jredwards• 3 years ago

You're arguing that the entire system is invalid because one of the concepts is poorly named?

bdlowery• 3 years ago

https://news.ycombinator.com/item?id=37134050

Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups.
If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.

replyifuagree5• 3 years ago

Yep, Scrum can't fix bad management!

drewcoo2• 3 years ago

If a cancer is merely something that I don't like and can opt out of, suddenly cancer doesn't seem so bad.

t4356214• 3 years ago

Scrum got popular but it doesn't fit in with most companies imperatives so the management modify or purposely fail to understand it or don't train anyone.

  It's really about teams adjusting themselves to whatever behaviour and process works for them and managers hate not having control. So it's inevitable that any method which gets adopted in name at shitty companies will be "enshittified".

Hence the article has no real insight and is just aimed at generating views with controversy.

bullen• 3 years ago

"Your software should be agile, not your process. Your process should be "disturb as little as possible". Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them."

b800h• 3 years ago

It's interesting. I saw this post after reading today's post about about Jake Seliger, and his brave and philosophical approach to death from squamous cell carcinoma.

The title felt oddly hollow.

floppiplopp• 3 years ago

Personally, I've experienced scrum only as a tool used by middle managers to control developers. It sounds good in theory, but power structures are a thing, and it gives too much influence in the way of metrics to malicious managing types who want to be in control. Scrum and agile are now red flags for me.

lafar65032• 3 years ago

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.

s-lambert• 3 years ago

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

JanneVee• 3 years ago

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

ghusto• 3 years ago

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

knallfrosch4• 3 years ago

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

npteljes• 3 years ago

After 10 years in software development, going from junior to lead, I still fail to see the benefit of sprints. The best performing teams that I have been part of all worked around it, in order to make the team look good, in the eyes of the customer whom we sold Scrum to.

For features, I'd say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum's ceremonies are useful without sprints, and gives, in my experience, the same value to managers as they do in Scrum. The overhead in administration and time that sprints bring are not worth it at all, though. And if management wants, commitments and planning can be done against a deadline, in the same way they'd do with sprints, just without the artificial short periods.

The tweet however contains lots of bad management, and general bullshit otherwise.

"Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." I think this is fantastic, not having a single boss, but having different "hats". One person can also have multiple, for different projects. In my experience, this worked out well.

T-shirt and poker.... I don't see why they don't work as analogies, and therefore this is moot criticism.

Even the author himself acknowledges: that wasn't scrum, they were doing scrum wrong. So stop doing scrum? Why not do scrum better? What makes him think that the same bad management will do any other methodology better?

brailsafe4• 3 years ago

In my last company, when the idea of T-shirt sizing came up, I legitimately thought whoever mentioned it was joking. As if the rest of the excruciating processes, and petulant passive-aggressive behavior of my managers weren't patronizing enough. "Ah yes, now I get it, it's like clothing! I have some clothing right here next to me, now we're speaking a common language"

firefoxd• 3 years ago

My experience with scrum is: metric driven development.

Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a "but you did the other similar project with just 50 points."

The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.

My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.

Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn't reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.

tamimio5• 3 years ago

I probably said it before in a previous post, but the problem isn’t scrum/agile per se, it’s just a tool, the problem is the inexperienced PM who thought just because it was applied in their previous company or another big tech, then it must be the secret formula for success, that, or as OP said, abused by control freak managers to micro-manage the team more, like poor soul I know, they had meetings for meetings..

I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.

brzezmac• 3 years ago

Two employees of a company were suddenly approached by the CEO accompanied by the CTO.

- Death or Scrum? - asked the CEO

The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.

The first one thus replied in a quavering voice: "Scrum"

In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:

- Neverending sprint planning meetings

- Daily Scrums that lasted 4 hours

- The sprint reviews

- Sprint retrospectives

- The backlog refinements

After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."

The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.

"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!

To this the CEO swiftly replied: Death ... by Scrum

freediverx2• 3 years ago

Stop posting Twitter links.

dorinlazar2• 3 years ago

Oh, I so much agree with this!

freediverx2• 3 years ago

Don’t blame scrum/agile for bad decisions made to appease business executives. A product owner’s role is to seek input from stakeholders and then make decisions to satisfy those stakeholders and the company’s business directives.

Companies were making poor technical decisions for short term business reasons long before agile became popular.

The cancer you seek is actually called capitalism.

xinayder• 3 years ago

I went on a road trip with my coworker last week. We were together and he had to attend to a retrospective meeting that was planned to last for 2 hours or so. The stand-in scrum master (their original SM was on vacation so someone stood in) said this would be an unusual retro because they had done 6 or 7 sprints and never did a retro on each of them.

I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:

- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn't believe what we were listening to.

- making JIRA tickets for useless things like "how to install software X". We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.

This is not what happened in my colleague's team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.

This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.

deely3• 3 years ago

I'm not sure whats wrong with second point. Even with super-b detail guide you sometime get troubles/issues/errors that you unable to fix without outside help.

If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people

Irony? Irony..

kelnos3• 3 years ago

The level of scrum-apologism here is I suppose both unsurprising but also egregiously sad.

Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology's fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when "done right".

We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.

bjourne• 3 years ago

Writing software is more like writing books more than anything else. So any process that presupposes that the workload can be divided among roughly equal agents is bound to fail. That's my experience after two decades as a software engineer. Every good software team has two or three engineers who knows how to write books, how to structure a story, and can work towards a common vision. The rest of the team more often than not consists of tag-alongs that don't know nor care about good literature. Every good software project lets these two or three engineers get stuff done. Every bad software project suffocates these engineers with processes and/or makes them quit.

tetrisgm• 3 years ago

Over the past ten years, I've made sure our team's rely on scum and agile less and less. We still have a minimal board, and standups, but that's it. No extra meetings. No definition of done. No stories. We just talk when needed. In practice, any work done to define in the card is likely to slightly change when there's new knowledge anyway. We find our approach substantially more flexible, agile, and stress free.

One of our engineers today said that he felt bad that some of the cards were on the board for so long. He was self conscious about some false sense of velocity that was expected. I told him it's just a page on the internet with some text on it. Scrum, with its frameworks and ideology and self righteous way of looking like a way to be performant and sophisticated, is just some words on a page and some performative meetings. Poor guy was getting distracted by that.

The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There's a culture fostered by executives, consultants, that posits that engineers don't understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it'd also what justifies middle management's jobs.

Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren't predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.

amai2• 3 years ago

Scrum and agile always fails if your company has a finance department. The finance department is never agile an will demand numbers every quarter. They don't care about your sprints. They want a plan for the next quarter and don't care about your sprints or your t-shirt estimates of your Kanban backlog. Unfortunately since they have the money the needs of the finance departments always win over all agile processes you have in place.

No agile book or manifesto ever mentions this issue, because there simply is no solution for it.

replyifuagree5• 3 years ago

Yep, if the CFO has this kind of power the R&D pipeline is essentially being run by an accountant.

Remember when wall street was complaining about how Bezos was running the company? If an accountant was in charge Amazon would have been quarter packing to please wall street, and would be much smaller/out of business.

replyifuagree5• 3 years ago

If an engineering organization is doing the equivalent of laying on the floor and kicking and screaming that they can't do anything, where signs of this include:

* Split up into multiple teams under different kingdom building directors/VPs

* More time is spent defending Jira SLAs and deflecting blame than actually solving problems

* Dev teams under different managers have an adversarial relationship

If the above is true, just adding a standup for a given initiative that includes all of the team members and just normal human behavior of exposure builds a little trust and collaboration is a miracle pill!

Albeit it's a 'miracle' pill that takes the org from laying on the ground kicking and screaming to slowly making code changes that no customer wants - but comparatively it looks like a miracle to legacy management!

The real solution is to fire 3/4 of the management staff and take the next 3 years to rebuild an effective organization. <-- however, this doesn't sell like a SCRUM Miracle Pill™

blobbers• 3 years ago

100% scrum might work in very simple projects.

Once things become difficult, challenging, or new, it's garbage.

Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.

Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.

With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.

Personally, I hate scrum.

dahwolf• 3 years ago

The good thing about Scrum is that it introduces frequent moments of accountability. They are not popular but much needed in many teams and better than the alternative of the traditional waterfall approach.

It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.

That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.

A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality.

True comedy is found in "scaled agile". This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.

Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it.

I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.

somsak2• 3 years ago

We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they'll call out time wasting.

I had to use t-shirt sizes to estimate software.

Why is this a problem?

We spent more time estimating story points than writing software

This I just really don't believe. Perhaps it was meant in jest / hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn't mean the whole thing is useless.

scrum is not for developers

Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.

berniedurfee• 3 years ago

Lol, I was on a team that was required to stand during standups, even though we all sat together and could just swivel our chairs around.

One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’

fsw• 3 years ago

One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’

There's no project manager role in Scrum so he was already doing it wrong.

Yhippa3• 3 years ago

The reason I have heard about this is that standing is fatiguing and discourages people from going on and on. I get it but I think it's strange.

dorinlazar2• 3 years ago

SCRUM solves a problem the X poster is too young to know. I'm mildly amused, he has no idea what SCRUM is about and why the ceremony is a lot better than the sleepless nights and the crunch time spent rewriting the application in the last month before release.

Pepperidge Farm remembers!

tripdout• 3 years ago

I much prefer Kanban. No unnecessary time spent coming up with story points that will be inaccurate anyways and don't even provide much benefit.

kerblang• 3 years ago

The original article is apparently on linkedin (ugh but hey)

https://www.linkedin.com/feed/update/urn:li:activity:7101572...

Not extraordinarily insightful but an amusing take on occult ritualism as engineering.

drewcoo2• 3 years ago

Speaking of occult rituals, I think scrum started to go wrong when we were told to stop it with the chickens and pigs.

https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/

https://www.scrum.org/resources/chickens-and-pigs

That's when it stopped being about teamwork and started being about micromanagement.

11235813213455• 3 years ago

agile, scrum, sprints are all bullshit, software & development are endurance, long-distance running, you only need some milestones for releases, but never ever 1 week or 2 week sprints

lispisok• 3 years ago

1-2 week sprints always seemed like a great way to accumulate tech debt as people rush to complete their stories. Doing good work can take time.

WJW2• 3 years ago

It's also great to stretch 1.5-week tickets into two-week tickets since after you merged it all there is no time to pick up some other thing.

ecshafer2• 3 years ago

Scrum I think is pretty bad. It’s designed to work in contract shops where you have a short window deliverable for the customer, and isn’t really well designed for a more collaborative development process. Also the cargo culting meetings are pointless.

Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.

Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.

mongol• 3 years ago

As usual, the truth is somewhere in between. To say it is cancer is to exaggregate to say the least. But it is certainly no miracle pill either. Like most things, it works best in moderation. If you apply it keeping in mind the agile manifesto, it is not too bad. But if you apply it like a rulebook, it will not be efficient.

As an example, "Individuals and interactions over processes and tools". A standup is interaction between individuals. I believe it was invented to get away from the formality of heading to a meeting room and waste time with a long agenda. Instead, short and concise, stand up around the desks just where you work. Short, efficient, concise.

However, now it may have outlived itself in many teams. We work more remote, have other tools than 15 years ago. So if it doesn't work, don't do it. But if you don't know what to do, you can use Scrum as inspiration, and take it from there. There are certainly worse ways, because Scrum was not born from nothing. It was a reaction to a worse way of working.

idkyall2• 3 years ago

I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.

But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.

Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.

palata4• 3 years ago

devs have basically always felt like our time is being wasted in meetings.

I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".

Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".

No wonder I don't respect my managers then, and now I happily waste my time in their meetings.

bitwize5• 3 years ago

Scrum practitioners often spout weird propaganda. I once remarked that a programming task might be time-intensive, and difficult to accomplish quickly in a process as meeting-heavy as Scrum. The Scrum Master then linked me to a FAQ item on some pro-Scrum web site which purported to assure us that Scrum teams spend far fewer hours per week in meetings compared to other teams. She might've had a point, albeit a small one, if:

* standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup)

* we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h)

* POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.

coldtea2• 3 years ago

I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.

All 10 of the former?

idkyall2• 3 years ago

Well - since he did say they were mostly people with the title 'scrum master' or 'agile coach' defending it, perhaps a better phrasing is "people whose livelihoods depend on it" :)

baz005• 3 years ago

The meetings are good. You're getting paid during them. I managed to customise my bike, plan two international adventures, run a side business and do a year of a degree in pointless meetings in the last 5 years!

throwawaysleep2• 3 years ago

Yep. I have come to love Scrum for the dysfunction it provides as a remote employee. I can sit in the background and do other things while not being expected to achieve anything.

bitwize5• 3 years ago

Ding! Ding! Ding! We have a winner. Tell him what he's won, Johnny!

Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.

jayd16• 3 years ago

management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it

I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.

I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.

lpapez4• 3 years ago

In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :)

However, the management insisted that we adopt Scrum and get a Scrum Master to help us.

I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).

The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".

After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.

Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)

nine_zeros5• 3 years ago

After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)

Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.

jauntywundrkind• 3 years ago

Yet to find a company where the folks down the reporting ladder can rate how they perceived various initiatives to have gone. So weird how businesses just don't want to hear how "Implement formal agile process" (or other goals) went.

WJW2• 3 years ago

Of course. Because they don't produce outputs directly, reputation is all a manager has to prove their worth to the company. If you take that away by publicly demonstrating how their actions caused bad results, their boss might well fire them since they are apparently being a net negative. Managers face a much more difficult labor market than most engineers too.

So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.

coldtea2• 3 years ago

More likely they'll just blame you, just like the sibling comment says...

Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.

notjoemama7• 3 years ago

aka: micro-manage, because they don’t understand the effort and cost…or if you’re cynical because you’ve experienced it, some middle manager desperately needs to control other people because they subconsciously know their position is 90% absolute dead weight. Maybe that’s a bit too negative, sorry.

vitaflo• 3 years ago

In many companies headcount = power. You getting a ton of work done with a small team matters less than Bruce with his 50 reports and $6m budget for them.

Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.

baz005• 3 years ago

Ah yes the defence:

"The process failed because you didn't have enough project managers on board"

No the process failed because it was fucking shit and everyone went somewhere else.

The only good thing heavy processes are for are propping up employment statistics.

notjoemama7• 3 years ago

Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.

projectazorian• 3 years ago

Heavy process is fine and necessary if you are building, say, a skyscraper or a nuclear reactor.

Most of us are not.

hibikir• 3 years ago

The best I can say of scrum is that it's designed to get some amount of output from an otherwise extremely dysfunctional team. If your teams were achieving nothing, it provides a modicum of accountability. So there's places where yes, scrum is an improvement.

But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.

oweiler• 3 years ago

There is the old saying that scrum turns bad devs into mediocre devs and good devs into mediocre ones.

bitwize5• 3 years ago

Real Scrum has never been tried.

notjoemama7• 3 years ago

True Scrumunism? :)

_jal• 3 years ago

Scrum can never fail, only be failed.

baal80spam4• 3 years ago

https://imgflip.com/i/7xhfm6

ourmandave• 3 years ago

What (or who) made them decide they needed scrum in the first place?

freedomben5• 3 years ago

IME, it's usually a new hire, usually a product person. There's always pressure on those people to introduce changes to increase whatever the KPI metric is, and from their perspective scrum is a great choice. Plus management drools over data/metrics, no matter how much you explain to them that there are serious flaws with the data. You get more of what you measure, and the law of unintended consequence can be a beast. I've seen people come under the Eye of Sauron because they weren't closing as many "story points" as their peers. In reality it's because this person was the best mentor on the team, and the most experienced in the codebase. They spent most of their time pairing and training others, but only one person gets to make the commit and claim the points. That person initially stopped helping people and would (understandably) get irritable when asked questions, and then left the company. Management considered it a win to dispense with a "low velocity" engineer. It hurts my soul to think about the stupidity, especially since they were told numerous times that this person was the MVP of the team, no matter what the metrics said. You get more of what you measure.

brailsafe4• 3 years ago

My most informative experience was had at this huge auction company that I was doing frontend on. At one point, I was working on what we'd now call a component, but was at that time manually created dom elements generated with a very long series of logic branches that depended on a number of external, possibly async conditions. It was extremely hard and time consuming to test and keep all of the possible conditions loaded into my consciousness with all of the chatter in the surrounding space and some fuckhead making sales calls on his phone and typing on his mechanical keyboard—because y'know, everyone's gotta be in the same room—meanwhile the product owner would come over to add new requirements while I was trying to focus and then the scrum master would come over to ask why I wasn't done yet. This went on until my productivity and motivation ground to a halt, I burnt out, got depressed, and got fired. However, when I started at the company, it was surprisingly fine. I worked with two other guys collaboratively on some tricky frontend issues, which we solved, and it was fine.

t4356214• 3 years ago

scrum masters should only bother you at the standup. They also shouldn't add requirements.

So .... the one you were dealing with was just an average bullshitter pretending to do scrum.

siva7• 3 years ago

This wasn't scrum because talking to the costumer is the primary job of the Product Owner and not of the Scrum Master. PO is also a full time job and not some side hustle of a team lead or SM. Having a good Product Owner makes the difference between adopting scrum successfully or failing at this process.

Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.

lolinder3• 3 years ago

I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line?

Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)

lpapez4• 3 years ago

Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.

How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.

What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.

chriskanan• 3 years ago

This was exactly my experience, but many more months than 3.

dragonwriter4• 3 years ago

Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master

Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.

But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.

(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)

Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.

Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:

tickets taking exactly one sprint to complete

This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)

EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.

I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.

lolinder3• 3 years ago

I'm reminded of Ben's question about the shamble-men in The Name of the Wind [0]. It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them.

In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.

[0]

“Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
“What if two people told you?” Another shake.
Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
“Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
“Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”

AlbertCory4• 3 years ago

So, would it be fair to summarize this as, "You weren't doing True Scrum" ?

freedomben5• 3 years ago

You're surely getting downvoted and lumped as one of the "but that wasn't real scrum" types, but this strikes me as unfair. I am highly critical of scrum, and have had many of the "that's not scrum" variety dismiss criticism, but yours is actually thoughtful and (indirectly) makes a good point: some people really do deviate from "real scrum" substantially. I hate scrum with a passion, but if we just do the inverse argument of blanket dismissing any criticism under "oh you're one of those" then we're being as intellectually dishonest as the "that's not real scrum" crowd (and for the record I don't include you in that crowd).

I appreciate you being willing to articulate an unpopular opinion :-)

systems• 3 years ago

I am curious, how did management respond when the progress slowed

did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important

what happened ?

dylan6042• 3 years ago

this would be an example to be studied in future classes of business school if this resulted in a change like you would hope for. otherwise, it's business as usual, and no, the changes you seek would not happen.

i'm obviously turning this into a hypothetical

palata4• 3 years ago

how did management respond when the progress slowed

Rule number 1: management is never wrong. The progress did not slow down.

CipherThrowaway• 3 years ago

Standard playbook in this situation is everyone involved saves face by blaming the team who were driven out, then they adjust to the new normal and everyone forgets they were ever able to build and ship software.

lpapez4• 3 years ago

Their view was that there was no problem, but rather that the new process was an improvement. I am not joking.

They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.

In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.

Justsignedup• 3 years ago

"if everyone is productive, don't hire a manager, promote." applies here.

If scrum isn't working for you and you're productive, do more of that.

If what you have isn't working, and scrum might help. Do that.

That's the point. Don't break something just because others are doing it.

username3322112• 3 years ago

I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).

And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.

In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.

Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.

ahtihn2• 3 years ago

The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.

I do not understand how this is possible.

* Sprint planning: 2 hours

* Sprint review: 1 hour

* Sprint retro: 1 hour

* Daily stand-up: 15min / day

On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.

What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?

palata4• 3 years ago

Not that I disagree with you, but I read your message as: "managers suck, so I found a way to work around them".

It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.

IshKebab3• 3 years ago

50%?? Scrum is like a 1-2 hour planning/retrospective meeting per fortnight plus 10-15 minute standups every 1-2 days. How could that possibly take 50% of your time?

simmschi• 3 years ago

The proper way to fight scrum is simply doing scrum properly.

Nobody usually wants this.

For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.

Some bug? Pfft, if not critical, will maybe take it next sprint.

Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.

CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.

What do you mean, you need more story points delivered per sprint?

The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.

Attummm• 3 years ago

Scrum master name is supposed to be joke, like dungeon master. They are supposed to lead the process of scrum and stay in the background.

karaterobot• 3 years ago

Ugh, swapping out a successful development paradigm midstream sounds like somebody up the chain thinks change is the same thing as progress.

In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"

Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.

lpapez4• 3 years ago

It never occured to me that the change can be framed this way, I will learn from this.

I thank you for this perspective kind stranger, truly.

Zigurd4• 3 years ago

Arbitrariness, disconnection from purpose, jargon, standups being badly structured meetings, disempowered product "owners," etc. are reasons to call it "cancer."

Agile was needed, to replace waterfall management of software development projects. In particular, trying to do resource leveled critical path analysis for most software projects is the road to project hell.

But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.

notjoemama7• 3 years ago

I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of product not engineering. By having tighter feedback loops it was promised less man-hours would be spent. My impression is it’s changed what the man-hours are spent on. It’s harder to get an elegant architecture over 2-3 years of agile as opposed to waterfall where it can be more tightly controlled. That’s probably the limit of my perspective on the matter. I am positive there are others that know more and have a more accurate perspective on why and how things changed.

Zigurd4• 3 years ago

This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized.

That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile.

You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs.

A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc.

More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.

notjoemama7• 3 years ago

I don’t mind scrum, specifically the daily stand up. In an old job a couple non-contributors became obvious. And so has been my work ethic. I benefit from that because I’m naturally the kind of person to get things done. Despite my good feelings about it, I also see how often it’s used as a) an excuse to micromanage and b) a mechanism to feed leadership’s need for attention. I don’t know if this is accurate or not, but I’m inclined to think people that get into managerial positions are more social and that seems to come with an intrinsic need to be seen, recognized, and given some form of public accolades (like everyone laughing at thier funny jokes). And while I like the accountability of stand ups, you’re going to get my PRs anyway and your agile tickets/cards are getting moved to done whether I’m in a meeting or not. I think overall it’s a bit of a waste of time for me. That’s just my personal opinion though. Maybe I’m wrong, feel free to give feedback. I’m open to being convinced otherwise.

paulcole• 3 years ago

I think overall it’s a bit of a waste of time for me

The company isn't trying to optimize for best use of your time individually or to make you happy. They are trying to get some kind of result. And it very well may be worth inconveniencing and annoying higher performers to improve the performance of lower performers to achieve the result they want.

notjoemama7• 3 years ago

Huh, hadn’t thought of that. Thank you.

nottorp• 3 years ago

In an old job a couple non-contributors became obvious.

So your management wasn't doing their job? They're supposed to know who's working and who isn't regardless of what rituals are practiced.

matwood2• 3 years ago

Or they did their job by implementing scrum?

notjoemama7• 3 years ago

That’s exactly right! I’ve had that same exact thought. Had they been making any kind of effort to “manage” that would’ve been dealt with much sooner. We didn’t necessarily need daily stand ups, but they ended up being the mechanism management used to figure out who was not performing. I have often wondered if a simple cursory check in would’ve accomplished the same thing. All the meeting and processional hand waving might’ve been unnecessary.

f1shy2• 3 years ago

If he was force to use Scrum, they were GOD DAMM NOT DOING THEIR JOB!

tstrimple• 3 years ago

but I’m inclined to think people that get into managerial positions are more social and that seems to come with an intrinsic need to be seen, recognized, and given some form of public accolades

I got into management because I like solving problems and I reached a point where solving purely technical problems is no longer what it takes to actually drive a product forward and improve things. The problems I try to solve now are more organizational so that dev teams can actually reach that creative state where they are talking with the customer directly and engaged in the overall process. I'm an introvert. The face time and accolades are draining, but it's important work that you've got to be in a leadership position to take on effectively.

asciiface• 3 years ago

My team does soft-agile. Month long sprints and minimal meetings. We treat it less like a rigid structure everyone must conform to and more of a way to organize backlog and delegate. It has worked very well for us, however we are a small and fairly siloed team and our stakeholders are highly technical people who consume our services internally. we get the leeway to self govern properly.

matwood2• 3 years ago

We have tried 2-3-4 week iterations, but keep coming back to 2 weeks. It's enough time to do something, but not so much people can get lost off track for a long time. But, we're also ok incrementally delivering features. No single feature has to be done in 2 weeks. Some take many iterations.

Also agree with minimal meetings. 1-2 meetings/iteration. When new people start we'll add some office hours time every other day as needed until they get up to speed.

stillbourne• 3 years ago

"Agile is a cult." Is a refrain I've had for a few years. I don't mean like the agile process, I mean the agile culture. I went to an agile conference for work and the things they talked about were just really really dumb, I swear they almost professed that agile could cure cancer.

Scarblac3• 3 years ago

I think it's Scrum that's a cult, agile works fine in the rare place that does it.

But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment.

Not something you have conferences about.

t4356214• 3 years ago

What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this.

Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.

datadrivenangel• 3 years ago

Scrum is good if you have moderately dysfunctional stakeholders or moderately dysfunctional developers. Otherwise it's not needed.

channel_t• 3 years ago

I haven't done a ton of Scrum in my career, but my observation of it, in concept at least, is that it's supposed to be sort of like training wheels for agile, which seems innocuous enough. What I have found particularly horrifying about some orgs adopting it is that the agile part (the part that's trickier to execute) gets thrown out the window in favor of what is basically waterfall with sprints, and then people eat it up like there's nothing profoundly wrong with the picture. Something like that is definitely a cancer.

rawgabbit2• 3 years ago

That is reality. Agile made a straw man out of waterfall. In reality, no one practiced waterfall the way the Agile Manifesto claimed that it did. In reality scrum is waterfall with a new name. There I said it. Now I will face the agile inquisition.

hankchinaski2• 3 years ago

Scrum is a good tool for a bad manager https://www.yegor256.com/2015/01/08/morning-standup-meetings...

mm263• 3 years ago

This dude talks about directly punishing people for not meeting deadlines and monetary rewards for completing tasks. This is weird, patronizing, de-motivating. I would run from him as fast as possible.

She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.

hankchinaski2• 3 years ago

the article is satire - at least i consider it so - but it describes the whole scrum charade pretty well

kypro2• 3 years ago

I got rejected from a job recently and I strongly suspect it was because I went on a rant about how awful scum was against my better judgement.

Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.

Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.

But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...

I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.

eikenberry• 3 years ago

I went on a rant

I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.

schwoll• 3 years ago

This is an apt observation. Anything negative. Even if true. Even if it doesn't reflect on you. They want someone socially aware enough that they can say negative things without saying anything negative. There's a nuance. "I understand where they're coming from. There's definitely situations where that is preferred", translates to "I disagree totally but it's their prerogative so I'm not going to worry myself too much with that decision."

It shows experience with people and ability to read between the lines.

kypro2• 3 years ago

You're right. I had already got bad vibes from the interview by this point and started acting up a bit.

I was initially really interested in the company and made it clear early on that I really liked what they were doing and how I thought I could add value, but they started shooting me down assuring me the role I was applying for wasn't that interesting and that I'd mostly be a code monkey (obviously not in those exact words).

By the time they started asking about my agile experience and what I thought of scum I figured I didn't have much to lose being honest with them. It would have been in neither of our interest for me to pretend I might have been a good fit.

But yeah, generally I'll try to be mostly positive while finding something minor to be constructively critical about. I think that tends to strike the right balance between showing you can think for yourself without coming across as the type of person who will cause problems. Sounds like you've noticed the same thing.

JohnMakin• 3 years ago

one of my former companies went all in on scrum/agile/whatever you want to call it.

In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren't always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues.

Another issue I had with it, it did not really encourage me to be super productive . Like, I took on 16 story points this sprint, finished them all in a week, what possible incentive do I have to take something off the backlog and squeeze it into this sprint when my teammates (some of whom are paid more than me) are doing half of the "points" I am? It creates tension where I don't think any is needed. To make things worse, the system is easily gamed.

Another thing is I think it created way way more meetings than was needed.

frou_dh• 3 years ago

Sounds like the guy is very happy to have whipped up a shitstorm because it Drives Engagement.

javier_e06• 3 years ago

Scrum means different things to people.

To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing.

A software development is only a team only in name. If developers like to help each other and talk to each other without having to be rounded up like gerbils is more of a fellowship.

TrevorJ• 3 years ago

The common thread is that scrum always prioritizes the time of the managers over the time of the people producing the work.

mbfg2• 3 years ago

it's very religion like...

The say they are doing scrum, but they aren't really doing scrum

He says he's a christian but it's clear to me that he wasn't one all along.

t4356214• 3 years ago

Lots of people claim to be Christians but don't forgive, turn the other cheek or love their neighbors because it doesn't suit them to but it does suit them to claim to be Christian.

So any successfully communicated methodology is going to be claimed by lots of hypocrits and then perverted while they simultaneously boast how much they love it.

And then you'll get the opposite kind of person who doesn't believe in forgiveness or loving their neighbors and sees a great chance to attack those ideas by supporting the hypocrits deception and claiming that their perversion is the real (evil) religion.

None of this helps software get built but is just a power struggle between developers who don't want to reduce the bus factor or despecialise or write tests or do maintenance or change their great plans to suit circumstances.

mbfg2• 3 years ago

the problem is, it's hard to prove that someone is not a true "_____". Because the definitions are not well defined.

darepublic• 3 years ago

Worked for a consulting company that was heavily into Agile. You were given an Agile book just for making the final interview. I honestly can't say it was 'agile's' fault but every decision we made in the project I worked on was completely overwrought and fraught with bike shedding, which could only be resolved by the underlying power dynamics where some people were in power and some weren't. The client eventually pulled the plug on our project which we failed to deliver. Not that we failed a specific delivery date; afaik we didn't have a set deadline for the project. I think back on it sometimes as an example of how not to be.

IKantRead• 3 years ago

I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing.

Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.

One thing I thought was interesting was:

First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.

It seems funny to critique people's job titles when the poster's Twitter profile reads:

I teach Machine Learning and run http://ml.school

I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.

tasubotadas5• 3 years ago

The OP barely has any experience in the field so... One bad gig is maybe 50% of his work experience.

rijoja2• 3 years ago

Thank you! Personally I started to ignore any post from twitter on HN, which otherwise has fantastic quality on its content, since you just know that the content will shallow and "clickbaity".

My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead.

It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively.

Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.

adammarples• 3 years ago

Critiquing Scrum in now way establishes you as an expert in teaching ML

rijoja2• 3 years ago

Yes, that seems to be IKantRead's point.

cmrdporcupine• 3 years ago

Scrum was never the disruption. Agile was. But really, it started with eXtreme Programming, from which "agile" was the more generalize distillation.

I'll say this: I worked in XP (and then "agile") teams ~20 years ago a couple times with varying success, but the one good thing was it got people thinking and agitating against the delusions that went along with waterfall.

Then I got stuck at Google for 10 years, where "agile" isn't really a thing. (There are teams that are sorta doing scrum... ish stuff. And there's a wide diversity of how things are done there. But on the whole Google has effectively unlimited budgets and headcount so things sorta just ... broken down waterfall ... until they're "done" whenever). When I got out... Scrum or some variant had taken over.

And I don't recognize this as the "agile" I worked with before. It's just a mess of pointless routines and shiboleths without the meat of what made things "agile".

Agile was: developers do their own estimates. Short iterations. "Stories" are 2-3 days and tied directly to a customer's business request. Intense involvement with the "customer" letting them know the trade-offs for every decision. Ship the prototype. "You ain't gonna need it." Informal daily standup just for the purpose of making sure everyone is on the same page. At the end of the iteration, go over the "cards" and triage and discuss why some estimates were off.

What I see now is just going through the motions of some of these, but in the end it's either chaos, or waterfall in disguise and some PM with a hard-on for configuring JIRA in some convoluted fashion so they can pass on reports to their superiors and make people jump through hoops so it looks like progress.

I just wanna code, get things done, fix things and ship things. Agile was the recognition that (good) engineers want to get work done and the upfront design process was often just getting in the way of problem solving and the creative process. The ones who don't? Get them off your team.

Somewhere along the line that message was lost.

genezeta• 3 years ago

I don't think that part is so much about the job titles themselves. It's more about the interests/motivations. As in "I said smoking was bad and a lot of people that worked in selling tobacco told me I was wrong and that smoking was perfectly healthy".

tabtab• 3 years ago

Many of these management techniques require a well-run shop to work well. They are not forgiving of riff raff and institutional dysfunction, and may even magnify dysfunction. So yes, they CAN work under ideal conditions, but ideal conditions are too rare, especially for non-IT domains who don't understand & value IT management.

Borrow the best fitting ideas from each methodology, but don't obsess on them.

wkat4242• 3 years ago

I totally agree with you, but I would add "for me".

I absolutely hate guidelines and processes and methodologies. I'm totally not a team player either. I need to have my own responsibilities. As ISTP personality these things are totally contrary to my personality.

As such I hate every methodology, of course right now agile (and Scrum as a subset of that) is the darling of every project manager so I hate it. But I do realize it would apply to every other type too.

But anyway I do as I've always done, the absolute minimum to comply with the framework and ignore what I can get away with. Because I get results this is accepted and I'm usually maneuvered into a niche area where I can perform.

For example I always stop logging my mandatory hours in Jira until I get reprimanded and then I stop again a few months later :P

Of course "logging hours in Jira" is our company's idea of "we're agile". We literally don't do anything else :P So it's easy to get away with.

tasubotadas5• 3 years ago

I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).

The remaining teams just needed Kanban.

Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.

After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)

dylan6042• 3 years ago

I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day

IshKebab3• 3 years ago

How do you "prefer kanban"? Don't all these methodologies use kanban boards?

palata4• 3 years ago

I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).

I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).

The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.

lhnz2• 3 years ago

The good thing about Scrum is that there are hundreds of little dials that can be modified if you're not getting any value from it.

Due to this level of flexibility, it's always the right approach.

manuelabeledo• 3 years ago

Isn't that precisely one of the most glaring issues with Scrum?

Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.

lhnz2• 3 years ago

Yes, sorry, that was sarcasm. It's incredibly funny that Scrum's most redeeming feature is for it to be so configurable. Scrum has the configurability of SAP.

nickelcitymario• 3 years ago

Take this with a grain of salt, because I've only experienced aspects of scrum, and I didn't hate it.

I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full.

Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis.

So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:

(1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we're trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.

(2) Sprint planning may have too narrow of a focus, since it's entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.

(3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.

(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them.

(5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.

ivraatiems3• 3 years ago

This guy is a grifter with uninformed, ranty opinions, and it's a shame he is getting so many of these HN eyeballs for his purposefully provocative nonsense.

Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237

The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are people on this site who happen to agree with him.

But if course, if you pay him, he'll say whatever you like, per his website.

aidenn03• 3 years ago

I think the reason he's getting upvotes is that a lot of people have had similar experiences. It should be obvious that adopting Scrum won't fix a dysfunctional organization[1]; nothing in the previous post, nor this one argues more than that.

I'm more interested in some of the comments I have seen here of people observing the adoption of Scrum as significantly reducing the velocity at what was previously observed to be well run. Maybe adopting the more formal process revealed an underlying organizational dysfunction that could remain hidden in the previous laissez-faire culture, maybe there's something wrong with how Scrum gets implemented at those places, and maybe there's actually something wrong with Scrum itself.

My only interaction with things explicitly described as "agile" (Scrum, or otherwise) appeared to be very large organizations mostly just renaming roles and processes that already existed, with a few minor changes that did not appear to have any effect (other than being able to claim that they were now "agile"), so I don't have any personal experience to answer any of these questions.

1: Though in defense of the ranters, you'll be able to find many Scrum consultants that will argue it can.

Yhippa3• 3 years ago

I'm not going to provide a source, but I bet a lot of developers can relate to what he said. It feels like a lot of us have had Scrum shoved down our throats at some point or another and it feels great to finally lash out.

hahamrfunnyguy• 3 years ago

Usually mindless implementation of some buzzword process in its entirety is doomed to failure. I worked for a manufacturing company a number of years ago. I was a developer, working on machine control software.

Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.

This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.

They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.

placesalt• 3 years ago

I hope someone had the acerbic wit to label the tape 'tape'

kenada3• 3 years ago

I’ve had good experiences with scrum. I was on a team that was empowered to own and refine its practice. We were able to halve our cycle time and improve sprint planning to the point where we rarely overcommitted. It was great, and it was credited with the successful delivery of a major project.

Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things should be done, and that resulted in a replacement process that was worse. We lost the ability to do effective capacity planning and iterate quickly. It was terrible.

That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people. If the people aren’t empowered, it won’t work. If you’re not iterating and communicating, it won’t work. If someone’s not on board with that, they can sabotage things (intentionally or otherwise).

pillefitz• 3 years ago

What was the replacement process?

kenada3• 3 years ago

The manager would tell people which ServiceNow tickets to work or what project work to do. We went from empowered to micromanaged. Maybe the kinks got worked out eventually, but I didn’t stick around and left after a few months.

Yhippa3• 3 years ago

That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people

From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.

kenada3• 3 years ago

That’s fair, and you’re right. I apologize for being unclear. Perhaps I should have quoted it to reflect that my issue is with what gets called “agile” rather than what the practice is supposed be (and the former seems unfortunately common).

afro882• 3 years ago

What's the alternative, where devs are motivated and productive, the team can react to the market quickly, and the business can rely on delivery dates for commercial and marketing?

I'm not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.

seadan834• 3 years ago

and the business can rely on delivery dates for commercial and marketing?

Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is based on the outcome of the previous.

afro882• 3 years ago

I know, I said:

I'm not saying scrum and agile achieve the above.

Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc

ineptech• 3 years ago

This looks like nothing but engagement bait for twitter's new monetization program. If I tweeted "Capitalism is cancer" or "Socialism is cancer" I'd get a lot of dumb responses too, but that wouldn't be evidence of anything except that constructive debate involves nuance and asking thoughtful questions and defining terms.

ph4evers• 3 years ago

Erik Meijer has a beautiful video saying basically the same: “Agile is a cancer we have to eliminate from the industry”. I believe the original video also had this title.

https://youtu.be/2u0sNRO-QKQ?si=veqouWjAzIaUt5TG

tester756• 3 years ago

First off define what is scrum for you

For me scrum is daily 10min meeting and that's it

and I like it, I don't have problem with one quick meeting to sync.

But when I hear stories about estimations in some imaginary units, then it sounds bad.

mjfisher2• 3 years ago

How long do we think it will be before a lot of the recent negative sentiment about Scrum bubbles up to exec-level consciousness?

I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.

I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".

bilater• 3 years ago

I think the deeper reality is that people just suck at working together. There is always gonna be friction when a group of individuals try to achieve something together (time lines, slackers, miscommunication). We blame it on method X when at the end of the day its human nature and no magical method of working can completely remediate that.

jake_morrison• 3 years ago

I think Scrum is a transitional phase. It is a solution to the problem of having a dev team shared between multiple business functions.

The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work.

In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.

The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development.

The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.

dancemethis2• 3 years ago

Oh, it's the kiddo who thinks they are very smart and adult for being a proud-to-be-misinformed gratuitous anticommie again.

stephc_int13• 3 years ago

Agile was introduced as a less-rigid and more efficient alternative to waterfall-like processes that were widely used in the 90s.

The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.

My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management.

Never seen any improvement from it, only overhead and demotivation.

edw519• 3 years ago

Finally, by far, most people hate Scrum with passion.

I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.

In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy!

https://eddiots.com/1700

skeeter2020• 3 years ago

If you thing scrum is bad, try adopting scaled agile. It's so bad that our new CEO who introduced it less than a year ago tried to pull the Steve Jobs reality distortion trick to convince everyone in a recent all hands that "we're not Scaled Agile, we never have been. We used little parts of it to make something better that's all our own".

What you need to recognize with all these processes that go beyond the direct dev team is that they are not there for the devs. They're for senior leadership and non-technical executives to pretend they can have their cake (agile with responsive and constant delivery) and eat it too (waterfall with scheduled "final" delivery). It still sucks but this understanding does help you survive.

koliber• 3 years ago

Scrum is a descent way to get a relatively immature team to get work done. There are other more effective ways to get work done if you have an experienced and mature team.

This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved:

How Big Tech Runs Tech Projects and the Curious Absence of Scrum

https://newsletter.pragmaticengineer.com/p/project-managemen...

jjkeddo199• 3 years ago

I think rapid iteration + kanban style documentation is indispensable towards good productivity for most dev teams. I think having quick dev cycles + good documentation benefits everyone: devs, managers, and the accounting team too. Where I think Scrum goes wrong is that turns documentation+rapid iteration into a cudgel to use against devs and pressure them.

"Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.

My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.

slowmovintarget• 3 years ago

Scrum fails when it is formalized and run Cargo-Cult style. "We must do all of these steps as in The Book." If you understand the reasons for the steps, and instead incorporate the function in the day-to-day activities, values, and norms of the team you get the benefits with very few drawbacks. But yes, you're no longer a "true Scotsman" doing "real Scrum."

Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.

t4356214• 3 years ago

Some developers are a cancer too of course - want to do things they way they choose, taking the time they choose. A lot don't want to lose their specialisation or ownership of some portion of the code.

You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes.

From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.

That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals.

And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people's code, writing tests, working on requirements, maintaining old code.

welzel• 3 years ago

I feel very sorry for Santiago.

His pain seems to be real, even if it is not even connected with scrum.

What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern.

1) "1. They tried to convince me that Poker is a planning tool, not a game." Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.

2) Scrum does not have "ceremonies". They are called "events" and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?

2) "Scrum of Scrums" is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.

3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.

4) "We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint." -> this is not scrum. This is whatever the team came up with.

5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques.

6+7 "story points" are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)

8. "Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.

Scrum is a cancer

Related Stories