Does somebody have more on this? I'm never sure how to structure my design documents, how does a Google Design Document look like, is there a template somewhere on how to write one? This would be super helpful, please.
Why do developers at Google consider Agile development to be nonsense? (2016)
51–60 of 239 posts
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#52Earlier 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...
https://www.scrum.org/resources/what-is-scrum
"This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together."
Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cannot say both that SCRUM is not authoritative and lets you do what you want, and then also say "you're not doing scrum correctly".
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#53Earlier quoted context omitted.
Is "the masses" offensive?
For someone who doesn't want to be painted in broad strokes, it seems like a very broad brush to paint non-Googlers with.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#54Earlier 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…
Some questions are easy to answer, but many questions can only be answered by doing a thing that takes work. And Scrum gives you a framework that tries to put a limit on how much work goes by with no answers.
So it uses a simple schedule.
The team works for X weeks, working on implementing specific tasks. (Which in turn answer some questions.)
Then the team stops, reviews their progress on the larger product, and adjusts plans accordingly. Now "do what makes sense" has demonstrably advanced.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#55When you building hard tech products (e.g. borg or tensorflow), the actual risk is technology and competition, and since this is new technology, there are not that many customers. In this case the risk is in the architecture (i.e. it would be hard to change the core architecture) and in the technology, since you do not know what kind of application will be build on top of this new technology. In addition, you face general competition risk, since the market can usually absorb only one dominant architecture.
So in this case, you invest much more time in design and careful construction.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#56> 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…
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#57Earlier quoted context omitted.
Is "the masses" offensive?
For someone who doesn't want to be painted in broad strokes, it seems like a very broad brush to paint non-Googlers with.
And then, of course, nobody said you're part of those masses anyway. Maybe you're not. Do you enjoy Google product X as other hundreds of million do? Then you're part of the mass that enjoys it. Otherwise you are part of the mass that doesn't.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#58Agile at its core, to me as an engineering manager, is: - People over process/tools - Plan-able execution and pivoting quickly in rapidly changing environments - Create consistent, repeatable work delivery - Retrospection, learning and iteration over time - Tools (can) support the process to multiply efficiency but do not solve the core goals and problems
Like the author of the comment said, the details of how you execute "agile" is where things get bumpy for teams.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#59"leapfrog for the masses" Is this how googlers refer to results of their work and people respectively?
Is "the masses" offensive?
[1] Pick a dictionary and you will find references to lower-classes, the not-elite or the common people. https://www.merriam-webster.com/dictionary/the%20masses https://en.wiktionary.org/wiki/masses#English https://www.vocabulary.com/dictionary/masses
[2] Put in to words nicely here https://medium.com/@steve.yegge/why-i-left-google-to-join-gr..., but you can feel it in many of Google's products where they make all the major decisions because they don't believe users are as capable of making good decisions as Googlers.
Re: Why do developers at Google consider Agile development to be nonsense? (2016)
#60I 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…
That kind of time allows some actual deep thought to happen. Some kinds of outcomes won’t happen any other way. I agree with that point in the quora answer.
This comes to mind as a recent example of an engineering project that had no incremental alternative: https://webkit.org/blog/9329/a-new-bytecode-format-for-javas...