Screaming Yellow Duc

Yes another motorcycle post.

After riding the other bikes this summer there was just something missing from the KLX 250. Primarily my wife. We were both missing the enjoyment of heading out for an hour or two on the weekends or a warm evening riding tandem. We know this might be an issue we we purchased the KLX, but figured we'd save up some money and deal with it next summer.

Fast forward to the present. I'm hanging around the dealership waiting for the service department to put some new tires on the KLX. The showroom is completely dead and I didn't bring anything to occupy my time, so I'm wandering around admiring the bikes. One of the salesmen strikes up a conversation as they are likely to do. Eventually he gets around to asking me what kind of bike I'd be interested in if I was really looking.

I'm honest with him. I say I'd be interested in something for riding 2 up. I've been here a few times and know they don't really have much in that category, but I've got time to kill and salesmen always have a bunch of good stories. He takes me through their limited inventory - a FJR, and a Concours. Both are nice bikes, but I'm not really into buying new off the showroom floor.

He detects my lack of real interest and asks what I'd really want. I say I'd be really interested in a Ducati ST4, knowing that the local Ducati dealer has this market pretty wrapped up. To my amazement he says hesitantly I think we have one of those.

I'm stunned for a moment. Then I come back to my senses. Most Ducatis are sports bikes, not touring bikes, it is extremely doubtful they really have what I'm looking for. Nevertheless I follow him outside where some of the used bikes are on display.

We walk down the line of bikes and by this time I'm not expecting much, but then I see it. A 2001 Ducati ST2 in yellow! Now ideally I would love to have on in Ducati red, but at this point I don't really care to much. It has only 5,500 miles and the price is reasonable, but not amazing. I hem and haw. He asks me how much I'd be willing to pay. I tell him a ridiculously low number. At this point he reveals that it is a consignment bike and if I want we can write up an offed. What the heck, I've got time to spare and worse case I go home with nothing.

While we're writing up the offer my wife shows up (she was going to take the old, but still serviceable KLX tires home). I give her the tour and the salesguy finds the key so we can listen to it. It sounds fantastic with the Fast By Ferracci carbon fiber pipes on it. She is excited, I'm excited. We talk, we decide how much we'd really be willing to pay. The salesman comes back with a counter offer and is willing give up the consignment fees.

We now own a nice yellow 2001 Ducati ST2.

The next weekend wasn't so nice but a few of us went for a ride anyways. We got wet, but had fun just the same.

Interestingly each one of us owns a different kind a bike, a standard, a cruiser, a dual sport and a sports bike.

Evolution of a Kanban board

In No More Iterations I showed our 1^st attempt at a kanban board. Now that we have a little more experience I'd like to show you where we are now and where we stopped on the way.

Here is where we started. Columns for backlog, blocked, in progress and done. Notice the large number of items "in-progress" even though there are only 7 people on the team (can you say multi-tasking?). In fact this was pointing to the fact that developers were building stuff faster than QA could consume it. One bottleneck identified.
	Here is the same board a few weeks later. Note the new column for blocked work in process (WIP) and that the number of in process stories has been reduced significantly. The number of completed stories increased dramatically. We accomplished this by focusing on getting stories done rather than just doing "work". That meant of course that programmers helped out with QA type tasks. It also meant that programmers had time to do some of the environmental cleanup activities that everyone always wants to do, but never has time to do them. Turns out we had time, we were just covering it up with other work An interesting side effect was that developers were not used to having "idle" time and this was very disconcerting for many weeks. It seemed like they were waiting for the other shoe to drop - i.e. some manager was going to come in and yell at them for not working as hard as possible.
This is a task board the team put together to identify the tasks required to complete the stories in the WIP. The idea here was to let other people know what was remaining to be done so that team members could help each other out or at least not step all over each other.
	Here is the next evolution of the task board. The WIP stories are listed down the first column and the various internal states are the remainder of the columns. The sticky notes are the actual tasks that need to get done (color is meaningless).
Here is a combination story task board from a different team. They chose to run the stories across the top row with spots for Backlog, WIP, Blocked and Done. The WIP stories get moved down to head the row just like the other team did. For this team they did use color and sticky dots to indicate various items, but honestly I've forgotten what them meant.

So where are we now? Interestingly things have been going smoothly for awhile so I had to wander over into the team spaces to be sure I remembered correctly. If you've followed along above you may have noticed that the boards got more complicated as we went. Since then we've been simplifying. Also we've gotten used to working this way and it turns out that if you work on a limited number of things, minimize multitasking and talk to each other there isn't much need to use up a big whiteboard with sticky notes.

