Good Agile — Development Without Deadlines

BigTom writes, "In a recent blog entry Steve Yegge, a developer at Google, writes a fascinating account of life at possibly the coolest development organization in the world. Steve lays out some of the software development practices that make Google work. Go on, say you are not even a little bit jealous. ;-)" From the article:

• Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
• There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
• Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
• Google tends not to pre-announce. They really do understand that you can't rush good cooking, you can't rush babies out, and you can't rush software development.

Yegge also does a fine job of skewering what the author calls "Bad Agile."

Comments

3 meetings a week!

[91degrees]

3!? What do they need 3 meetings for?

Where I work, we have an average of about 1. and sonme of us think that that's too many

Re:3 meetings a week!

[0racle]

My guess is there are a lot of team member introductions.

Re:3 meetings a week!

[Xzzy]

Don't tell people what to work on? And exactly how does that finish projects, ever?

Considering how often Google puts up new features on their site, apparently it works pretty good for them.

Regarding the number of meetings, I only have one formal meeting a week, but can spend several hours a week with a couple other guys talking over the specifics of whatever we're working on. Could be considered "meetings", even though they don't involve sitting around a table and going through an agenda.

Re:3 meetings a week!

[EastCoastSurfer]

Don't tell people what to work on? And exactly how does that finish projects, ever?

This is a direct by product of the type of person that google hires. They look for the really smart self motivated type. This is the same type of person that writes OSS (and no one tells them what to work on and there are surprisingly quite a few OSS projects in various stages of completion). Your comment also ignores the fact that no projects are ever really finished.

Googles method is a good one, and it works for them. I do think the author missed one of the huge reasons that it works - googles hiring practices.

Not true

[Anonymous Coward]

"Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team."

I work for Google and I can tell you right now that is total horse shit. Google are not so different than my previous employers, Oracle and Microsoft.

If anything, working in Google is worse than Oracle/Microsoft due to the people I work with (brainwashed losers.) They are the type of people who want to join a cult.

Re:Not true

[Anonymous Coward]

100% correct you are. // posting anonymously for obvious reasons

I worked for Microsoft myself and I'm at Google now. There's a whole lot of brainwashing going on here at the miracle company. Yes, the benefits package is pretty good, and yes the work per se is pretty cool. But all the marketing hype that makes working here sound like working in heaven is so much inflated. Coincidentally enough, I'm planning on going to Oracle in the coming months -- there are a couple cool positions open in the group where a friend of mine works. Don't get me wrong, Google is cool, but nowhere near as cool as it's portrayed, especially here on Slashdot.

Agile has a place too

[Gnostic Ronin]

I think part of the reason that other companies choose the "Agile" methods rather than the "Google" method is the problem of the customer. The customer needing a custom application needs it by a certain time or it could become outdated or downright useless. Tax software complient with 2006 tax codes are useless after April 15th, 2007. Or if you're making custom software for manufacturing, you can't leave the client without his software after the plant opens, he'll probably cancel the contract. Virus updates would be another big "can't be late" kind of issue. Waitng a month before you can stop a new virus probably means a cancelled contract, and a lot fewer customers.

Google can do this, and pretty much any company that can set its own time-table can use "Google Agile" methods. But you're limited to just those products where a delay of a few weeks or months isn't a major issue. It's simply not true for every type of software developer out there.

Maybe "Agile" methods aren't the absolute best out there, but there are cases where it's simply not possible to use "Google Agile" methods.

Okay, sure

[Z0mb1eman]

- there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

- there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.

- even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.

Sure, that sounds wonderful, as long as:
- you're working with intelligent, competent, creative people
- you have an effectively unlimited budget(relative to most other companies)
- you're working for a software-only company which is only successful because of its innovation, not because it has to deliver specific functionality to specific clients

How many of us can say that? Hmm?

It sounds like a dream job, but let's face it: it relies on individual heroics, from everyone, all the time. Now that's fine if everyone working there is far above average, and "individual heroics" means "enough intelligence and maturity to keep a view of the big picture without being whipped with a rolled-up Gantt chart", but it's a recipe for disaster in most other places.

Is this the emerging ivory tower of Google developers? While I'm happy for the guy, most of the blog sounds like "look at me, I'm developing under near-ideal conditions, why isn't everyone else?"

Don't criticise

[tygerstripes]

It's easy to jump on this guy for making us all feel shit about our inevitable working conditions (you think you've got it bad? Try working in local government...). However, really what he's doing is putting in clear, simple terms some concepts that we all understand deep down, to whit:

- Google is a company whose success is almost entirely based on innovation

- Innovation comes from intelligent, well-motivated people

- The best way to motivate intelligent people to innovate is to give them total freedom (rewards are just to give them a direction, NOT to motivate them - they are motivated because they love what they do. Try offering rewards for something they don't want to do, and see what happens...)

- Most companies (even software companies) make the majority of their money through churning out the goods, not innovating - Most companies do not have the funds or the original culture to even contemplate the above working practices

- It would be lovely to work for Google.

Personally I'm really glad this article got posted - it's not telling everyone how everyone should work, but it does offer insight into how Google works, and that's valuable insight indeed as long as it's not taken out of context.

Just keeping the talent happy...

[rockmuelle]

Google is not a software development firm, but an ad sales firm (check their 10-K if you have any doubts). It uses software to attract viewers in the same way television networks use programming and magazines use articles. Under this model, it makes sense to give developers a large amount of freedom to develop whatever they want. The final type/quality/status of the software doesn't matter nearly as much as the fact that there are new features appearing on the site from time to time to attract new viewers..er, users... and keep old users. Most of the applications probably won't amount to much, but just like with any media company, you only need one or two big hits a season to keep people coming back.

Google develops a large amount of its content in house in much the same way old movie studios developed all their films in house. For Google, the talent is not actors and directors but developers. Movie studios learned that you treat the talent well to keep them around and Google has taken that lesson to heart. Developers tend to want complete freedom to work on what they want with no deadlines and giving them this is the easiest way to keep them happy. Call it 'good agile development' or whatever else you want, it's really just keeping the talent happy in the hopes that they'll keep developing content to attract users.

Unfortunately, software companies that rely on software or service sales for revenue cannot take this extreme approach to agile development. They need to deliver software on occasion or someone else will replace them in the marketplace. Agile development is still the best way to go, but unbounded development only works if software isn't your primary source of revenue.

-Chris

Re:No Wonder...

[EastCoastSurfer]

I know you're just flamming, but what does 'beta' actually mean? It's just a label on a given version of a piece of software. Would it make you feel better if tomorrow google changed their gmail from 'beta' and put 'production' on the page? That is what most other software companies do. Especially if the product has been up and running successfully as long as gmail has.

In reality most software is either continously developed or it dies. I've worked on numerous software projects and few if any have ever reached a point where no more work was required. Even if you found and fixed every bug (haha), feature requests will continue to come in as people use the software. As soon as bugs/feature request quit coming in most software is essientially dead b/c that means people have quit using it.

besides search/adds?

[RingDev]

Is there any Google app that is truly profitable other than Google Search and Adds?

As you mentioned, with their huge amount of capital, they can afford highly in-efficient project management. I pity the fool who tries to introduce this management style into a smaller organization with budgetary concerns and uncontrollable deadlines. Not that I wouldn't mind working in their environment one bit. Either as a coder, or as a PM.

-Rick

Re:you can't rush good cooking

[MikeBabcock]

The terms "rush" and "do quickly" are different.

Yous till can't rush a stirfry ... if it takes 3 minutes, it takes 3 minutes, not 30 seconds.

Its not rushed if its done in the right amount of time, even if that amount of time is short relative to other foods.