Say-Do

While talking about agile metrics a while ago I was asked if I’ve ever used the “Say-Do” metric.  I had not actually heard of it.  So let’s dive in.

The Say-Do metric was explained to me as “basically that you “do” what you “say” you will do.”  Sounds like common sense so far.  Looking around the interwebs a bit revealed some more detail.  The Say-Do metric is commonly defined as a percentage of comittments met over number of committments made.  Ah, there’s the rub:

In software, the word commitment is a thinly veiled synonym for scheduled-date.  Hmmmm….I think I’ve seen this movie before (it’s called traditional project management) and I know how it ends (badly).

Two things will happen if you try using Say-Do metrics and management styles.

A) Individuals will set smaller and smaller goals, so they can achieve them more often than not.

B) The value of your product/company will not change.

Why?  Because software is a complex creative endeavor.  Say-Do works for simple and even complicated things.  I would use it for children doing chores or for landscapers building me an outdoor cream-city brick wood fired pizza oven.  It might work here.  It might increase productivity and give me something to measure performance against.  But I wouldn’t use it for complex creative tasks.  I wouldn’t ask a composer to tell me when he’ll have that opera finished and measure him against that.  I wouldn’t ask a nuclear physicist to guarantee zero defects in his first design of a cold fusion reactor.  Those requests are just silly.

The software world has been badly hurt by the “engineering” and “manufacturing” analogies.   Writing software is nothing like engineering a bridge or producing widgets on an assembly line.  Nothing alike.  OK, maybe there are similarities and parellels to be drawn upon, but at least I can say with some degree of confidence that they are not the same.

In software, it is *impossible* to accurately predict the end date when we’re talking more than a few days out.  Hours even.  There’s simply too much complexity.  Everything we’re doing in software we’re doing for the first time – we are creating – and all of our techniques for estimating engineering projects rely on recipes and past knowledge.  Sure there are typical design patterns and best practices that we use in software.  But we’re applying it in a completely different context under different circumstances and wanting different results.  Complexity matters.  There’s 30 years of grossly missed software project dates to prove this.

So when we ask for Say-Do metrics, we’ll get A and B.  “A” is due to a paradox of measuring people, the fact that the measurement is visible and people want to “achieve” it, and possible Hawthorne effect at play.  “B” is due the fact that measuring dates, even when it’s the date provided by the people who are doing the work, is a fallacy of traditional project management altogether.  Your software project will not improve because you are using Say-Do.  You will not go faster.  You will not deliver more features.  You will not increase time to market.  You have really changed nothing about the software or project itself, or reduce its complexity.

We have a professional responsibility to be aware of the complex world in which we create software products.  It’s simply niave for management to ask for dates and for developers to give them.  Perhaps even unprofessional.  Maybe even unethical.

 

 

Advertisements

One response

  1. Nice post, thanks for covering it. As the asker of the question, I mentioned that about 2 years ago this was making around the agile blogs as a metric. I think some of it was aimed at “backing up” your velocity to demonstrate your teams accountability.

    One thing I still struggle with though is that people attach really well to success and failure. I know in my experience that once our team was finally able to complete all the stories for a sprint it was a pretty log time before we didn’t complete them all in a sprint. I think your point that any sprint that releases software that provides business value is a success, but it also strikes me as the “everyone gets a trophy” philosophy. I think goal setting (as a team) is important to keep our focus and drive going.

    My team philosophy is that I want my team to “…be the guys that do their job. You must be the other guy[s].” I don’t think a magical say-do metric is the answer to driving accountability, but we should have tangible things(doesn’t have to be data) to base our continual improvement on. I also think we should recognize not completing all our sprint stories as an improvement opportunity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s