Velocity and standard work

LEAN has a concept called standard work times which is an expectation of how long some task should take.  For example, it should take you 1 minute to mill part X from a block of steel.  Having expectations of how long something should take is important in manufacturing, because it helps you assess whether an individual or team is meeting those goals.  The measure for standard work shouldn’t come from some desire for a certain output, it should be based on how long those things really take.

In software, lots of measures of standard work have been generated over time, but we don’t seem to use them much.  I recall, from my earliest days of programming, that a programmer was expected to create about 5000 lines of code per year.  I’ve also heard estimates for debugged lines of code per day (10-25 or so, if I recall correctly).  Capers Jones’ expressed measures of productivity in FP delivered per day.  We seem to have some understanding of what a typical productivity expectation is.

And then we ignore it.  For some crazy reason we decide that the “laws of physics” don’t apply to us and we need a measurement that is unique just to us.  In Agile, they call it velocity.  It’s a measure of the team’s productivity based on story points per day.  What’s a story point?  Well, that’s a relative sizing mechanism the team determined.

The problems with velocity are numerous:

  1. It’s only good for the exact team you’re currently on.  Sadly, team members come and go.  As anyone can tell you, people are not protect-able resources.  Even if you don’t want them to quit, they will.  And when they do quit, your measure of productivity walks out the door with them.  The new person will need ramp up time.  The new person may be more or less productive.  The new person might not gel with the team.  And until then, your expectations of productivity are gone.
  2. It’s only good within the team.  You can’t compare cross team productivity if everyone’s got their own way to measure it.  I’m positive that I’ve argued before that comparing yourself to other companies isn’t necessarily a worthwhile activity, but being able to compare yourself to yourself is.  How do you know you’re getting better (or worse) if the ruler keeps changing size?
  3. It can accept lower productivity.  Sure, even if you accept #2 above, that you don’t want to compare yourself to your competition, you have no gauge as to whether better is even achievable.  Software is a relatively slow process, so you don’t get lots of data points out of it.  If you have to wait for your team to build up a measure of productivity, you could be accepting a lot lower productivity than is likely achievable.  Being able to compare yourself to a typical expectation of productivity provides a measurement it will take far longer for you to build up on your own.

I understand that there are people out there who believe software is more of an art than a science; that software will be practiced by small teams doing great things.  I happen not to agree with that.  It may be true some of the time, but certainly not all or even most of the time.  In most cases, software is more likely to be like building houses – unique but largely assembled from similar pieces.  And with that in mind, software is more predictable than we like to admit.  But predictability means you can have expectations of standard work times, and that you needn’t allow each team to define productivity in their own vision.

Leave a Reply

Your email address will not be published. Required fields are marked *