Heather McLean

Jurgen Appelo has a new post up about the trials of performance appraisals. I think we can all agree that performance appraisals are a time of the year (or multiple times of the year) that is full of feelings both good and ill for managers and employees alike.

I found this near to my heart since this is the first year I’m doing performance appraisals for other people. I’m having the same experience as Mr. Appelo: “I had too little information to produce reliable performance appraisals.” The three people I had to appraise were on a team that I had only joined in July, so first off I was only able to appraise them for half the year. Second, even as team lead I was not in a position where I knew everything that everyone was doing or had done. This was especially difficult for evaluating individual goals, since I frequently didn’t have a complete picture of what they had to done to achieve those goals.

Still, I got through it as best I could. I still couldn’t help the trepidation of feeling like I might be judging some people too harshly and others not harshly enough. It doesn’t help that our performance appraisal system is based on a bunch of arbitrary 1 to 5 ratings. I was pretty stingy with higher numbers, but I know some others (especially the appraisees themselves) rate much more loosely.

The idea of 360 degree feedback sounds good on paper, though. I would love to be able to consult with multiple people on an appraisal so that I could get a more complete picture. Unfortunately that’s the sort of change that will be difficult to sell from the bottom up, and as Mr. Appelo points out, it won’t be received well if it’s not consistent across the organization.

While following the links from Mr. Appelo’s post, I stumbled across another article that I found interesting: What Great Managers Do Differently. It’s actually a short review of Marcus Buckingham and Curt Coffman’s book, First, Break All The Rules: What the World’s Greatest Managers Do Differently (which I will now need to add to the ever-growing pile of books I want to read). In particular, this passage caught my attention:

The traditional performance improvement process identifies specific, average or below performance areas. Suggestions for improvement, either verbal or in a formal appraisal process, focus on developing these weaknesses.

What great managers do instead, is assess each individual’s talents and skills. They then provide training, coaching, and development opportunities that will help the person increase these skills. They compensate for or manage around weaknesses.

This struck me as something both equally intuitive and obvious, yet something I had not considered before (“Why didn’t I think of that?!” moment). In every performance appraisal I’ve ever been a part of, it tends to generate a lot of negative feelings since the appraisee feels picked on—the appraiser points out their biggest flaws and then tells them that they must change.

The idea that the manager should instead pick up on the employee’s strengths and foster those whilst all but ignoring deficiencies is brilliant. The employee doesn’t feel worthless and can focus on those things they do well, and the manager can improve performance by directing subordinates to roles where they will excel.

A coworker recently turned me on to the Google Tech Talks Channel on YouTube. There is a wealth of good information on many different topics. In particular, I found this presentation about leadership from Mary Poppendieck especially insightful this morning:

Not agile related… just a note to myself. Something I might be interested in attending if I have the time.

Future of Web Apps – Miami 2009

I’m a little behind the times in responding to this (the “blogosphere” moves so fast), but I wanted to address an article that James Shore wrote back in November about the decline and fall of agile.

He talks about how agile is failing us, but I think the real underlying problem is that teams are failing to understand agile. Perhaps that is a failing of agile, but I think it speaks more to how teams and companies choose to implement it. In particular, Mr. Shore makes a good point:

[Scrum] also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.

I see this every day in my own organization. Project management gets so hung up on sprints and burndown charts that the team focuses too much on trying to deliver rapidly, avoiding quality practices like pair programming, TDD, and others.

It is not a lost cause, though. For Scrum to succeed, you need to think about your projects from the bottom up rather than the top down. Top-down thinking is a result of project management trying to hold onto waterfall practices while paying lip service to agile practices. The sad part of this is that typically in these kinds of environments, the team consistently points out these problems in their sprint retrospectives, and yet has no or little power to do anything about it.

Project management has to buy into Scrum and embrace the hands-off part of the practice. Determine the product backlog and the release cycle, but leave everything else up to the team. In return, the team should focus on delivering quality over quantity, i.e. following best practices rather than “get ‘er done.” If quantity is becoming an issue (missed commitments, etc.), then the team needs to stop committing to too much and focus on ramping up, or the product owner needs to stop forcing the team to commit to the pace the product owner wants rather than what the team can deliver.

As a closer, I wanted to share a response to the article that one of my colleagues sent me:

An interesting article. Here is an odd thought that won’t seem related, but I think it is.

Over the course of the past week, whenever I had a little “down time” (i.e., while people were sleeping), I re-read Malcolm Gladwell’s book Blink: The Act of Thinking Without Thinking. In one of the chapters, Gladwell talks about Agile, he just doesn’t call it that. He speaks of the commonality between highly successful combat commanders, on-floor commodities traders, ER personnel, firefighters, Improv comedians, and basketball players. Every one of these domains has this thing in common: they are agile. Here are the two primary keys that Gladwell asserts contributes to their success. First, in each domain, there is agreement with the circumstances. As in systems/software development, when we are using Agile, we take things as they are – we don’t try to tell the customer what they want, we try to find out what they want. Second, in each domain, once the action starts, the players do not maintain rigid adherence to a scripted outcome (how “waterfall” is that?); instead, they respond in each moment, according to a very disciplined set of fundamentals. Players in each domain spend their “off-court” time practicing those fundamentals, honing their skills, sharpening their tools, so that when the moment to perform arrives, they are prepared to perform at their very best.

We could learn a lot from people in these different domains As Gladwell asserts, they are our soul-mates. Agile will never decline or fall. It is an adaptive way of life for any domain where rigidity leads to inevitable failure.

And my response:

An excellent observation… it is similar to one of my favorite metaphors for agile (from Ken Schwaber): driving a car. It’s something we do every day without realizing it, but it embodies agile: adapting to change. As you drive, you continually assess the state of the road around you, making adjustments as necessary… most of the time minor, but if you hit a major “block,” you might change your route completely.

When you realize how much “agile” there is in the world around us and in your everyday life, you really start to see the counter-intuitiveness of waterfall.

Everyone needs to see this.