I just read through Google's introduction to Chrome (their new light-weight browser). The intro is done as a cartoon. One thing that's really interesting (the browser sounds pretty cool too) is how many references there are to agile development within it. You can find the complete intro at http://www.google.com/googlebooks/chrome/.

On page 9, they talk about their automated testing and the benefits of doing things incrementally...

When I'm running on the trails down at Town Lake or I'm in the gym working out, it is natural to take a look at those around me and see what they're doing. Are they running as fast? Are they doing as much weight?

• There is wisdom in crowds. The conference was kicked off by James Surowiecki (author of The Wisdom of Crowds). Crowds are very good at coming up with answers (assuming they meet some prerequisites such as having some understanding of the problem). There were many examples where the average answer of the crowd was better than the best guess of any individual. Diversity can really help in working through issues as it introduces new ways of thinking about problems / solutions.

Planigle derives from Planning Agile. While I was at the agile conference 2008 last week, I was asked whether that was an oxymoron. In other words, if you're planning, you're not being agile, right? Wrong.

How many backlogs should you have? As few as possible.

On one project I worked on, we had a backlog per team. This is an easy trap to fall into. It gives the team the ability to focus on their own part of the world with minimum interaction with the outside world. It gives the product owner of that team independent control over what they are doing.

I just finished reading Mary and Tom Poppendieck's second book on Lean Development: Implementing Lean Software Development: From Concept to Cash. It was a great book. Highly recommended. In this blog entry, I'll cover some of the major things that I got out of it.

A key concept behind agile practices is that once an iteration starts, you try not to change its scope. After all, it is only a short time until the next iteration. Why can't the interruption wait? By adhering to this approach, it allows the agile team to focus and not get killed with interrupts.

How does this approach work with third level support (which by definition works on an interrupt basis). You usually can't wait until the next iteration to start working the customer issue. To do so would typically violate your SLA's.

Agile Development and Object-Oriented Programming share many similarities as trends in the software community.

The first aspects of Object-Oriented Programming originated in the 1960's with Simula. Smalltalk carried it forward into the 70's and 80's. It finally crossed the chasm and hit the mainstream in the early 90's. C++ and Java helped greatly in driving its adoption.

On Wednesday, I (along with 80 other people) heard Jeremy Miller give a presentation on Agile Design at Agile Austin. Generally speaking, it is a hard topic since it is difficult to discuss without going into specifics. Jeremy did a great job at it. This blog entry captures what I took away from his talk.

One of the hardest things in agile development is adjusting customer / stakeholder expectations on the way that things are promised.