Skip to main content


Showing posts from December, 2011

Agile and Performance Reviews: Pt II

Yesterday, I blogged about lessons learned around performance reviews in an agile environmentMarvin Toll pointed me to this essay on the subject by Mary Poppendieck.

It's a very worthwhile read, and I think that we're ahead of her recommendations in a some areas.  A few things stand out, though:
It takes a lot of courage to change the compensation process.  It also takes a lot of influence - if most of the company thinks that the process is the best/most fair way to allocate the raise budget, you're not likely to change it.It takes a lot of work to improve performance evaluation.  One thing I know firsthand is that if you don't talk about goals and performance at least monthly, people will lose focus.Training is a better place to spend money than merit raises.  I don't have any objective data to support this statement, but I am sure that the best developers enjoy going to conferences and being exposed to different perspectives.I have seen some firsthand evidence t…

Agile and Performance Reviews

I found that one of the most difficult issues to deal with in an agile development shop is performance reviews.   There is a scrum process that Jeff Sutherland talks about in his blog, but it doesn't satisfy most of the requirements for the review process where I work. 

I'm not certain that doing reviews at all is a good idea.  Left to myself, I'd look for some way to reward entire teams, and empower them to most or all of what a traditional manager does.    I don't think my company is ready for such a radical change, so I and my peers have worked out some techniques that (I think) give us a more effective take on the traditional PR.

Hard work warning:  I believe that the only way to do a decent review is to put a lot of effort into it over a long period of time.  Ideally, the annual review should summarize dozens conversations and observations that take place throughout the year.

Here are some of the keys as I see them.  These are all things that I have applied or t…

Mobile First

This isn't a new idea by any stretch, but I'm hearing a lot more buzz about it these days.  The core concept is that if you create your mobile app first, it will focus on the essential features.

A secondary benefit is that mobile will probably surpass desktop use (particularly when it comes to search) in the near future.

Luke Wroblewski's blog entry on the subject is short and clear.  If you want a bit more depth, consider skimming this presentation by Tyler Tate, which focuses on search applications.