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...

The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release.  I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion. Lets start with the definition that velocity is the speed of progress in a given direction. The direction part gets missed. People (including my slightly younger self) want to do things like track bugs (" failure demand ") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really.  We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity...