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."

3 meetings a week!

[91degrees (207121)]

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!

[jimstapleton (999106)]

/\ informative/insightful/underated the parent please.

In most places I've worked it's been no more than once per two weeks for the prorgrammers. The buisiness side of things has more, but hey, that's what business people are payed for, to sit around and talk while others do the work.

Ok, the business side fo things does do work, but the programmers shouldn't have to go to meetings like that. Their meetings are more like the occasional team huddle to verify that they are working on the right path - 5 minutes, quick, and to the point

Re:3 meetings a week!

[0racle (667029)]

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

Re:3 meetings a week!

[aussie_a (778472)]

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

I think it explains why much of Google's stuff is currently in beta.

Re:3 meetings a week!

[Xzzy (111297)]

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 (310758)]

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.

Must be nice in Candyland

[TopShelf (92521)]

One thing that helps Google in this regard is that they are insanely profitable, and their software engineers as described in TFA are really more like product development entrepreneurs, so it's easier to set up an incentive-based program like this that puts a huge, juicy carrot in front of the developers to keep them headed in the right direction. I suspect that 99% of the rest of the IT world doesn't have this luxury.

That said, it's a very interesting example to consider. Within the coming months I'll be forming a new application development group, and the mechanisms of determining what we'll be working on and how it will be prioritized are TBD. Good food for thought, here...

besides search/adds?

[RingDev (879105)]

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:Sure, The Policy Is Dazzlingly Brilliant *NOW*

[thesandtiger (819476)]

Er, except for one difference...

Google's making money. Actual real profits. You must be thinking of YouTube or something.

During the 90's, the companies that were being touted as being run by genius management were pretty much not doing anything but helping the manufacturers of $800 office chairs get rich.

Re:Sure, The Policy Is Dazzlingly Brilliant *NOW*

[UbuntuDupe (970646)]

Something I want to add about Google's profitability. A lot of people have tried to compare Google to GM, and basically say, "Yeah, you're doing fine, because you're profitable now, wait until you have retirees to take care of like GM did." The difference though, is that, having learned from the 50's, Google isn't making those mistakes. Google will never have massive pension obligations for the very basic reason that Google does not enter into these obligations. When an employee leaves, Google's "debts" with them are already settled in full. If half their current workforce suddenly retired, they'd have to find replacements, but they wouldn't have to scratch their heads about any pension fund.

That's one sign they have a clue what they're doing.

Now we know why all the software is Beta

[thammoud (193905)]

for years.

Re:Now we know why all the software is Beta

[lewp (95638)]

Indeed. I think it's so funny that people focus on the "omigosh beta" aspect of Google's software. It's only beta because they don't want you to bother them about it if you can't get it to work for some reason. Is it enough to make you want to keep a backup of your GMail account because you're afraid they might just decide to discontinue the service some day (even though they won't)? Good! You should be doing that anyway, beta or not, Google or not.

Not true

[by 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

[by 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 (980129)]

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 (629653)]

- 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?"

The PHB response?

[paiute (550198)]

No doubt some consultant will turn the Google model into a salable series of talks and books. Your management will crow about how they are going to adopt the Googleway, where all employees are happy and productive. What could go wrong?

But the PHBs will cherry-pick those aspects of Google's business that suits their preconceived comforts. Remember when we were all supposed to be like the Japanese? Show up for work, sing the company song, use just in time, statistical process control and all the other stuff? Yea, we were just like the Japanese, except for that pesky lifetime employment understanding. We'll just leave that one out - it really isn't important.

Don't criticise

[tygerstripes (832644)]

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 (575982)]

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

Reward vs. Entitlement

[Vexler (127353)]

Back in the peak of the Bubble, I worked as a systems engineer for a software development shop. Of course, being a software startup during that period meant having $1000 Aeron chairs for everyone and pool tournaments ever so often, to say nothing of free Friday catered lunches. Then, when the money started to run dry and a few airliners crashed into a couple of buildings, the perks went away and so did my job.

What is interesting, however, is the way similar "perks" are perceived as rewards at Google. If you feel that perks are rightfully yours and must not be sacrificed even in the face of company financial difficulties (feeling "entitled"), then it's hard to make your brain justify working hard for your keep (or harder during particularly difficult times). Whereas if you are working on something for which you have genuine motivations AND have rewards to aim for, then the management has two aces in their deck: An employee's internal motivation (which can be invaluable), and external positive reinforcements. These two characteristics contribute directly to the health of the company both in its balance sheets and in its corporate culture, and that is A Good Thing.

Looking back, it wasn't the exuberance of the Bubble that destroyed it, because the way Google works can seem to be quite exuberant to some code monkey at Chrysler. It was the way that management could not decide (a) how to set business goals, and (b) how to manage its employees. When management forgets how to manage and employees forget how to work, you have a problem on your hands (see the sad saga that was Daikatana).

My company is better

[pubjames (468013)]

That's nothing. At my company, we never have any meetings at all, nor any plans. And staff can take holidays whenever they want and work on whatever they want!

We're not making any money yet, but it's only a matter of time! (Fingers crossed!)

It's must be all about HR

[andykuan (522434)]

Such a model can't succeed without the right type of people: intelligent workers who take pride in the quality of their work and who are self-motivated. And I don't care what company we're talking about -- you're never going to bat anywhere near 1.000 when it comes to hiring people with all three traits. I contend (with no supporting evidence whatsoever, but Yegge doesn't offer much other than anecdotal evidence either) that Yegge is wearing rose-colored glasses and there's either a good segment of the workforce at Google that still needs to be micro-managed or Google is quietly firing 10% of their staff every quarter to keep trimming out the slackers.

Herding cats

[plopez (54068)]

Often I have, and no doubt you have also, heard the phrase "managing programmers/software engineers is like herding cats".

My observation has been, if you are trying to herd cats you are using the wrong management technique.

You herd cattle, not cats.

With cats you put them in the general area of mice and let them do what they are good at. Cattle you herd to the slaughter house.

Most software projects fail due to poor management, then managers don't understand it is not an industrial activity. Most are still managing from that perspective. Software is more like R&D and in reading the description of Google it sounds like they have built a good R&D environment.

I havent't tried XP, but if it gets us away from the rigid factory model of development, more power to it.

Re:No Wonder...

[EastCoastSurfer (310758)]

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.

Re:you can't rush good cooking

[MikeBabcock (65886)]

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.