-
alex_gaynor
8 months ago
|
link
| on:
Why do some developers at strong companies like Google consider Agile development to be nonsense?
Questions (and answers) like this really ought to start with a definition of what they mean by “Agile”.
The top voted answer appears to be critiquing a very rigid Capital-A-Agile methodology, but none of it comes through to me as a valid critique of a more general lower-case-a-agile methodology: deploy regularly, tight feedback cycles with users, integrate feedback.
-
I guess these discussions are always a bit futile, because “Agility” is by definition a positive property. It’s a tautology really.
Most criticism of agile methods are more focussed on a specific implementation (scrum at company X), and the usual response is “this is not true agile”.
-
“this is not true agile” I’ve been guilty of this in the past. Agile is good, therefore if what you’re describing to me isn’t good then it’s not true agile.
But after years of Scrum at various shops, sometimes under the guidance of pricey “Scrum coaches” consultants I’m totally burnt out and disillusioned by it.
As you say agile is by definition positive but beyond this, I think there are still a lot of good ideas and principles in the early agile movement just not in the Scrum process itself (which doesn’t predate Agile) and what it has come to represent.
-
I would define Agile as “follows the principles of the Agile Manifesto”. This implies a few things:
-
The Manifesto devalues things like comprehensive documentation. This can be criticized and discussed.
-
Scrum is only one possible instance of Agile. Not necessarily the best, maybe not even a good one. I would suspect that people discussed that to death already when Scrum was fresh.
-
You can do Scrum without Agile. Scrum is usually defined superficially. This means there is a lot of room for variation including stuff which undermines the Agile intentions. Second, it helps the consulting business, because how could you get Scrum right except by oral teachings of certified people?
-
The Manifesto devalues things like comprehensive documentation. This can be criticized and discussed.
This aspect is a bit peculiar. Do they devalue software-documentation? (which is how I understood this principle). Or maybe it can be thought of a devaluation of a requirements-library/document. I came to terms with this principle in the sense, that it meant as an advice to avoid wasteful, up-front documentation, because clearly you cannot build a good product without documentation.
-
From the manifesto:
That is, while there is value in the items on the right, we value the items on the left more.
It’s not “documentation doesn’t matter”, it’s “deliver something that works or your documentation is pointless”.
-
-
The key bit of superficiality that reduces Scrum’s value is that people ignore the fact that Scrum does not mandate a process:
It is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. What is Scrum?
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum Guide
They take the initial process guide, defined in Scrum as a starting point to test, reflect, and improve upon, and treat it as a big collection of interwoven mandatory components. It makes middle management feel good as they get to hold meetings, see progress, and implement a buzzword, but avoids all of the valuable parts of Scrum.
-
-
Bertrand Meyer has some criticisms (and compliments) of the core ideas, especially user stories vs requirements.
-
-
-
okay, I haven’t watched it fully, but skipped over a few parts ,but I made sure to look at the user storeis and requirements parts. I am a bit torn on his view, because I can relate to his feeligns as a software user, that many times his user-story was forgotten and he attributes this to not generalizing them into requirements. However, I wonder if the lack of a requirements document is really the reason. Also, I think he must have forgotten how unusable a lot of requirements-backed software has been.
I share his sentiments on design and architecture work. However, good teams with good management have always made it possible to fit such work into the agile workflow. I attribute to agile consultants, that throughput and “velocity” have been overemphasized to sell agile, when it should much more be about building good products.
He lost me when he commented on test-driven development.
-
-
-
-
-
-
I would argue that what you’re talking about there is more the consequences of adopting continuous integration and making deployments less painful, which one might call operational agility, but it has very little to do with the Agile methodology as such, at least from what I can see.
-
-
-
-
Can you explain? I don’t see the words “tight”, “feedback” or “cycles” here http://agilemanifesto.org/principles.html
-
Presumably: The main difference between collaboration with customers (vs contract negotiations) is that rather than getting a single document attempting to describe what the customer wants up front (feedback cycle = one contract) you continually work with them to narrow down what they actually want (shorter/tighter than that).
-
the first principle, satisfy the customer through early and continuous delivery of valuable software, implies it. the third, deliver working software frequently, implies it. the fourth, business people and developers must work together daily, is an out-and-out statement of it.
-
-
-
-
-
Regardless of your experience and opinion of utility, those strategies are core to Agile and have obvious analogues in other industries that Agile draws inspiration from. They aren’t unique or novel products of Agile, but I think it’s fair to say that’s how they reached such widespread use today. It’s definitely incorrect to say they have little to do with Agile methodology.
-
-
-
-
After having been making the error of using the word “agile” in the latter generic sense for some time, I came to realize that pretty much nobody does it. When you say “Agile” business people automatically think “Scrum” and it works (still) as a magical incantation. When you try to talk about the actual merits of agile approaches (plural) they tend to phase you out and think you’re trying to look smart without knowing anything.
-
The top voted answer appears to be critiquing a very rigid Capital-C-Communism ideology, but none of it comes through to me as a valid critique of a more general lower-case-c-communism ideology: democratic, common ownership of the means of production, state and classlessness
-
-
I find it quite strange to see many comments (here, now; but also elsewhere when this comes up) about how (a) gamification detracts from the site’s main purpose (being a knowledge base) and (b) it’s hard to get points now, well-thought-out questions and answers often don’t get many points, other people got lots of points without much effort.
Surely (a) implies that the points are meaningless, and hence (b) is a non-issue? This seems especially true when it comes to questions: the few times I’ve asked a question on SO or another stackexchange site, it’s because I want to know the answer; not because I want more meaningless internet points.
The other common complaint is overly-strict closing, which certainly does sound like a delicate issue which could put off many people from participating further.
-
Actions are gated behind points. You can’t answer “protected” questions or post links until you have 10; can’t comment until 50. Then, too, there’s a network effect where people are, perversely, more likely to upvote answers by high-reputation users. Thus, the points do matter; the ones that matter the most are the hardest to get; and there’s an entrenched group of high-rep users who accrue reputation just by virtue of having high reputation already.
-
Actions are gated behind points. You can’t answer “protected” questions or post links until you have 10; can’t comment until 50.
Ah yes, I forgot about this.
The failure mode I was mostly thinking about was considering SO reputation when comparing prospective new hires, which would give these ‘internet points’ a real economic value, and cause all sorts of distortion.
Thus, the points do matter; the ones that matter the most are the hardest to get;
Do you mean those initial 10 or 50 points? I see how this is bad, but also why something like that is necessary to prevent spam (lobste.rs uses invites for a similar reason). I don’t know enough to comment on the particular tradeoffs (e.g. how SO spam correlates with reputation requirements).
Then, too, there’s a network effect where people are, perversely, more likely to upvote answers by high-reputation users… and there’s an entrenched group of high-rep users who accrue reputation just by virtue of having high reputation already.
I put this all in my “so what?” bucket :)
-
-
I personnally wasn’t complaining on the gameification of the site but the difficulty to get reputation nowdays (which you do mention).
I do agree with your points and your second paragraph made me rethink my arguments.
To be frank, my main motivation for getting reputation (which is probably a bad one) is if I ever want to find a job using StackOverflow Jobs or if a potential employer decides to look up my profile on StackOverflow. But I’m probably stressing over nothing.
-
-
I think it’s harder to gain reputation today than it was a few years ago. I program in C# and all of the basic questions, things like : “What is an abstract class” have already been asked. These questions have garnered huge amount of reputation to people (see https://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo) for what is basically basic knowledge of the programming language.
Today most questions in established languages like C# are either: 1- a duplicate, 2- very specific so as not to be interesting to most people.
This means that the question will not get many views and votes making significant reputation gains almost impossible. The most votes I got was on a very simple syntax question for Rust. Mostly because the language was new and these simple questions hadn’t been asked yet (https://stackoverflow.com/questions/26665471/semicolons-are-optional-in-rust/26665514#26665514).
If someone wants to gain reputation in any meaningful way, you have to start following a new language/framework/library, hope that it gets traction (and thus a lot of traffic on Stack) and answer the early easy questions about it.
I’ve seen a prospective employer list all week-end hackathons as part of their company culture as if this would sway me into getting a job there.
Eh… I don’t see how doing a 72 hours shift of unpaid overtime is anything but exploitation. Does anyone really considers this a perk?