Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why do developers at Google consider Agile development to be nonsense? (2016)

quora.com

Post reply on HN
Print view View original

31–40 of 239 posts

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#31

Post by theworld572 »

mmcnl wrote: post #17

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 discover that there is a whole area of code that needs updating in order to allow for your feature to be implemented. This adds on another week of work required.

In a common-sense based development team, what usually happens is the developer has a quick work with the project manager and maybe other devs who need to be involved and says "Hey, I've found out that we need another week to complete this feature because X needs refactoring, do you still want me to continue with this?" then the PM either says "Yes this feature is important, even if it will take another week" or "No, the feature is not important enough to be worth spending another week on". Its really not rocket science.

In SCRUM what usually happens is the SCRUM master will tell you that the rules say that we have already committed to a set amount of work this sprint and that extra week of work falls outside the scope so we should create another card for the extra work and consider this card blocked.

The whole idea of having a rule for what to do in that situation just seems absolutely crazy. Just do whatever makes sense! Its really not that difficult.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#32

Post by anoncareer0212 »

6thaccount2 wrote: post #13
anoncareer0212 wrote: post #4

Earlier quoted context omitted.

I went from waiter -> self-educated SW engineer founding own startup -> sold startup -> Google. (Been on 3 teams, all of which shipped to match HW deadlines) The only thing noteworthy about Google is _there is no process_. Hell, just last week, a coworker and I finally resolved a year-long difference of opinion when it clicked for him that there wasn't a defined system, insomuch as there was one I was defining it, an…

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 renders bugs from the internal bug tracker as post-it notes arranged in columns, with each column representing a bug status (ex. assigned/started work/code in review/done).

This alone caused a ton of grumbling, meanwhile I'm sitting there gobsmacked that Scrum and Agile aren't proper nouns that everyone has highly detailed opinions on.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#33

Post by ChrisSD »

S_A_P wrote: post #27

I consider it nonsense because it becomes dogma at each organization. The problem with that is that they each have their own way of being “agile” and questioning the status quo is futile at best to politically charged at worst. Secondly, well meaning management often thinks that the reason they are having trouble delivering on time is because agile needs to be implemented. If the developers and business analysts don’…

> questioning the status quo is futile at best to politically charged at worst.

Which is antithetical to the agile manifesto. The whole point of agile was to question the current methods and be agile enough to change them as needed.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#34

Post by pas »

Jedd wrote: post #11
gilgoomesh wrote: post #7

I think the answer badly misconstrues the purpose of "short term planning" and "continuous integration" as though these concepts preclude long proof-of-concept projects. The point of short delivery cycles is not to deliver a viable product to an external customer every two weeks. Rather it simply ensures that code remains in-sync with its intended use-case and guards against individuals going off on untracked tangent…

> I think the answer badly misconstrues the purpose of "short term planning" ... 'short term planning' appears to be your construct, not found in TFA. Short term implies reactive / tactical -- not the planned / strategic level that TFA is talking about. It may well be that Agile 'precludes long proof-of-concept projects', given its essence is 'better ways of developing software', which clearly hides a wealth of compl…

Agile (and XP) realised that it's a folly to plan in detail the next 5 years when likely the project, the circumstances, the business landscape, the team and even the technology will significantly shift in that timespan.

This of course doesn't mean that if you have a very concrete goal and you need to do a trial and error iterative research and development project, there is of course no need to do "agile", because the goal is fix, the things you can try is probably largely predetermined, and you already know one of them will work adequately. (Or not, but then at least you might have some form of benchmark target in mind.)

But even then, almost no endeavor starts in a vacuum, so it likely pays off to have some ability to quickly check progress (be it a CI system or just a testbed in the lab, or the aforementioned benchmark), and similarly other aspects of "agile", like try to break up the work and estimate it (think about it, its dependencies, its complexity, your competence for the particular work item, typical pitfalls), let the team know who works on what, interact with stakeholders from time to time, and so on.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#36

Post by taneq »

mmcnl wrote: post #17

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…

I think Agile has the same strength and weakness of any methodology: The people implementing it. If you have good people running and working on an Agile project it's going to go well. Those same people would do similarly well with waterfall, or just sitting in a dark room with a carton of Coke each.

Where your methodology really matters is the how information flows between your dev team, the end users, and any other systems you need to interoperate with. Agile is great for providing development-as-a-service to a client who doesn't know what they want but will know it when they see it (eg. building enterprise software or web apps). Waterfall is great for providing known, fixed functionality (eg. building an ECU for an engine, or a back-end for a web bank).

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#37

Post by zamadatix »

mmcnl wrote: post #17

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…

The problem I've seen with agile is it's too easy to turn into "as long as we complete something that was defined as value this sprint the problem isn't what this team is doing" that many places end up having teams avoiding any large or external issues completely while reporting everything is going great.

You may say it's not a methodologies fault when it's misused but I'd say it IS a methodologies fault if the feedback cycle on the misuse is easily hidden by the process.

In the end I think for many places where agile is put in more value would be had putting that work into the business communication flow. If your biggest problem to solve is you don't know how to work on problems in smaller chunks + communicate when you've done something and that's what you need to reform you're probably doing pretty good and agile will be great. If you're implementing agile for another reason it probably won't fix that problem and agile will be blamed.

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#38

Post by gordaco »

js2 wrote: post #29

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to th…

> Little did my manager know that a few quarters of "meets expectations" had caused HR to drop me into the bottom 5% of the company and so I received a letter from HR that I was at risk of being terminated.

This is disturbing and, I think, a twisted form of grade inflation, mixed with the usual suitspeak where words don't necessarily mean what they mean. If an employee is as good as you think they should be, why would you put it at risk of termination?

For the record, I also work in a big company with long product cycles, meaning that the product I'm working on started more than one year ago, and the first public release is planned for next December, so I feel your pain. Luckily our process is a bit more sane and our manager follows our work closely, so I'm getting good ratings (but I wonder if the grade inflation will continue in such a way that "exceeds expectations" now means "subpar employee"...).

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#39

Post by taneq »

theworld572 wrote: post #31
mmcnl wrote: post #17

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…

> 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. Probably check with the tech lead first, but it's that flexible.

> In SCRUM what usually happens is the SCRUM master will tell you that the rules say [...]

This SCRUM thing sounds evil.

> Just do whatever makes sense! Its really not that difficult.

This is probably the best advice ever for any development team. Just do the thing!

Re: Why do developers at Google consider Agile development to be nonsense? (2016)

#40

Post by malvosenior »

cyknus wrote: post #25
PasserBy2022 wrote: post #23

"leapfrog for the masses" Is this how googlers refer to results of their work and people respectively?

>I would caution against trying to paint "developers at Google" using broad strokes.

There's a lot of irony in saying that about "developers at Google" and then immediately turning around and classifying everyone else as "the masses". Talk about broad strokes!
Post reply on HN