Would a six-sigma business architect support Agile methods?

A few weeks ago, I spent a few days with "six sigma" folks.  I was reminded of that experience when my manager asked me for "measurable results" and I thought back to what my six-sigma friends would say is a 'Measurable result.' 

 

In one team at Microsoft, I had a long chat with a software process person who was very interested in measuring the productivity of the development team in "average lines of code per hour."  At the time, I felt, in my bones, that this was a poor measurement of "productivity" but I had a hard time putting my finger onto why.  So all this came together when my manager asked for measurements.

 

If we, as developers, are going to deliver value, that value will pay off when we deliver a feature that an end-user will use.  Owning the software isn't enough. It must be used.  More so, they have to not only use the feature, but feel that the feature is valuable.  Therefore, of all the lines of code that I write, if that line of code is not in direct support of a "valuable feature," then the time I spent writing it should NOT count towards my productivity. 

 

So take an application spec, deliver only the features that a user will find valuable, and I will deliver a small increment of value to that user.  Call that V.  Multiply V times the number of users who find it and you get a measure of "accumulated value" for that feature (FV).  Now, subtract the cost to develop the feature.  (Net FV).  Pray it is not a negative number. On a feature-by-feature basis, that is how to know if I am productive.

 

Of course, we'd all like to think we are delivering valuable features.  So why did I find myself in an argument today with a business analyst who was insisting that a segment of the market for one little tool would NEED "expensive feature X," when that same analyst couldn't answer the question "what business process will that user be performing when they use feature X, and how will that feature add value to that process?"  He didn't even try.  Yet, he still insists that the feature MUST be delivered.  His project is waterfall.

 

And that is why Agile works, and why Waterfall doesn't.  Because he is typical.  Because developers and analysts think they know what users want, but they are nearly always wrong.  Because we need to have users IN the team, and working WITH the team, and not the victims OF the team.  Because users discover their needs on every iteration... so giving them as many as you can, in a short period, is the best way to "grow" your application from an idea to a useful solution.

 

Because, in the end, instead of measuring developers' productivity by lines of code, we should be measuring teams by their Net Feature-Value (NetFV). 

 

That would be a 'measurable result.'

Comments

• Anonymous
  February 20, 2006
  Like one of my management teachers taught us, "what gets measured gets done." So if you are measuring lines of code, thats what you get lines of code, nothing more.