Last weekend I attended ProductCamp Austin. ProductCamp is "a collaborative, user organized unconference, focused on Product Marketing and Management topics". Here are the top nuggets of wisdom that I heard there:

• Oftentimes we focus too much on a feature. Instead, focus on the problem you're trying to solve. This will encourage you to think of other (potentially better) solutions.

ProductCamp Austin is tomorrow. See http://www.barcamp.org/ProductCampAustinWinter09 for more info on the event.

There are currently 28 sessions scheduled ranging from Agile, to Social Networking, to Entrepreneurship and Leadership, to Innovation and Intellectual Property.

Agile practices do a great job of surfacing issues. It reminds me a bit of user interfaces. A former colleague used to say that the UI always got blamed first. Often the issue was in lower layers, but the UI was the part that surfaced the issue.

I've been attending a web based class on Lean development presented by Alan Shalloway. This entry captures some of the more interesting parts. See this previous entry on notes from the first class.

On January 6th, AgileAustin had a session where it opened the floor to questions to a panel of agile experts (Paul Brownell, Michael Maham, Jeffery Palermo, Vishal Sheth, Bill Skrapits, Mike Wethington, Jack Yang and David Anderson). There were lots of good questions and some great answers. Here are some of the tidbits I found most interesting:

• You don't do lean or agile. Lean is agile. There are strong parallels. Note: see previous blog entries on lean.

There are three main methods of agile in use these days: Scrum, Extreme Programming and Lean. Amongst the three Scrum is being used the most by far. Though I base my practices primarily on Scrum, I always say that I do Agile, not that I do Scrum. The reason for this is that each of the three have value to add to the mix. They complement each other very well. I'd rather be free to mix and match than to be constrained to just Scrum.

Scrum originally proposed iterations (called sprints) of 30 days. Extreme Programming says 1 to 3 weeks. Lean questions whether to even have an iteration (i.e., why not a continuous flow of stories). Where should you start?

I generally recommend that projects start with two week iterations. Once you get a feel for things, you can adjust to what is appropriate for your environment.

In daily stand ups (daily scrum meetings), there is an often used analogy about chickens and pigs. When it comes to breakfast, chickens (who provide the eggs) are interested, but pigs (who provide themselves) are committed. The analogy goes that the same is true for team members and those outside the team. Therefore, when it comes to the daily stand up, pigs should speak and chickens shouldn't because the pigs are the ones who have the most riding on the success of the team (chickens have other teams).

I'm currently attending an online class on Lean development by Alan Shalloway of Net Objectives. In a previous blog entry, I reviewed an excellent book on Lean by Mary and Tom Poppendieck. After reading the book, I attended Alan's session on Lean at Agile 2008. I view this class as an opportunity to see how others are using Lean to get the most out of Agile.

The term "Agile" came into existence in February 2001 when the "lightweight method leaders" at the time met to agree on common principles. Each of their approaches had key aspects in common. This was an opportunity to elevate the discussion.