Agile Software Development

I'm an idiot, I have fooled myself. I'm usually quite good at fooling others, but this time I have fooled myself. And I did it with what I might call a false velocity.

Velocity Defined
Velocity is the rate at which you complete your work, in a certain period of time. This might refer to the number of stories completed, the number of issues processed, the number of exams passed, the number of kilometers driven, the number of hamburgers baked and served, or (for some guy I know) the number of girls dated and dumped.

The Velocity of Writing a Book
I might have mentioned earlier that I'm trying to write a book. It's a book about managing software development, and the things we can learn from complexity science. Last year I did a lot of research, a tremendous effort that will continue to the end of this year. And I started writing my first pages of text in January this year. I am planning to write around 350 pages in 1.5 years, which equals to an average of 5 pages per week. After 15 weeks I have completed 75 pages of text, which is... 5 pages per week! It's exactly the velocity I need to finish the book as scheduled. Right?

Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.

Agile processes recognize and try to effectively use the fact, that software creation is a difficult and not very predictable process. Therefore quite often teams applying agile processes end up with the not completing all the committed product backlog items by the iteration end. Teams just starting to employ Scrum or XP can sometimes end up with half of the items being not completely done. Naturally in such a situation people are tempted to finish the uncompleted stuff as soon as possible. Some think about extending the iteration length for a week or two, some think about marking the item half-done, adding half of its size to the team velocity and continuing with it during the next iteration.

Measurement is fundamental to any engineering discipline and the planning of a software creation work is no different. Whenever you plan to make or renew a piece of software the most important metric as the workload size. Measure of size is important because knowing the amount of work to do and the team skills (i.e. velocity) you can easily derive the work costs and duration. Agile software development methods do strive against the overplanning and overdetalization