Counting points, or "stats are for losers"

Sports fans are familiar with the phrase "Stats are for losers." If your favorite team got hammered last Sunday you can count on a few people jumping into a discussion with an argument about how the team "should have won because we outgained the other guys 500 yrds to 250 blah blah blah..." The simple rejoiner from the winning side is, "Stats are for losers."

I was thinking about this in the context of an agile project that was comparing its iteration point count with another team's. "Yeah, we got 25 points last iteration, the other guys only got 21." Agile practitioners know that if you're doing estimating correctly, the points are only measures of relative effort, comparable only to the team's effort within a release. They can't be used to compare to, for example, another team's point estimate. The team that was congratulating itself had delivered a design that was flawed (and they knew it) but didn't fix it once the flaw was pointed out, because it would have affected their point count.

Stats are for losers. Winning means delivering high quality product that is of value to the business, not having a high score on some arbitrary measure like points.

Scrum pep talk

I took two days of training for Scrum product owners. At the end of some excellent training the trainer said, "We're going to send you a certificate that says you're a certified Scrum product owner. Take that certificate and put it on the wall. It doesn't entitle you to tell anyone anything. It will be there to remind you that you don't know anything yet, you really don't. But it's your job to learn everything you can and put it into practice."

That's the kind of pep talk people need to hear when they get a "certification."

Remarks on The Art of Agile Development

There are a large number of books about agile development, and many more about XP, but the book The Art of Agile Development by James Shore & Shane Warden is really exceptional. In addition to covering the principles and practices of XP, the authors spend a lot of time on the interpersonal aspects of software development. Team building is important on any project. The book shows how XP practices reinforce important values like trust, respect, and teamwork. This book will be a reference that I return to for its clear understanding of agile and, more importantly, how to lead a team. Highly recommended.

You call this Agile?

I started a small project recently with a company that touts its Agile development process. The assignment was straightforward enough: determine why callers aren't completing what should be a simple registration process using a speech IVR.

A couple of things you probably already know about Agile. If done correctly, it's faster than traditional waterfall methodologies for getting projects completed. It also de-emphasizes the creation of documentation during the project. Of course, after the project is over no one wants to hang around and create documentation from scratch.

So, a week after the start of the project, no one has been able to produce any documentation of the existing system - no grammars, no call flows, nothing. This makes it just a little hard to review. This is one of my least favorite aspects of Agile.