At the “Scrum Beyond Software” in Phoenix, Tobias (@tobiasmayer) challenged us to get beyond the words, and I echoed him. Now it is time to put action behind my words!
This morning, my inbox was freshly loaded with an opportunity to help an unknown find a better way of doing things, and it started like this:
Confession: In all my years of software development I’ve never successfully and usefully estimated, tracked, or measured anything.
I get the impression that measurement is one of the keys to improvement. If that is so, where should we begin? What useful statistic should we collect first? What value can we derive from that info? How can we apply the information to help us do better? – Alan Baljeu 
My challenge to myself: answer this without using any loaded words like “cycle time” or “velocity” or “takt time”, and do so in a way that allows the reader to use the results for self-driven, meaningful improvement at a team level. Here we go!
What do I measure?
I’m going to use a basic physics metaphor. For each of the levels, track things as simply as possible at the item level, aggregate for clarity and perspective, manage any single item out of the ordinary as a special case. Keep the results big and visible in the team’s shared space, whether that’s physical or virtual. Please note, there’s nothing really new here, the basic ideas and metaphor have been around longer at least as long as I’ve been doing software.
1 – Position: What’s being worked on, what’s completely done, what’s going to be worked on next (for a very limited scope of "next" ).
2 – Motion: Take the above, add in time dimension: How long did each item take, when did it start, how many other things were being worked at the same time.
3 – Acceleration: Take the above and start looking for changes in the trends over time. If the "how long" is decreasing, and you didn’t do anything intentionally to make it do so, figure out why and (likely) celebrate!
How do I introduce it?
In my experience each of these levels provides its own, distinct benefit if you do them in order. Start with level 1, figure out a way to effectively track it in your team, get people used to seeing it for a few days, and observe the changes it makes in how the team interacts. Tweak how you’re tracking position and ensure the team’s comfortable before you move forward trying to track and use the next layer of information. Typically, this step is a basic physical or virtual task board, although it could be a shared Google spreadsheet or any number of other tooling-based solutions.
Next, start putting dates along with the work. At its easiest, just jot down the day work starts on something, and the day it’s done, then do a “week-day math” subtraction to find out how many days it was actually being worked on. See what this awareness does to the team, how they react, if the information’s in the right spot. Finally, start tracking those numbers over time. How many things are typically being worked on at once? Does this number seem to be going up, down, everywhere, etc? How about the time things tend to take? Is it getting smaller? How about rework on things that “could” have been right? Is it in balance with the time it would have taken to discover the right way in the first place? Is Quality high? Start mapping the perceptions against the numbers and see if they match up, figure out what patterns are in there.
Throughout these steps you’ll start seeing things you want to change about how you approach your work. Do so! Try things, see if they work, and be willing to put things back the way they were if you don’t like the results. Foster an attitude within the team to make these experiments a Good Thing ™. Treat them as experiments… success and failure isn’t the goal, learning a better way is the goal, and it takes both “success” and “failure” to achieve that learning.
Finally, remember to look back at the old numbers once in a while, and celebrate as a team just how much better the new numbers are, and how far you’ve come as a team.
 – I normally would avoid applying attribution to something that sounds potentially negative. In Alan’s case, I greatly respect the courage it takes to publically state something like this, and I also recognize that finding a quote is trivially easy and he deserves the respect that courage deserves.