Are Scrums a Cancer? (devops.com) 293
Santiago Valdarrama teaches machine learning. He posted this week on Twitter and LinkedIn that "Scrum is a cancer." Some highlights:
I've been writing software for 25 years, and nothing renders a software team useless like Scrum does... We spent more time talking than doing... We spent more time estimating story points than writing software... 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 believe in Agile, but this ain't agile... The result was always the same: It didn't work. 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.
DevOps.com shares some reactions, including the developer who calls Scrum "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."
But later in the week, Valdarrama revisited the issue with a follow-up post. "After 3,400 replies, I learned a few things." First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master...."
Second, Scrum can't fail because Scrum is whatever you want Scrum to be. There's no right way to do Scrum, so if it doesn't work for you, you aren't as bright as you thought you were.
Third, Scrum isn't agile, except when it is. But it's much better than Waterfall, except when it isn't. And it's better than nothing and everything at the same time.
Fourth, many people got triggered by my comparison of Scrum and communism...
Finally, by far, most people hate Scrum with passion.
Thanks to Slashdot reader RUs1729 for sharing the link.
I believe in Agile, but this ain't agile... The result was always the same: It didn't work. 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.
DevOps.com shares some reactions, including the developer who calls Scrum "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."
But later in the week, Valdarrama revisited the issue with a follow-up post. "After 3,400 replies, I learned a few things." First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master...."
Second, Scrum can't fail because Scrum is whatever you want Scrum to be. There's no right way to do Scrum, so if it doesn't work for you, you aren't as bright as you thought you were.
Third, Scrum isn't agile, except when it is. But it's much better than Waterfall, except when it isn't. And it's better than nothing and everything at the same time.
Fourth, many people got triggered by my comparison of Scrum and communism...
Finally, by far, most people hate Scrum with passion.
Thanks to Slashdot reader RUs1729 for sharing the link.
Developers treat it like any other management tool (Score:5, Interesting)
They go through the motions, humor it, then work around it and ignore it. There's a common joke among our devs.
We go to sprints and standups, so our scrum masters feel productive.
We do story points, so our agile coaches feel productive.
We give reports, so our product owner feels productive.
Then we ignore it all and do our work, so we can feel productive, too.
Re:Developers treat it like any other management t (Score:4)
Pathways to making good code that will work with others. If someone is doing something that fits into your code, you should know about it and work with them. Double work is not productive for either.
Hangups that are causing you to pause, sometimes discussing them open forum or coworker to coworker can lead you to solutions.
Potholes in code that can trip you up, cause security concerns, or make sure you are correctly flowing with your code. A sometimes futile effort, but is always nice when you catch it before you have to rewrite it.
Re: Developers treat it like any other management (Score:4, Insightful)
Re:Developers treat it like any other management t (Score:4, Insightful)
And if your team is good and they aren't bogged down in meetings and reports, they will self identify when they need to talk and to whom and will do so by email, voice, video, or in person as necessary. They'll loop in whoever is keeping track when they have something useful to report.
Most of the Agile, scrum, etc, etc, ad. nauseam is just cargo cultists who build non-functional mock-ups of technology out of wood thinking it will attract the magic and cause the real thing to appear.
It's the same as people who think if they wear a black robe and a mortar board they will magically become smart.
Re: (Score:3)
Yep. The fact that there are "ceremonies" alone should be a red flag. How it is "agile" to waste a week playing Fibonacci poker planning out 8 sprints in advance, when everything will change three weeks in the future anyway?
Retros
Grooming
Overblown Definition of Done
etc.
Instead of doing work.
Re: (Score:3)
The only reason anyone should get together is to discuss pathways, hangups, and potential potholes
And only after you've failed to work the problems out via asynchronous communication (emails, chat, etc.). Meetings are for when there is something critical to do that can't be done in any other way. 99.9% of meetings are unnecessary and merely reduce productivity with no discernible benefit.
Re: Developers treat it like any other management (Score:4, Insightful)
The problem with almost every 'Agile' method is that they never works well. Mostly because they try to formalize without understanding the actual need of the organization.
The end result is that they just waste time.
Re: (Score:3)
The problem with almost every 'Agile' method is that they never works well. Mostly because they try to formalize without understanding the actual need of the organization. The end result is that they just waste time.
Scrum is an attempt to package some agile ideas so that they can be implemented in a traditional corporate structure. Some of these ideas are interesting and actually an agile methodology implemented right can deliver, but the typical corporate sees the ideas but is unwilling to adapt itself to realize them. They want a "standard solution" to buy and implement without having to understand it too much and without having to change too much. Scrum to them is said solution.
The fundamental point of agile is hand
Re:Developers treat it like any other management t (Score:5, Insightful)
I would have thought that "no methodology" is much more popular than "methodology X" in most software teams across the globe. Do we actually have statistics, and who comes up with the estimates?
Re:Developers treat it like any other management t (Score:5, Informative)
Time and time again we get articles like this; the person whose shit at it claims it doesn't work (whilst failing to explain the literally millions of developers across the globe it's working just fine for every single day).
Where exactly are these literally millions of developers it's working just fine for every single day? I don't recall ever meeting a developer in real life who is a strong advocate of Scrum. People with Scrum-related management roles, sure, but developers, never. At best developers' opinions on it seem to be "meh" and many are openly critical or outright hostile towards it. IME developer opinions also skew more negative the more experienced and senior the developer is.
But let's not rely on one person's own anecdotal experience and personal network. We can look at public evidence as well. It's known that few if any of the successful big tech firms use it. Are there any documented examples of successful small firms using it? How about a single robust, peer-reviewed study that shows Scrum is better in any relevant way than anything else? Or that it's "the most popular software delivery methodology across the globe"?
I think if you're going to write a long comment about how everyone else's experience is wrong and we're all just incompetent and there are literally millions of people doing better than us -- despite all our own experiences and quite a bit of verifiable public evidence suggesting otherwise -- then the onus is really on you to back up the claims if you want to convince anyone.
Re:Developers treat it like any other management t (Score:4, Insightful)
Thank you for proving my point.
You prep your bullet points, everyone barfs theirs into the channel, nobody reads it. Why the hell do you do it?
Re: (Score:3)
Unsure about my coworkers, but I read all the posts.
Hate to be the one telling you this, but you're the only one. They don't give a fuck about it. They skim it to avoid doing what's already been done, but they don't care what you do as long as you do it and they don't have to.
But I guess if you like working in the dark, and not knowing what your coworkers are doing or if they can help out with what you are working on and having issues with, etc. then yeah, they probably are a waste of time.
It's more a matter of workload. I'm in security. I know that one of my coworkers is currently doing the PCI-DSS compliance testing. I don't. So I don't care. If he talks about it, there is no reason for me to pay any attention because it does not affect me at all. The only person I curr
Re: (Score:2)
It sounds like that would be better done as a web page where each person gets a box that they can edit.
Re: (Score:2)
tl;dr: It works fine, you're just holding it wrong.
I've said this for years. (Score:4, Informative)
Not just about "scrums" but "Agile" as a whole too. It's garbage. It's a bad idea, simple as that. There's no substitute for a proper workflow, and proper workflows are important, but whoever came up with this shit didn't even have getting work done as a goal in mind. I'm fairly certain it's actually been a Russian psy-op all along.
Re:I've said this for years. (Score:5, Insightful)
Re: (Score:3)
It's not even the superstar developers, it's simply that it's decided by people who have no fucking clue what developers need because these things are designed and implemented by managers who know what managers need. It's just SAP all over again, which is a great tool for managers but never offered anything useful to those who have to suffer, I mean, use it.
Re: (Score:2)
Yes, that's the thing. Agile/Scrum are a one size fits nobody approach to something where the current circumstances should be dictating the workflow.
Scrum is a toolbox. You rarely need all the tools (Score:5, Interesting)
I personally see scrum as a toolbox in which I can pick the tools I need. Depending on the people in the team and the manager's strength and shortfalls, I need a different set of tools to make this work. In other words, pick the tools you want or need and leave the rest away.
Using Scrum with the full set of overhead that it uses, then yes, that's probably going to be way too much. It's really up to the organization to pick the tools it needs. And to be flexible enough to recognize that team A might be comfortable with a different set of tools than team B.
Re:Scrum is a toolbox. You rarely need all the too (Score:5, Insightful)
Re: (Score:2)
I think the point of scrum is that it gives the developers the power. You sit in a retro, you write a post-it note saying "We spend too much time planning story-points". Then you talk about it and decide e.g. to speed up planning sessions. Instead of trying to accurate estimate, you just throw some hat value and save time. For example we have those planning sessions only perhaps once a year where we throw some values and then live with that.
Problem is that usually the developers don't have the power. Instea
Re: (Score:2)
tl;dr: If Scrum doesn't work for you, you're holding it wrong.
Whenever I see these discussions (Score:5, Insightful)
I thank God I'm in a small IT group and basically get to do the full stack myself. I don't think I'm constitutionally compatible with scrums.
Re: (Score:2)
Amen to that.
Re: (Score:3)
Yup. Some of the best work I've seen comes from developers who are just naturally good at what they do, for which the best methodology is to get out of their way.
Hmm, might write a book on that actually, as soon as I can think of a fancy name for it.
Re:Whenever I see these discussions (Score:5, Insightful)
I am a good developer and I worked with waterfall and scrum and perhaps some other systems also that I've forgotten. I also worked alone and in small teams that don't use any fancy protocols.
I think it works best when we have a project manager who worries about the whole schedule and demands some estimates from developers and demands some parts to be ready at certain dates. . And other than that, let developers and customer together arrange their work and work order as they like. Product requirements should be written as development proceeds, which customer constantly testing to see that developer has made what they actually want. If developer understood some requirement incorrectly, the requirement text is clarified.
You should start with some kind of waterfall to make the project plan and get rough estimates, then continue with scrum to get things started (customer-developer communication), and then phase out scrum meetings and just be on constant improvement/development mode.
But this only works with good developers and good customer. If you have bad developers or bad customer, daily meetings are great way to find those people and keep them somehow in check.
Re: (Score:2)
Betteridge was wrong. (Score:5, Insightful)
Are Scrums a Cancer?
Yes.
Re: (Score:2)
Communism (Score:3, Funny)
Re: (Score:2)
Let's take North Korea as an example -- what has the CIA done to undermine it? Is it an example of Communism working?
What about China? It was on a path that involved a lot of market reforms and increases in freedom. After the CIA screwed up tradecraft [thehill.com] about 20 years ago, they lost most of their assets in China -- are the recent crackdowns on freedoms and decisions to stop publishing [nbcnews.com] many statistics [bloomberg.com] examples of Communism working?
Exactly which countries do you think are places that Communism has worked?
Re: (Score:3)
Communism requires that the means of production is owned by the workers. North Korea, everything is owned by the dictator. I see a compatibility issue between these philosophies.
Re: Communism (Score:3)
Startup companies are a form of communism, as the early employees own a significant fraction of the company.
If they do well, they normally convert to capitalism where the workers don't own the company any longer, and the original staff cash out.
Re: (Score:2)
You're making the same flawed argument as others in this thread, that any kind of common ownership is communism. It's not. Depending on which definition you use, communism is about the economic system, the system of government, or both. If your examples are privately owned companies in a market system, or farm cooperatives within a traditional economy (like the kibbutzim that another person picked as an example), they're not communism.
It's like saying that public roads or schools are socialism. They onl
Re: (Score:2)
True Scrum, like True Communism, doesn't work. It's not about North Korea not doing it right, they're not doing it at all. A lemon is not a bad apple, it's simple not in the same family. If you're going to apply the No True Scotsman fallacy argument, you should start by (a) not bothering, at least with me, and (b) not bothering, because you're probably not understanding the argument.
Re: (Score:2)
And why should I put in effort beyond pointing out that two species are different?
Re: (Score:2)
If you don't want people to think that you're a moronic apologist for communism, you might want to show that you read more than two sentences of my earlier comment before getting triggered into a reflective but stupid comment. I gave two prominent examples and asked for what the OP thought was an example of working communism.
And you could also make an argument that is right on its own terms. The DPRK government and its official philosophy reject the idea that the dictator owns everything. Just a few year
Re: (Score:2)
Communism works as soon as people prefer working to having others work for (or instead of) them.
Re:Communism (Score:4, Insightful)
hahahaha somebody's wearing blinders. /because of the CIA/.
Yeah, communism's failed
Everywhere communism exists you have more corruption, more disparity of wealth, and more inequality, oppression, etc than with capitalism. And it has nothing to do with the CIA, it has to do with the fact that people in power are corruptible. Capitalism has its flaws, but when allowed to work properly (free market) it's statistically the best thing we've found.
Oh, but hey, it must have failed that last time because {insert implausible explanation to make you feel better about justifying your like of something that's insanely broken}.
Re: (Score:3)
The difference between Scrum and communism is that communism works if the CIA doesn't undermine it.
I know, right? The glorious successes of the USSR, Cuba, Cambodia, North Korea ... how can you just ignore all that?!?!?
Re: Communism (Score:3)
That's a common confusion. People who don't know much about left-wing schools of thought hear "Communism" and they promptly think of Marxism-Leninism and its offshoots Stalinism, Maoism, Juche etc.
The equivalent from the other side is someone from the left to hear the expression "free market" and promptly think of Mussolini, Franco, Pinochet, the CIA doing political assassinations all around, and drones exploding middle eastern marriages.
In both cases the reply is "you're a little confused", but more often
Re: (Score:3)
"That's not true Communism! If Communism didn't work for you, you were doing it wrong. Communism didn't fail you -- you failed it." is literally exactly a classic defense of Agile or Scrum, just with the noun changed. Perhaps vice versa, given that that form of argument was old when Agile and eXtreme Programming were first devised..
Or were you thinking that MaoÃsm, Juche, or the Khmer Rouge is what people should think of when they think Communism?
Re: (Score:3)
is literally exactly a classic defense of Agile or Scrum
Thanks for proving my point.
By the way, here are two examples of working communism. No, neither is Marxist-Leninist or a derivative. Yes, they're both free-market-based. If that sounds contradictory to you, yes, you're confused -- though I doubt you'll be willing to un-confuse yourself anytime soon. Having fully formed dogmatic certainties on how the world works is too tempting to be easily given up: Mondragon Corporation [wikipedia.org], Kibbutz # Economics [wikipedia.org].
Re: (Score:2)
Your examples of "working communism" are cooperatives that make up relatively small parts of market economies in parliamentary democracies. Yes, one of us certainly proved the other's point.
Re: (Score:2)
Your examples of "working communism" are cooperatives (...)
That's always interesting to watch. You start getting the answer right, as quoted above. But before that can grow, your ideological dogmatism takes hold and leads you astray. Heh, reminds me of my Libertarian phase, almost two decades ago, when I misargued and strawmaned the exact same way. Good times -- and also simpler times, for certain.
Re: (Score:2)
Communism is by definition an economic and/or government system. It's not a catch-all term for shared ownership of things.
You're just trying to define communism down like a bunch of other Commie apologists. You, like them, should know better. The rest of us do.
Re: (Score:2)
Communism is by definition (...)
~ rolls eyes ~
Re: (Score:2)
The difference from Scrum is that for example USSR didn't claim to be communist. Developing towards communism was explicitly the goal, but all the way through the 80s those were just lofty goals they were failing to get close to.So, it doesn't match the textbook definitions or and they didn't claim to be practicing it.
The method isn't the problem. (Score:4, Interesting)
When done right, it's pretty effective at controlling renegade devs doing whatever the heck they want rather than work on what actually needs to get shipped in a timely manner.
The problem is the "done right" part. Scrummasters being the ultimate problem. Scrum masters are basically temporary do nothings that should work at eliminating their presence. But most work it in a way to create a permanence for themselves, in a typical "survival instinct" way.
The scrum guide is like 17 pages. Any dev worth a 4 figure salary can learn it and apply it in under 2 hours. Technically, the Scrummaster is just there to iron out the kinks in the early sprints, and should disappear. But they don't work out the kinks, so the devs get to resent the whole thing. Backlog grooming takes as long as possible even 20 sprints in. Stories are poorly written 6 months in as if they were written by someone who doesn't know what a Story is on day 1. Versions are poorly defined, Epics don't have end goals. Sprints are poorly planned.
Here's where scrum comes in... (Score:5, Insightful)
Re: (Score:3)
Comparing scrum with communism... (Score:3)
... is, of course, anti-communist bull. But even 30+ years after the cold war the anti-communist dogma that primarily feeds on not wanting to know what communism even means is as virulent as ever...
Re: (Score:2)
How the fuck is scrum comparable to communism?
Re: (Score:2)
Real communism has never been tried, right?
Re: (Score:2)
... is, of course, anti-communist bull. But even 30+ years after the cold war the anti-communist dogma that primarily feeds on not wanting to know what communism even means is as virulent as ever...
Found the commie! /s
Re: (Score:2)
What does communism mean?
It means a spectrum of ideas that is wider than anyone who uses the word derogatorily wants to know about.
Given this, your additional questions are irrelevant.
Re: (Score:2)
Communism is Soviet power plus the electrification of the whole country.
--Vladimir Lenin
Soviet power is Communism without electricity.
--Logic
Re: (Score:2)
What does communism mean? What is "true communism"? Has any society ever been a true communist society? If so, which? If not, why not?
The 19th century economically successful 'pure communism societies' such as Shakers and Harmony Society were not self-sustaining, because they were also celebrate.
Draw your own conclusions :-)
Re: (Score:2)
I'm not a sociologist or a social political scientist. But I suspect part of this is the ability of a group of people to subordinate their own personal desires (of all kinds) for the group benefit. That's an explanation I've read on Shakers, etc. The problem is that pattern of behavior seems to be unusual, most people will act in their own perceived self-interest. And that's an argument why communism fails in larger groups.
Independent of whether Scrums work on complex projects, from my observation some
If only. (Score:2)
If only any of the Agile cult can be as productive.
Re: (Score:3)
Well, cancer grows and grows, takes up all the space it possibly can, consumes the resources that the benign cells would need, starves them and eventually forms metastasis in other organs of the body.
Yes, it's apt.
Re: (Score:2)
Unlike agile/scrum.
Re: (Score:2)
Successful... well, it propagates and continues its existence at the expense of the host, until it kills the host.
Still saying the comparison is apt, sorry.
_Bad_ scrums are cancer (Score:2)
They metastasize, and teach the attendees and the managers terrible habits that spread. It takes some diligence to keep them useful.
The Problem Is Agile (Score:3)
From what I read in screeds against anything agile, most people just want to be told what to do. And most of the rest want to tell someone else what to do.
This works out, because mangers want to tell people what to do. To meet that market need, consultants transformed agile into Agile - a micromanager's dream!
This, of course, upsets the people who do not want to be told what to do.
Nobody's happy. Maybe they should rebrand it "democracy" and tell us it's the worst thing except everything else.
Re:The Problem Is Agile (Score:4, Interesting)
Agile is the thinly veiled attempt to shift the workload of management onto the working people. Why the hell we need managers if we now do their job is something nobody told me, though.
Re:The Problem Is Agile (Score:5, Insightful)
Agile is the thinly veiled attempt to shift the workload of management onto the working people. Why the hell we need managers if we now do their job is something nobody told me, though.
That's little a agile. And, frankly, I liked that aspect. Most software managers have no idea how to manage anything and were promoted into the positions only because they were good monkey coders. I love it when they get the hell out of the way.
Big A Agile is all about micromanagement. They have "innovations" like SAFe which have lots of rules and little flexibility. They still "value people over process" but they really mean they "value scrutinizing people over questioning process." Newspeak like that is what dumb managers think smart managers sound like.
Re: (Score:2)
What I need a manager for is to make sure the resources I need are available at the right time, place and amount. I don't need him to tell me what my job is. I was hired because I know what I need to do. I need him to provide the resources I need.
If he can't do that, I'm better off without him.
Re: (Score:2)
What I need a manager for is to make sure the resources I need are available at the right time, place and amount.
You don't want a manager. You want a signaling system.
I don't need him to tell me what my job is. I was hired because I know what I need to do.
Yet you want to define what your boss does. Curious, isn't it?
Re: (Score:2)
You don't want a manager. You want a signaling system.
What's the difference?
Yet you want to define what your boss does. Curious, isn't it?
Boss in name only. Once you notice how to play corporate, you become his boss.
There it is (Score:3)
...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
And there it is. If you have a good team, the methodology doesn't matter much. Get out of the way, protect the team from interruptions, and let the team work.
Re: (Score:2)
I will say that, conversely, that objective of getting useful work out of clueless developers is almost certainly an impossible goal, but remains the dream of management.
One big thing is estimates, where you declare a "complexity score" for a task, and one misguided piece of guidance common is "a task is equally complex for anyone that would work on it". This lights up management dreams where the cheap readily available low quality software developer "should" do just as well as a well recognized industry e
Re: (Score:2)
Get out of the way, protect the team from interruptions, and let the team work.
And that should be the mantra of any manager.
It already is the mantra of the good ones.
Don't use a hammer as a screwdriver... (Score:2)
Re: (Score:2)
tl;dr: Scrum is good... at everything but the stuff it's used on.
Scrum.. by slayer. (Score:2)
The reason why scrum sucks is because your time is less valuable than you think. If gathering requirements and validating correctness are more important, time consuming, and difficult than development (like they are at most places); then it makes sense for development to use a process that allows those activities to run as fast as possible, because those activities are the bottleneck. Even if it slows down development with low value meetings. Every time I've seen scrum "not work" its because "product ow
Yes (Score:3)
I have not seen a single case where daily micromanagement meetings contribute anything. Except frustration.
Now that I am (semi?)retired, I have decided not to accept any work that involves such.
Scrum at e every job for 20 years (Score:2)
I've been threatening for years (Score:2)
I've been threatening for years to write a wonderful paper called "Why Agile is (Mostly) Bullshit". However without a replacement methodology to give managers a set of pretty charts and the appearance of control, it would do no good. In fact, having been in the industry as both an individual contributor and/or manager for 40+ years, I could safely broaden the title to "Why Methodologies are (Mostly) Bullshit" without much change. I think as long as IC's understand that their management is for the most a bun
It's a tool (Score:2)
Like any tool it can be misused. Add to that that it was hyped, and you'll see lots of companies only doing it because it was hyped and not because they understand where it would benefit them.
Also in my experience, "productivity" for software developers is not actually a goal. That's why people still write overly verbose code to the point that it's hard to read what's actually happening.
Think different (Score:2)
Rewrite the headline (Score:3)
This story is in violation of Betteridge's Law of Headlines.
Frustrating... (Score:5, Insightful)
Second, Scrum can't fail because Scrum is whatever you want Scrum to be. There's no right way to do Scrum, so if it doesn't work for you, you aren't as bright as you thought you were.
I see this pretty much all the time for advocating for scrum. Doesn't that mean you aren't advocating for nothing in particular if anything can be Scrum? Also the "no true scotsman" fallacy of "oh if it failed, it wasn't *true* scrum".
The reality is that, as *the* project management self-help go to of the last couple of decades, the most obnoxious management flocks to the buzzwords. Since, as they say, Scrum can be whatever 'you' want it to be, it ends up being whatever a dysfunctional management wants it to be.
Now fine, what else is new, dysfunctional management is agonizing. Except somehow once they armor their thoughts in the buzzwords of "Scrum", discussion on process improvement is closed. Any "hands-off" that might have been in place is out the window, they are going to micromanage team processes. The industry standard buzzwords are in place, there's no way there's any feedback to be had. In our case, we had a self-organizing team, but some executive felt that Scrum was the buzzword that was going to fix a certain other productin his organization (their technical work wasn't really at fault, their business case was just a bad one), but if Scrum promised to fix his 'bad' team, think how it would do for everyone. So they paid an outside consultancy to come train on Scrum, management attended, wrote notes, and had a follow-up training where they amended the guidance to "correct" the training to their opinions. So we had freedom to do what worked for the team before, then Scrum came around and mandated a great deal of micromanagement and meetings.
I've seen teams skip daily meetings, others have a 15 minute "stand up" every day (because the training said to limit it to 15 minutes), then a 15 minute mandatory "parking lot" (because 15 minutes was not enough for a certain technical team member to speak as much as he wanted) followed by a 30 minute "status meeting" because management didn't follow what the other meetings meant>. Weekly two hour "scrum planning" meetings with weekly 1 hour "retrospectives" where people say the same stuff over and over again and no one owns or wants to own fixing anything listed as going wrong, but it's worth spending every week griping about it anyway.
Estimating was one of the weirdest ones. The training was "estimates can't be used to estimate completion time, they are just abstract measures of complexity, that shouldn't matter who works on it". Which of course is utterly useless and bogus. It was right that time boxed estimations are generally crap, but a "complexity score" doesn't really help anyone, because management *will* ascribe a time value to it. The "estimate value is the same for a task independent of who gets assigned" plays into a management dysfunction where developers are seen as interchangeable cogs. Management gets frustrated why some 20 year veteran in the industry can reasonably handle a difficult task better than a new college hire, when scrum taught them that software development tasks are equally sized no matter who works on them. Finally it gets to the point where you estimate "4 points" and management says "ok, so that's two days".
I will confess to a conversation with one person that seemed to sincerely think Scrum improved their work, but it was a specific and rare circumstance. Most of the time I see Scrum come from top down, from busybody management that's not very good, but the buzzwords bolster their micromanagement. In her case, they struck first, to tear down some nasty top-down processes that weren't "AgileTM" and used the industry buzzwords to basically advocate to let this team actually self-organize and do things the way they want, and only be held accountable for the final outcomes.
Re: (Score:3)
E.g in your case, a Retrospective would conclude: we have to long daily stand ups. Wrong is A we should do B instead.
What do you know, that is exactly one of the things that are mentioned, and guess what? Management says that the Scrum training said this was a reasonable approach for management to participate.
That's my whole point, that the folks that need to argue from a brand like "Agile" or "Scrum" rather than the benefits of specific methodology are generally managers looking to establish their "vision" in a "hype-compatible" way that allows them to assert their correctness.
When debating in a forum, if someone complai
Meetings are the problem. (Score:3)
Meetings are established as lowering the intelligence of those involved.
https://www.inc.com/jeff-haden... [inc.com]
https://www.theguardian.com/sc... [theguardian.com]
https://psychcentral.com/news/... [psychcentral.com]
In consequence, you want a system with as few meetings as possible to achieve the desired result. Scrums are a system of maximal meetings.
The whole agile approach makes me think of parallel processing through lightweight threads and factories, with the attendant problems of non-trivial parallelism and the latencies involved in launch and cleanup. It's suitable for some problems, but not others. Indeed, if you look at parallel processing from embedded computing through to HPC, you see a wide range of different approaches, dedicated tasklets being not particularly popular in the grand scheme of things.
I don't know what form of agile you'd use with software development through formal methods or via test-driven development, since they're not really amenable to splitting up into precise 2-week task fragments. I could see a looser structure being useful, where implementors are given certain fragments to implement or maintain, but even there, interactions and interdependencies would play havoc with trying to isolate fragments. And yet, TDD and FM are the two approaches that are pretty-much guaranteed to produce the results you wanted, even if they can't tell you when you'd get them.
I follow the JFCI methodology (Score:2)
Just Fucking Code It.
Funny ... (Score:2)
... you truncated the bit about communism.
Fourth, many people got triggered by my comparison of Scrum and communism...
The original:
Fourth, many people got triggered by my comparison of Scrum and communism. They say communism is great but recognize they have never lived in a communist society. They keep mentioning this book they read and how every person who shed blood under communism was "doing communism wrong."
Call the cancer by its true name: Taylorism (Score:4, Interesting)
It didn't work for what it was originally designed for, and it especially doesn't work for knowledge work, for which it is uniquely unsuited.
The main purpose of systems like these is not to work more efficiently, but to measure success as compliance with a proscriptive process in lieu of actual productivity.
You can never manage your way out of not having developers capable of delivering what is asked of them. You can only generate artifacts to limit accountability at the transition point between the technical and nontechnical.
4-6 hour standup meetings... (Score:2)
At a previous place I worked, the daily standup meetings took 4-6 hours. Daily. The Scrum master would demand Bill the Developer justify why she isn't done with each of her deliverables, one by one, Bill would point to Alice the Developer, say, "She's blocking me!!!!111One". Alice would reply. Then the next item on the list. All that would start with the next developer. I was in Ops, so all the developers would be pointing their fingers at me, because I did cruel things like demanding they at least ha
Re: (Score:2)
Sounds like a less dangerous form of Communist Self-Criticism sessions.
The less dangerous part being you had an almost perfect chance (you could have collapsed and died because of it?) of living through it.
Any process can be done poorly (Score:2)
Regardless of the merits or flaws with any methodology, it can be abused and misused and done poorly.
For example, if your scrum team is spending more time talking about the work, than doing the work, they're talking too much. That's not scrum's fault, that's mismanagement.
The least worst option (Score:2)
Let's consider the other options.
Waterfall is incredibly laborious and expensive. It has *all* the meetings Scrum has, but longer, plus books full of documentation that nobody ever reads, and a laborious change control process.
Ad-hoc development (commonly used in very small shops) is haphazard and lacks intentionality, and doesn't scale.
Scrum has issues, yes. But all human-designed processes have issues. Personally, I don't ever want to work in a waterfall process again, and will turn down any job that clai
What does the customer think? (Score:2)
From my point of view (Score:5, Insightful)
Re: (Score:2)
It's not useless, except when it is. I've seen quite a few groups where incompetent engineers game the scrums to hide their lack of accomplishing anything useful, and where a weave of scrums of too small or too large a size don't permit the critical engineers to ever talk directly to each other. The damage is enhanced when the people at the scrum are never permitted to speak directly to the client, so the targets of the scrum have filtered through so many layers of management the project has become the clas
Re: It adds value (Score:2)
Not knowing when you are stuck and need help is far more a sign of a junior developer.
Re: (Score:2)
Well, we can agree that it adds cost.
Whether it also adds value is debatable.
Re:It adds value (Score:4, Insightful)
It's not "just let me program", it's about how Scrum frequently enshrines bureaucracy.
For example, company has a customer base, and there's a customer requirement that would be nice to work with developers on. Except that won't do, we have marketing people to manage requirements, so marketing gets first pass at triaging requirements, despite not having any idea how easy or hard they would be, or in many cases outright failing to understand the customers comment before rewriting their interpretation. Then it goes through the development manager, who also is a non-technical person and that person becomes the stand-in for the "customer" in the Scrum methodology (because after all, why should they bother a customer with this "junk"). So everyone make believes that the stand-in is the "customer" in a way that totally breaks down (the point of having the customer directly involved was to capture nuance and mitigate misunderstanding, but having a clueless stand-in simply wastes time pretending the stand-in understands the customer).
Daily standups are useful to sync with fellow devs about the work, to see whoâ(TM)s stuck and needs help, and if weâ(TM)re making good progress.
In our case, we basically spent the day ambiently coordinating before the "scrum" mandate, the standups are the time where we *don't* sync up, because management coopts the concept to a status meeting.
Retrospectives are useful to learn about whatâ(TM)s working for us and whatâ(TM)s not.
Again, we had ambient conversations before, now every week we spend a lot of time explicitly griping about things that no one will let us change. Nothing is ever said that everyone isn't painfully already aware of, and if anything it's demoralizing to consciously repeat stuff that will absolutely be ignored.
Refinements force us to think about stories. Do we fully understand the request, do we know how to solve it, and do we have a rough idea about the efforts and complexity.
As mentioned above, commonly you don't even have the right people in the conversation to understand the request, and all you end up doing is exacerbating the telephone game. Frequently pissing away way too much time trying to estimate when folks won't really know until they get started. You can make a very quick "this is the lower hanging fruit than that" estimate, but taking the time to tediously score every thing in some abstract point system to gain alleged insight to proportional difficulty is a huge waste of time, because no one has ever been good at estimating.
Sprint planning helps us to think about a logical order to pick stories up, and think about what we can achieve in the coming days two weeks. Devs like to know whatâ(TM)s ahead, and the rest of the business likes to know what we plan to pick up.
Time boxing can be good, but things can get all twisted. You have some business *requirements* that simply must be met, and some items that are likely to drive improved value in your product or team. The "story points per week" mindset distorts this and cause management to worry about the wrong things, the requirements are met and some "value add" is happening, but if the story points don't exactly hit the expected velocity, they flip the hell out even if there's no actual problem at all.
Yes, there are "programming, motherfucker" folks, but what I see are largely people complaining about bad management, and Scrum buzzword compliance is the hallmark of bad management. Conversely, "true Scrum" (to the extent that actually exists) doesn't need to be labeled as such for a team to be successful, as long as they are communicating and stay in touch with the customer and business requirements. So the only scenarios where the buzzwords specifically matters are the mismanaged scenarios.
Re: (Score:2)
Do you have a better way to make sure that a system will be predictably safe for life-safety applications? In theory, having explicitly stated, thoroughly validated requirements (potentially even what DO-178 and DO-278 call "low level requirements") that trace to code and treat procedures, then to test results does not require the V model and a DOORS-like system, but Agile and Scrum don't even try to produce those artifacts. Applying Agile and Scrum to life-safety systems merely gets you stochastic safety
Re: (Score:2)
I'd say it's not about extravert/introvert, but just about Scrum being the banner of the most dysfunctional management and manifests as micromanagement.
No matter how much you like talking to people, it is obnoxious to listen to the same material be repeated every day and deal with a manager who wrings their hands over the apparent disappointing velocity of the occasional weird looking day, despite it *always* working out fine for all deadlines for the last decade.