41–50 of 239 posts
There is unfortunately a large gulf between “agile” and “Agile” development these days. The former refers to development generally in line with the agile manifesto, with processes tailored to the needs of the team and the project. The latter is a buzzword used by consultants to convince management to put their favored bureaucratic method in place, usually some variant on the scrum system.
This is mostly what I see happen too, "Agile" is used an excuse to introduce some type of bureaucratic process to fix what is actually pathological cultural / leadership issues.
I feel like people who are opposed to agile and scrum often make out things of it that are in no way prescribed by these methodologies. For example, I see people mentioning the idea that with scrum, you should release working software every sprint. This is not the case. The idea is to deliver a _potentially_ shippable product increment - a.k.a. not building 10 bridges in parallel if there's no need for it. Some might…
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you di…
No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a thing done. If and when it becomes clear that this feature is too complex, too big, or whatever, then it can be reestimated, or decomposed or reevaluated. It's supposed to be agile, not rigid and fragile.
"leapfrog for the masses" Is this how googlers refer to results of their work and people respectively?
Earlier quoted context omitted.
Can you explain that better? Basically in a nutshell they don't have worthless agile processes?
Overall picture: Google recognizes it's a large company that has an extreme diversity of teams with idiosyncratic goals and personalities, and doesn't prescribe _anything_ Dollars to doughnuts, there's multiple teams doing extremely prescriptive Agile, but I've never seen one in 3 years in a 2,000 employee office. By far the most organized team I've been on merely kept track of bugs using an internal web app that ren…
Earlier quoted context omitted.
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you di…
> What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Pro…
This article makes a common mistake: Scrum and Agile are not synonymous. Given that error, the conclusion is nonsense. And besides, even Scrum doesn’t require a delivered product each sprint. Just an updated status and increment completed. If I’m building a new server and client architected system, the early sprints may be getting certain design details down. More documentation than code. Later on, I may have sprints…
It does not. It merely acknowledges that Scrum is the most popular and widely practiced incarnation of Agile and is what most developers are familiar with.
From the article: "The simple high level Agile Manifesto is something I think is close to the way Google engineers think about software development...Google development style exemplifies the type of individual empowerment talked about in the principles."
And: "While the high level Agile Manifesto is flexible enough to work with these principles, these are very different than the short-iteration low documentation Agile/Scrum process which has become synonymous with the word Agile."
Earlier quoted context omitted.
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you di…
> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a t…
Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and that a sizeable (if not the majority) amount of developers loath working in SCRUM teams. So wouldn't we just be better off if the industry ditched SCRUM entirely?
Earlier quoted context omitted.
> What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Pro…
I think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...
Earlier quoted context omitted.
> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a t…
Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business. Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and…