Agile Otter Blog

Note: this was originally all plain text and a little shorter.  As more people have joined the conversation, and other supportive materials have come to mind, it is growing links and a little verbiage but this is only to support the idea: we don't have to settle for expediently cranking out horrible work between pointless meetings. We can do better.  Are we getting tired of the kind of "agile" where you don't really have any particular technical practices, change (and improvement) is entirely optional, and you pretty much do waterfall with additional overhead of meetings? Are we tired of seeing "sprints" and "iterations" used as ways to pressure people into working harder and longer (" pushing velocity "), with no training or learning or even autonomy? Are n-week death marches the ultimate expression of our values? Are we tired of the kind of "agile" that's all about buzzword compliance and rituals and motivationa...

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost) I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post: Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying. Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement. Though velocity is a gauge, it is subject to  Goodhart's Law . It is rather dodgy when used as a basis for governance. Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations,  risk of personal blame, reporting and rec...

This first appeared on the Object Mentor blog in 2007, but I had to get a cached copy from google to reread it. I'm reviving it here so we don't lose it forever. I think it is still carries a valid point, and I would like to revisit it in the near future. Short Reach Posted by tottinger on Monday, April 23, 2007 I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy. Finally I decided that Agile, as I understand it today, is about the short reach. It seems to me that all of the agile practices are about shortening our reach, the distance in time-and-space that one leaves an assumption, decision, or line of code untested and unconfirmed. All the practices seem to follow this one rule. The customer/analyst is kept in the same room, in the same short reach.  We feed back the iterations to the customer/analyst so that his every decision has a shorte...