It's About the Product, Not Velocity

Watch out when the team or management are too concerned about velocity.  The problem with metrics, is that people will start trying to game the system to increase the numbers they think that you think are important. Imagine this conversation:

Good day Boss.  Good news, the team has increased their velocity by 125% in the past 4 sprints.

Some bosses would be happy with this, but out of context, this is an inconclusive statement.  That could have been 4 sprints making pixel level adjustments to the UI, or perhaps updating the CSS to use a different shade of green.  What about the product?  What value is being added to the product?

Look at the product and your cost.  Figure out your burn rate for the team per sprint.  Let's say it costs about $10K to run the team for a sprint.  Instead of the quoted scenario above, consider this scenario:

Hi there Boss.  We just spent $10K over the past sprint and this is what changed in the product.  Are you happy with what you just paid for?

Please, make a good product at a good cost.

Quote: Simple Definition of Business

"A business is a collection of rules that manage a bunch of lists."
Camron Shimy

Trash and Interfaces: Working Together

I took out the trash this morning (please hold your applause).  I wheeled out two trash cans, a green one for yard trimmings, and a black one for other household trash.  This was a very easy task to accomplish where at the end of the day, my trash cans will be empty and I will be able to fill them back up again.  Ah...closure.  How does this work?

Here are some things that help make this work:

• The point of interaction between me and the garbage company is the street curb.
• We have a defined transport container.  Rather than throw all this junk on the street, there is are nice, color-coded containers that indicate to me what to put into each container, but also lets the trash company truck drivers know which containers to pick up and which to leave for other trucks.
  
• We have a defined time frame
• The trash is collected between 6am and 6pm.
• I can control the quality (more of a boolean, but sometimes not)  If I want to maximize my chances of the trash being picked up properly, I need to put it out before 6am.  I also need to make sure it all fits in the containers provided by the trash company.  I can always skip a week if I please.
  
• We have a defined frequency, once a week.
  
• We have very clear responsibilities
• I put the cans out
• They empty them
• ...and some other minor things that I don't feel like typing.

Wow, that is a lot of coordination.  Here are some points that make this easy

• My neighbors have the same service and do the same thing, so it is easy to share information about scheduling, overflow, and who to call if there is a problem.
• This is a standard and repeatable process
• When the schedule changes (a holiday here and there), I am notified of the new schedule
• This process is similar to other trash companies in the area, so some kind of "regional industry standard" exists. 
• I don't care who picks up the trash, as long as someone does.
• They don't care who wheels it out, as long as someone does.

Why don't you develop your software the same way? 

• Agree to the same (and clear) goal
• Work as a team
  
• Accept changes
• Define responsibilites
• Make it easy to use
• Provide value
• Keep it simple
• Interact frequently
• Care about what needs to be cared about

Please tell all your friends about this mind blowing article.