Uncharted Waters

Oct 10 2016   2:02PM GMT

The Agile Scorecard

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Agile
scorecards
Scrum

I came across a post on scrumalliance.org today describing an agile scorecard. The scorecard is a set of categories and criteria that a manager or lead might use to assess each person on a technical team after a sprint. The author suggests that this is good because it moves assessment from one or twice a year, to every few weeks.

This sounds good at a superficial level, team members that don’t get feedback often may not know that they could change something small to be a more useful person. But, the details of this scorecard are full of anti-patterns. Things that, to me, suggest organizational dysfunction and a complete misunderstanding of agile principles.

Here is a closer look.

I’ll start with the key theses in the scorecard:

The key objective is to improve predictability, a primary goal of many businesses. By predictability, I mean that for a well-defined set of inputs, the same outputs are generated every time. Outputs in small intervals give an opportunity for producers to receive periodic and regular feedback from stakeholders, all leading toward continuous improvement of the outcome.

I agree with the words. Learning to deliver in a somewhat predictable way by taking very small pieces of work is a reasonable thing to want. That will never happen every time, of course, but some managers like to shoot for the impossible as a motivating force. Not my style, but some do it.

The problem I see is with the contents of the scorecard — self-sustainable, meets commitment, bugs, untraceable work, un-capitalized time, and unscheduled work. Most of these criteria aren’t in the realm of control for someone on a technical team.

agile scorecard

I’ve worked at several companies as a regular technical contributor, for several years each. The general pattern was us starting a release with a planning meeting. People would get impatient, so the technical team would leave with an incomplete idea of what they were supposed to build. We would spend some time going back and forth to get clarification. Eventually, testers would get the new code and start a find, fix, retest cycle. Sometimes, emergent work would get shoved into the queue mid sprint. Maybe that extra work causes a feature or two to miss the release deadline.

There was some dysfunction in there, but nothing terrible. I’d say, that represents the average of what people call agile at software companies in the US.

Half of what is happening in that example would cause people to get bad reviews when score card time rolls around. Bugs and meeting commitment are often directly related to downward pressure from product owners and management. When we left meetings with a poor understanding of what needed to happen, and then work gets inserted, only two things can happen. We move forward quickly and build un-maintainable junk, or move slow to learn more and build something good and end up being late. On one end you get bugs, on the other end you get a late release.

Other parts of the scorecard are just silly. Uncapitalized time, I usually call this slack time, is a good thing. It gives me time to rest, time to think, and time to develop skill and come up with new ideas. Penalizing people for having a little spare time on a project is anti-intellectualism.

This particular score card, like most of the text I’ve seen pushing agile toward some sort of Frederick Taylor scientific management style future, strips all of the nuance out of what really happens when software is being developed. At a minimum, it shows little understanding of power structures in development teams — who is directing the work, who chooses what to develop next, who assigns tasks to what person.

My take is something like this. Giving and getting regular feedback is great. Definitely do that. Giving that feedback on things the team member can’t control, and in a way that doesn’t drive improvement is dumb. Definitely don’t do that. I have never seen a scorecard nuances enough to be useful for the reviewer or the person being reviewed.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: