81–90 of 239 posts
> 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…
Earlier quoted context omitted.
>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!
Developing for a small but demanding set of enterprise customers with concrete (but sometimes arcane) requirements is a very different problem from developing for consumer markets.
> 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…
A specialist working on a platform that doesn't need the whole backend team is isolated and easily skipped over for all accolades
The original Extreme Programming project at Chrysler was a payroll system, so many strategies for handling things like this have been thoroughly discussed in literature and forums in that community.
The most toxic example of Agile/Scrum I've come across so far has been in a company that was non-technical at its core but wanted badly to pivot to a SaaS business model. The type of company that 50% of the employees have the word "manager" in their title yet manage no one (Digital Project Manager, Technical Project Manager, Product Manager, etc). I think its just in a lot of companies culture that if they can instil…
And not just because all of my experiences have been agile (they have not been).
For agile to work well, you need a competent team and manager, AND be embedded in an organization (ie, who determines appraisal of your manager/team) which truly is concerned with prioritizing value to business/customer over, say, "looking good to other managers", or "trying futilely to predict what the software will look like a year from now, because it makes me feel in control" or "weird power struggles with other parts of the organization". Everyone (or at least the majority of those with the power to make you miserable or break your career) has to be really at least trying to work together to maximize business/customer value.
If you have that, is your experience (and your software) going to be good whether you use agile or not? Probably. But agile is a really useful and effective mindset for making your software product _and_ your experience (stress-levels for instance) even better. It works, in my experience.
If you don't have that, is your experience (and your software) going to be terrible using agile or not, in proportion to how much you don't have it? Sure. And agile and especially scrum can probably make it even worse.
> Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. 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, pleas…
> Developers should create a Google Design Document (a fairly minimal, but structured design doc), explaining the project, what goals it hopes to achieve, and explains why it can’t be done in other ways. 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, pleas…
https://go.googlesource.com/proposal/+/master/design/go2draf...
> 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…
As a rule of thumb: anybody who needs regular progress updates on a project is a "customer".
The difference in agile vs other development processes is progress reports are partial releases of working code instead of a percentage increase on a gantt chart.
Google runs on design docs. You define the problem, dependencies, risks, end state, etc, in a 20-page doc, and then you drive its development for 1-2 quarters. Google doesn’t do extreme programming, we do extreme ownership.
I really prefer it to the time I spent working with Pivotal or Carbon5. They were great, but imo not a sustainable process for mature products. Agile is good for driving a new, greenfield MVP... and that’s about it.