Measuring Productivity = Continuous Improvement?

December 18, 2008


How do you measure the productivity of a team? Some answers that leap immediately to mind are:

  1. Story Points
  2. Throughput
  3. Function Points
  4. Features

And I’m sure there are dozens more. But as I consider this, perhaps I should re-examine just what the word “Productivity” actually means. According to Merriam-Webster the definition is:

1: having the quality or power of producing especially in abundance 

2: effective in bringing about 

3 a: yielding results, benefits, or profits b: yielding or devoted to the satisfaction of wants or the creation of utilities

4: continuing to be used in the formation of new words or constructions 

5: raising mucus or sputum (as from the bronchi) <a productive cough>

OK, we’ve all probably worked on a few projects that fit definition #5 of productivity. Cough. Ahem. There are a few words in those definitions that catch my eye: abundance, effective, yielding results, benefits, or profits. I’m still no closer to measuring productivity. Hmmm…

Donald Gray has a great blog on applying measures to a teams work. He points out the usual criticism of most measures – namely that you get what you measure (for better or worse – usually worse). However, that really doesn’t help us at all. We’re still stuck without a decent measure for productivity.

You know, the more I think about it, the more I wonder, “Who’s asking for a productivity metric?”

I can think of two basic cases:

  1. Some sort of external stakeholder (a manager, a director, a product owner, a CEO, a customer, etc…)
  2.  The team

If the answer is #1, some external stakeholder, then the odds are good that for some reason they don’t see the team as productive already. If they thought the team was productive to some sort of acceptable standard, they wouldn’t bother asking in the first place. It could be caused by a variety of things (poor visibility into the team, not understanding how the team measures its progress, or plain good old fashioned cluelessness). Or maybe they are trying to help the team. Pardon me for a moment, a monkey just flew out of my butt…

If the answer is #2, then that’s a team I want to work with! The way I see it, this is the way it should be. It’s the team’s job to be constantly examining their own productivity. They should be fascinated by it. Positively mesmerized. How can we improve our work? Measuring productivity in what ever form it might take is the heart and soul of continuous Improvement. It’s the team’s job, not the customers. That feels right. See? No monkeys!

Personally, I like Ron Jeffries example. Productivity is the team’s challenge and the customer’s right. Let the team find the measure and then they should hold themselve to it. Make it visible. I’m a lot happier with the notion that the team controls the measures of productivity rather than some external stakeholder. Is that wrong? Still no monkeys…*

*I apologize for the monkey references. Pinochio had his nose, I have butt monkeys. 

Inspired by Executable Design

December 16, 2008


A post on “Executable Design” from Chris Sterling inspired me today. I’ve started running TDD workshops with the teams that I work with. It’s one of the most challenging things I’ve done in a while. Part of the challenge lies in exercising my technical skills – nothing exposes you to a group like coaching directly on coding techniques. Developers can smell your fear…

However I find that technical issues aside, acceptance of TDD lies in doing a lot of listening. And I mean a LOT of listening. As Chris states so eloquently, TDD is not a silver bullet that should always be used regardless of the circumstances. When someone is objecting to using TDD, there is often a darn good reason for it. Sometimes they just fear change, but as often as not, I find that people have realistic concerns about the appropriateness of using TDD in the particular environment they work in. Ignore them at your own peril.

Most of the time people understand the merits of TDD quite quickly – let’s face it, it’s really quite simple: Test. Code. Refactor. Repeat.

The merits of the process are not what people usually have problem with. Usually they are envisioning what happens when they try to apply it to the environment they are currently working in. That’s where the rubber meets the road. You have to be willing to listen to them, take their reservations seriously, and venture into the dragon’s lair (the environment they work in) to understand what they are dealing with. It’s very hand’s on. Very messy. Fraught with challenges.

Very quickly you can discover that TDD is not an all or nothing proposition. If people feel like you hear and understand their reservations and concerns, then they will probably be willing to follow you down a path toward some sort of adoption – if there is measurable  benefit. They may be willing to explore a variety of useful but perhaps imperfect solutions. On the other hand, if you are just regurgitating the benefits of TDD and dismissing fears…well, I’ve tried it and not had much success.

Working with Agile Teams has to be better

December 9, 2008

Like many folks I work in an environment where multiple methodologies are used. Some are insiders: the various and sundry Agile methodologies like Scrum, XP, Lean, etc. Others are outsiders: Waterfall, RUP, and so on. One thing I realized the other day was that it’s not enough just to make the “insiders” happy. The team can be as happy and cozy as peas in a pod with their Agile methodology, but if everyone else is miserable, then “Houston, we have a problem.”

With that in mind then, an Agile team has to provide the following experience for everyone in the organization:

1) They need to be more responsive
2) They need to be more organized
3) They need to be more helpful
4) They need to be faster, smarter, better, etc.
5) They need to be more fun to work with

If they aren’t demonstrably better in a whole host of different ways both measurable and intangible, then an Agile team isn’t really worth much. They can be productive as hell, but that’s not enough. If operations hates working with the Agile team because all they do is pump out code faster, then we may have made the teams life better at the expense of others in the company.

We need to keep the big picture in mind. Adopting Agile has to provide benefit to more than just the team and the product owner. It has to benefit sales, marketing, operations, security – the people who aren’t necessarily on the team.

Continuous Improvement – Samurai Style

December 4, 2008


Ever since I saw the movie “Ghost Dog” I’ve had a bit of a fascination with the “Way of the Samurai”. You name it – I like everything from books on Bushido to Kurosawa movies. One of my favorite reads is the Hagakure, a collection of philosophy and principles as they applied to the Samurai. I love the purity of purpose and dedication that is embodied in “The Way”. The following quote caught my attention today:

“In one’s life, there are levels in the pursuit of study. In the lowest level, a person studies but nothing comes of it, and he feels that both he and others are unskillful. At this point he is worthless. In the middle level he is still useless but is is aware of his own insufficiencies and can also see the insufficiencies of others. In a higher level he has pride concerning his own ability, rejoices in praise from others, and laments the lack of ability in his fellows. This man has worth. In the highest level a man has the look of knowing nothing.

These are the levels in general. But there is one transcending level, and this is the most excellent of all. This person is aware of the endlessness of entering deeply into a certain Way and never thinks of himself as having finished. He truly knows his own insufficiencies and never in his whole life thinks that he has succeeded. He has no thoughts of pride but with self-abasement knows the Way to the end. It is said that Master Yagyu once remarked, “I do not know the way to defeat others, but the way to defeat myself.”

Throughout your life advance daily, becoming more skillful than yesterday, more skillful than today. This is never ending.”

Hagakure, Yamamoto Tsunetomo translated by William Scott Wilson

The notion of “levels” that he talks about in this passage reminds me of the notion of Shu Ha Ri. I like the notion of levels in the Hagakure better. After all, in a project oriented world we can’t help but find our selves repeating the same thing over and over, never truly finishing our work. This notion of levels helps me to put it all in some sort of perspective.

It even occurs to me that you could map this notion of levels to the Dreyfus Model of skill acquisition:

Hagakuri Dreyfus
Unskillful/Useless Beginner
Unskillful/Aware Advanced Beginner
Worthy/Proud Competent
Knowing Nothing Proficient
Never Succeeded Expert

Of course the final paragraph brings in the notion of continous improvement. The Japanese must be the all time champions of continuous improvement. It seems it is built right into their culture. I don’t have anything really profound to add to all of this – I just wanted to hilight some of the diverse influences behind our modern notions of continuous improvement and Agility in general. It seems we are only rediscovering what some have known for a very long time.