No, I'm not talking about such materialistic traits like salary. No. I'm talking about the monthly hits on this blog! January 2006 reached well over 115,000 hits (including aggregator polling, but still). The numbers for this month will be much less, apparently due to Simon upgrading our Pebble to a newer version with the accompanying changes in the way stats are collected.

More press for agile methods in Finland.

The result of a recent phone interview I gave to a Finnish business paper, Taloussanomat, apparently went online last week. If you've got the knack for Finnish, it's freely available on their web page with a snappy title, "kuinka ketterä olet?"

I'll just go ahead and translate a couple of "gems" for the international audience...
Please note that I did not say these things. Really, I didn't! :)

"We use the Scrum method from rugby where the team gathers together shoulder to shoulder."

"Agile software development means focusing more on people and interactions rather than on processes and tools. This creates better tools and processes."

At this point, I had to pinch my arm to convince myself that I'm not just making it up. And, finally, one more pearl for the swines:

"Agility is a synonym for Agile, and also an endurance sport for dogs."

All in all, I welcome the attention agile methods are getting but I can't help making a bit of fun of the kind of misunderstandings that seem to be inevident when interacting with members of the press over a phone line. Ironic, isn't it, considering the topic of my recent talk...

I recently did a relatively improptu retrospective for a client team I was visiting and something interesting turned up, as usual. The team had been running iteration retrospectives for several months and they had consistently identified the same issues in need of improvement.

I realize that this might not be surprising as such--after all, many of us have been trained to consider this normal by corporations doing their annual employee satisfaction polls where the employees complain about insufficient salaries and management decides to compensate by having fresh fruits delivered to the headquarters (where most people don't work) every Tuesday noon. Next year, the same complaints about salary come up and the same fruits are delivered, this time twice a week but in smaller quantities, etc. The real problem, however, remains (and it's probably something else than the salary) and most likely gets worse over time without getting the attention it so desperately deserves.

The problem with this specific team's retrospectives seemed to be that it had became too much part of the process rather than a way for the team to reflect upon their ways of working and, including but not limited to, process. Just like with the imaginary Big Bad Corporation doing what seems like polls for polls' sake.

Digging further into the apparent frustration, we established that while the retrospectives were run using a textbook group brainstorming format and while the sessions had always resulted in lists of things that went well, things that need improvement, things that puzzle us, and so forth, the resulting action plans were simply too vague to have much chance of actually getting executed. For instance, it's easy for a team to fully agree that "we need to improve our communication", it's not as likely to lead into actual steps being taken to improve the said communication as a more explicit statement of the required action would.

Project retrospectives are an invaluable tool for teams as well as individuals to learn about themselves and for the organization as a whole to evolve towards an even better awareness of our strenghts and weaknesses. Iteration retrospectives, however, have an additional and highly significant role in agile methods. Iteration retrospectives are a mechanism for an ongoing agile project to develop its process through the feedback loop the retrospectives represent. Iteration retrospectives are not just about what we'll do differently in the next project. They're also about what we'll do differently starting next Monday.

If you're serious about succeeding with agile methods, I'd suggest you invest the time and effort to run proper retrospectives and treat them as what they are.