"Of course we get side-lined by an occasional production support task or an overly optimistic lead developer that bites off more than we can chew.... I feel that it's a huge slap in the face when you are programming like a ferret and don't get to 1 or 2 stories out of 25-30 in a 2 week iteration and the PM or IT Director is "disappointed" that you have carry over.... And thus I bring the question to you--what is the TRUE measure of success?"

 
Here's my cop-out answer: There's is no TRUE measure of success. There are only individual measures that make sense to each person and situation.

Here's my pitch: The real issue may be that the team has one definition for success while management has another. If we're willing to acknowledge that there is no TRUE measure of success, then what can we do to align how both the team and management view success?

Here's my blog:
When planning timeboxes (task cycles, iterations, etc.) I tend to implement one of two types of goals with teams, either: (1) firm goals or (2) stretch goals.

A firm goal is one that we try to hit come hell or high water. We should have planned to overcome a few obstacles along the way, and not be surprised when obstacles do materialize and we need to clear them out of our path. We expect credit for hitting a firm goal. We expect big at-a-boys when hell and high water both come and we hit the goal regardless. Further, we understand that management may be a bit underwhelmed when hell and high water proved to be too much for us and caused us to miss our goal. Although we hope they're not too whinny about it. After all, it happens to the best of us.

A stretch goal is a challenge that we, as a team, make to ourselves.  A team can use stretch goals to keep from falling into a rut of good-enough performance (similar to the sub-optimal "memory" batteries can learn when they are only half-used and fully recharged too many times).  We know stretch goals are hard to hit, and everybody should be happy if we get ninety percent of the way there. However, we expect big at-a-boys when we actually hit stretch goals.

We should chose what type of goal we are setting based on two major factors: (1) the team's own internal preference and (2) the temperament of management.

Some people get excited about hitting goals square on the head one after another, while others get excited about seeing how far they push themselves. In practice I have seen teams switch between hard and stretch goals depending on how everyone is doing during a given period in time. Some managers love and encourage strech goals. Others don't get them or don't have the nerve for them.

Here's my answer to Quinn's question:
You've probably guessed what I'm going to say by now. While the team's goal-type preference matters, the team also needs to pay keen attention to the preference of management. If management doesn't understand or doesn't want stretch goals, but the team continues to implement them, then the two measures of success will remain misaligned.

If management wants to measure success using firm goals, then the team should set its goals accordingly, by either dialing back a bit on its commitments or being a degree or two more conservative on its estimates. This will enable the team to set and deliver to firm goals, thereby aligning the two measures of success.

Comments (0)

Write comment

Show/hide comment form