Stevey's Blog Rants: Good Agile, Bad Agile

I thought I'd share an interesting post from someone with a decidedly anti-agile point of view.

Stevey's Blog Rants: Good Agile, Bad Agile: "Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places."

I think you can safely ignore the rantings about "bad agile" and the bad people who promote it. But it's helpful to take a detailed look inside the highly agile process used by Google to ship software. Three concepts I found particularly helpful:

1. Process = discipline. Agile is not an excuse for random execution or lack of standards. They have an extreme focus on unit tests and code standards, which is highly recommended.
   
   
2. Dates are irrelevant. Use a priority work queue instead of scheduling and estimating. As I've written previously:
   

   I think agile team-building practices make scheduling per se much less important. In many startup situations, ask yourself "Do I really need to accurately know when this project will be done?" When the answer is no, we can cancel all the effort that goes into building schedules and focus on making progress evident.
   

3. Focus on launching. All of the incentives described in the article focus on making it easy and highly desirable to launch your product:
   

   [He] claimed that launching projects is the natural state that Google's internal ecosystem tends towards, and it's because they pump so much energy into pointing people in that direction. ...
   
   So launches become an emergent property of the system.
   
   This eliminates the need for a bunch of standard project management ideas and methods: all the ones concerned with dealing with slackers, calling bluffs on estimates, forcing people to come to consensus on shared design issues, and so on. You don't need "war team meetings," and you don't need status reports

   I even believe in doing launches on a continuous basis (see continuous ship).
   

Anyway, thanks Stevey for your thoughtful post. And sorry about those horrible Bad Agile charlatans that have been apparently torturing you with their salesmanship and dumb ideas.

Related articles by Zemanta

• Google's Engineering Philosophy
• 12 Unit Testing Tips for Software Engineers
• Using Continuous Integration to Reduce Project Friction