Slashdot Mirror
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.
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
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...
Stop by my site where I write about ERP systems & more
for years.
There is a catch. You have to be a genius with god-like programming skills.
"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.
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.
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?"
ClutterMe.com - easiest site creation on the Net. Just click and type.
Google is the darling of The Street, stock's trading at a bazillion a share, we're a Google nation. Of course their managers are all paradigm-shattering super-geniuses, and all the "normal," plodding-along companies will be buying Google-branded Kool-Aid and foosball tables in the hopes some of the magic drips off.
Check back in five years, there's some kind of upheaval in Middle-Central-Lower Slobovia, the Market tanks, Sergey's enmeshed in a sex scandal with an Israeli weight-lifter, shareholders revolt, The Next Big Thing hits (something with a Google-opposite development philosophy, perhaps involving chains and semi-regular beatings), and all the wonks who are praising Gooogle's brilliant policies today are writing best-selling books with titles like "What Were They Thinking?" and "...Damn Hippies!"
Been there. We called it "The Nineties."
the catch is the 5+ page tps reports that you must do and can't talk about out side of google
I love Google; but really - these perpetual betas are basically just another form of pre-announcing, IMO.
#DeleteChrome
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.
Having developers on a merry-go-round between projects is probably a good reason why their products never make it past the Beta stage (which is terrible).
There aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week.
One meeting a week should be sufficient. Three meetings a week spells inefficiency and poor process.
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.
Okay, so now we're advocating against the use of project management techniques? Let's piss in the wind and hope it lands where we intended?
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.
There is tasty food everywhere in this world. Why does it need to be constantly emphasized that Google has tasty food? Google is a software company, not a restaurant. And secondly, the author makes it seem that in crunch periods, companies other than Google do not allow their employees to have lunch and dinner. I somehow suspect (legally, personally, ethically, etc.) that is not the case. Are the employees of EA starving during their crunch periods? :)
The point here is that Agile Development is a good model if its used properly. Using Google as an example to demonstrate how Agile is good, however, is a mistake. Subscribing to Google's use of Agile is a recipe for disaster.
For he today that sheds his blood with me shall be my brother.
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.
If Slashdot were chemistry it would look like this:Cadaverine
- 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.
Meta will eat itself
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
so apparently you don't have to work for Google to come to the same conclusions as this guy. Agile with the capital 'A' (or XP) is a religious movement, it adheres to a sweat shop mentality because it forces release dates (release cycles,) while pairing programmers and thus forcing everyone who is coding to kill their wrists (does that really leave that much room for thought?) The story cards are a ridiculous substitute for a proper design, and projects that succeed do so because someone takes their responsibility seriously (and in case of Google it helps immensly that everyone takes their responsibility seriously, regardless of what the insentives are.)
Of-course not everyone can afford the same culture as Google, simply because not everyone has access to the same funds.
You can't handle the truth.
It's clear, good people in good mood, that's the best way to give incentives to your peers. second...
that is, killing the pressure in a smart way, and third....
that is, the respect of your peers is a KEY here, as a consequence that keeps things calm....
Are you serious? That's a busy week for me. Usually only during intense design sessions. Or training. We usually have only one formal meeting a week and then chat online or pop into someone's office as need be. Far cry from when I was working at a fortune 500 company and we 4-5 a week, chewing up up to 10+ hours a week. The same was true at a Uni I worked at.
Google's getting too big.
putting the 'B' in LGBTQ+
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).
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!)
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.
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.
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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.
putting the 'B' in LGBTQ+
Can I take your place? I work here at Oracle, and it sucks. I'm not sure what your friends told you, but it ain't good working here. Let's swap positions. Meet me at the Starbucks at the corner, and we can exchange contact information...
The terms "rush" and "do quickly" are different.
... if it takes 3 minutes, it takes 3 minutes, not 30 seconds.
Yous till can't rush a stirfry
Its not rushed if its done in the right amount of time, even if that amount of time is short relative to other foods.
- Michael T. Babcock (Yes, I blog)
Wow. Is it just me, or does anybody else get the impression that this guy is too smart to play well with others? I'm sure he does great things all on his own. For the other 90% of us mere mortals, Agile (yes, with a big "A") puts us in an environment where we can contribute, learn, and grow while producing business value. Even up against deadlines. Agile is a way to deal with the toxic cocktail of business chaos and technology potential. It's not a silver bullet - it's wolfsbane, garlic, holy water, a steak, a torch, some leather armor and a few other things to fend off the monsters of the Death March. You need to take the items (practices) that work for you. And to the author from TFA, the cards are a direction of what you need to do. Not gospel. If your project broke down over what could or could not be put on an index card, your problems were not with Agile. Agile was just exposing that you did indeed have serious problems (and Agile is *GREAT* for doing that!).
Even the much maligned (indirectly) Kent Beck went back and wrote version 2 and relaxed from the strict rosary of the 4 values and the 12 practices to a more organic view of values (still all required, up to 5 with "Respect" added) and practices (try 'em, but use what you need). The spirit of Agile is more about "Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.". Keep in mind, that phrase gets pulled like a gun when somebody tries to build up big seminars. I'm not saying people aren't making money off the Agile name, but it's flat out wrong to think it's a snake-oil sales system. Anyone with an Agile community around them can get in touch and talk face to face with practicioners (we're a friendly buch, honest;). All it will cost is the time, the gas, and perhaps a cup of coffee.
Google may be small 'a' agile, but it seems it can only afford to do so because it has a cash cow and technologists at the helm. The grad school/hippy commune the author describes can't exist in the smog of capitalism unless it can be hidden away somwhere because some moron with a bigger paychack is always saying "at the end of the day, we gotta do somethin'". In the rest of the corporate world Agile tools and practices not only gives the dev team a chance of "doin' somethin'".
*** Sigs are a stupid waste of bandwidth.
Why doesn't the blog author just say, "Google has found the optimal development strategy for their market niche and guess what it is? Flexibility and profit sharing for the employees!" Big suprise. There was absolutely no good reason for him to wail on his straw man impression of agile. I work for a proud agile java development shop, Asynchrony Solutions, in St. Louis. Agile works amazingly well for our market niche where we are held financially accountable to produce deliverables for our customers. The "agileness" just keeps all the developers and the customers on the same page throughout the entire software development cycle.
This blog author conveniently chose to not mention many of the most rewarding concepts in agile development. Our agile process includes daily stand-up meetings. Around 10 am when just about everyone is accounted for, each team member standing in a circle takes a turn summarizing what they accomplished yesterday, and what they plan to accomplish today. This serves two major purposes: people must articulate their goals thus clarifying the big picture for everybody, and each person is held accountable by their peers for how their time is spent. You wouldn't believe how this motivates people to make themselves useful so that they don't have to explain why they have nothing to say to the group at the standup.
Shame on this blog author for not even going into how agile development works hand in hand with test-driven development. Well written unit tests coded at the same time as the software itself in atomic increments is the most amazing paradigm shift in software development for decades. I feel liberated when I can fearlessly refactor code that has been written months ago by different people and integrated everywhere in the project because they have properly maintained a test suite. Contrast this with a project that has no unit tests. You have to tip-toe around every line of code, and as the project grows, it becomes exponentially harder to make even the simplest refactor. Peer programming and the agile discipline enforce test-driven development in the real world.
This article made me sad because a lot of damage was done. The blog author is riding on the implied credibility from his position at google, but he is not a professional agile developer. Although the author was right to be upset about shameless vendors who don't care if what they are selling is a mismatch for their customers, I am in awe of how everyone at my company rallies around the agile flag because we are proud that we've got a development process that works for us and our clients, and the discipline to deliver great software. It may not be as visible or high profile as google, but I work with a staff that is just as driven and talented. I hope we don't miss out on any future business because of misconceptions born from this slanderous blog article.
My only regret... is that I have... bonitis..