That's right - we no longer have a kanban board. Now that isn't to say we've abandoned the concepts, we've just determined that we don't need the big visible board.

Currently tasks are being tracked in Extreme Planner and stories are being tracked in a spreadsheet by the project manager.

I use a parallel spreadsheet without all the gory details to help the stakeholder prioritized work, see what is in process and what various releases might look like.

In a way I schedule the entire department on a single 8.5 x 11 piece of paper that has its roots in our very first kanban board.

Throughput vs. Velocity

Throughput and velocity are ways of measuring how fast a team can do work. Knowing how fast a team is going allows the team and their stakeholders to know when something is going to be done.

What is Velocity

Velocity (http://www.extremeprogramming.org/rules/velocity.html) is a commonly used metric for teams using Extreme Programming or Scrum as their guiding principles for software development. Velocity is a unit-less measure that tells the team how much work they should take on each iteration or sprint.

A simple example of calculating velocity:

At the first sprint planning meeting the team estimates the top 10 stories and believes that they can complete 6 of them in the next 2 weeks based on the following estimates.

At the end of 2 weeks stories A-E are complete and F is started, but not complete. This teams velocity is 16 point per iteration, or about 32 points per month. Note there is no credit for partially done work. The next iteration the team estimates stories until they have stories that add up to 16 points. At the end of the iteration they measure what was actually completed and repeat until the project is done.

Velocities cannot be compared across teams because velocity is derived from estimates created by the team and since no team estimates the same way it is impossible to compare them.

Velocity is also not a productivity metric. Wanting to see the velocity have a constant increase is like asking to increase the speed of light. Velocities do vary over time due to various factors (like the fact that software is complex), but tend to stabilize if the work and personnel are not fluctuating too much.

What is Throughput

Throughput is not commonly used in software development, but is becoming more prevalent with the introduction of lean concepts. Throughput is most common when using a kanban scheduling board (http://blogs.consultantsguild.com/index.php/wayne/2008/02/01/no-more-iterations) to help manage the delivery of stories.

Throughput is the number of things that can be done in a given period of time.

A simple example of calculating throughput:

The team pulls the highest priority item off the backlog and works on it until they are done. They note when they started the story and when they finished it. They do this over and over until the project is over. Every month someone summarized the information about the stories that were completed.

This team completed 4 stories in January so their throughput is 4 stories per month. Each story takes on average 6 days to complete with a standard deviation of about 5 days. So 90% of stories are completed in 6 days +/- 5 days. With additional data the standard deviation should tighten up unless you have large variance in story size on a regular basis. Even though story E was started in January we don't count it because it was not completed in January. It will go into February's stats.

Since throughput relies on actual start and finish times we can derive a predictive measure for forecasting without any estimating.

Note that duration ignores the fact that some days are weekends.

Like velocity throughput is a team specific number and cannot be compared across teams.

Challenges with Velocity

Velocity is based on an abstract unit such as Story Points (http://en.wikipedia.org/wiki/Story_points) that are not always easy to explain to stakeholders (or even the team sometimes). Stakeholders often want to know how many days a story point represents. Since story points are relative to each other there isn't a direct mapping, although many team do grudgingly come up with an equivalence. To get around this some teams estimate in ideal or engineering hours. Unfortunately the same questions get asked. "How do I convert your funny agile units into days?" See also http://www.think-box.co.uk/blog/2006/02/ideal-time-vs-story-points.html

Velocity also requires the team to spend time estimating the stories. I'm not sure I ever met a developer who enjoyed estimating and even with planning poker (http://en.wikipedia.org/wiki/Planning_poker) most team member do what they can to get out of the estimating meeting yielding less than useful results. One team I know of estimated everything as "?" once they got tired.

As in all estimation the results are only as good as the information at hand. When you are estimating something you've never done before the accuracy can be all over the place.

Challenges with Throughput

The big knock against throughput is that it requires you to have relatively similar size stories in your backlog. This is true to a point. If your stories are not of a similar size your standard deviation will be larger leading to a larger range in your completion date predictions.

Which to Use?

In my context (stable teams working on product lines) I prefer the kanban/throughput combination. We don't have the dreaded planning meeting and we are still able to tell our stakeholders how many stories they should plan on having in the next release.

If you are currently using velocity it is very little overhead to start tracking throughput as a way to double check what your velocity metric is telling you.