Good Agile, Bad Agile

Read this beautiful peice of write up from Steve Yegge. He works for Google (am really jealous) and explains how Google uses and perfects the art of Agile working.

My favoutite peice:

"Back in Ye Olden Dayes, most companies approached software development as follows:

- hire a bunch of engineers, then hire more.
- dream up a project.
- set a date for when they want it launched.
- put some engineers on it.
- whip them until they're either dead or it's launched. or both.
- throw a cheap-ass pathetic little party, maybe. This step is optional.
- then start over."

and

"- 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.- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.
- there aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.
- it's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.
- 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."

All I can say is Sigh!!!!! Read the full article here.