Skip to main content


Showing posts from 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.

Building agile teams in a large organization

I went through a successful agile transformation a couple of years ago, and I think I have some idea why it worked so well. 

We focused on hiring people who were already agile, or who had a strong desire to become so.  We then seeded several teams with developer-coach consultants.

To do something similar with an existing organization, you'd have to either fire & then hire a lot of people, or build teams more slowly.  

I think this would work well:
For any given team, put 8 hard-core agilistas and 2 people who have an interest in it from the existing staff. Every month (give or take a week), add 1 person from existing staff.When the team gets to 16, fission into two teams and repeat.Keep working your way down to the people who had the least interest in going agile.That means it would take 7 months to build the first two teams (or if you're willing to bring in 16 contractors at once, the first four teams).  It's a big investment, but if my experience is any guide, it'…

Google needs to step things up for Apps users

This is getting really annoying.

As one of the people who actually pays Google for services, it would be nice to be able to access their latest and greatest technologies.

Snowulf has a pretty good description of the problem on his blog.

If Google Apps gets the vast majority of it's users from very large companies, then I suppose it makes sense for them to enable their more bleeding-edge features last.  I didn't find any statistics on the subject, though this page implies that there are 30 people per GA account, on average.

I'm the only person on my domain, but I have 20 or so email addresses set up.  If they're counting me and others like me in that statistic, most "businesses" their referring to are probably individuals.

Choosing the best language: Twitter moves away from Rails

This is an interesting article about Twitter's shrinking use of Ruby and Rails.  (My friend and coworker Abdul Habra sent it my way.)

The upshot is that Ruby and Rails are better tools for rapid development with a small team, but that they don't compare to the JVM for encapsulating things so that multiple teams can change things at the same time.  There is also a performance gain, but that's a secondary concern. 

Twitter seems to have taken a very smart route here - build their product quickly with "Agile" tools, then change as needed to support a larger user base.

I'm particularly geeked (pun intended) about their choice of JVM language.  They went more cutting-edge with Scala as their language of choice for most applications.

Android Market - install directly to your device

It took me a while to discover this, but much to my surprise, I can shop the Android market on my laptop, and the app will install to my phone!Google is just cool.

On a related note, the Android Blogger app is pretty nice, too. (That's where this post came from.)

Remembering the little things: a backlog for inactive projects

This came up at work the other day: how do you capture those "little" features that you want to take care of next time you modify an existing (but currently un-funded) codebase?
We're using an open source project by Jasig - the central authentication service. We have a suite of different products that use it, and we want it to act as a single sign-on solution for users who have a subscription to more than one product in the suite.
A problem cropped up last week when I discovered that it was loading some information from a table at start-up, but didn't refresh the data until a restart. It should be a pretty simple task to add a cache that would reload the data every 30 minutes or so, making it simple to add another product to the auth service.
I didn't want to make a change right then because we have enough going on this week on my current project, but I didn't want to forget about it next time we dust off the codebase and add another set of features. The answ…

Pair Programming: The Binkiewicz Pairing Model

If you don't know what pair programming is, read this:
Bill Binkiewicz is one of the many top-notch developers at my office. He's also a pretty humble guy, and as far as I know, doesn't blog. He didn't even put his name on this, but that's OK - I'll add it for him.
I'm finding this to be a very useful model on my current team. The document centers around how to choose who should pair on a given problem, based on their interest and experience with the technologies and business domain.
Shared on my google docs site:

The Learning Organization: Improving on the code randori

For most of the past year, I have been pushing to make my workplace more of a learning organisation.  I'm doing this for purely selfish reasons - I simply enjoy working in a place filled with smart, motivated people.    A focus on learning and continuous improvement tends to attract people who enjoy that, and chase out people who don't.  (Senior management expresses it differently, but I think my reasons are more honest.)

A big part of this effort has been to run a regular "craft day".  "Craft days" are  in-house software conferences with a heavy emphasis on hands-on practice of programming skills.  (This has been disappointing for people who wanted to make beaded purses and wallets, or whittle figurines from a block of wood.  You just can't please everyone.)

It really is awesome that I can do this during working hours, unlike what Chad Fowler describes and which most of us have had to do - learn almost all of our new skills outside of work hours.


Why are we having a "Post-Agile" debate?

I just read a post by Kurt Häusler to the Software Craftsmanship Google group this evening.

The background for this is a long-term debate about what exactly "Software Craftsmanship" means, and what it's major focus should be.  I think that Kurt did a great job spelling out two of the major points of view:

It seems a lot of people suffering from "agile-fatige" and looking for something post-agile are in two camps. One camp seems to be competent leaders working with poor developers. For them things like Scrum have bought some improvements in the organization and they despair that after all this "agility" the code is still crap. These people crave something like craftsmanship to light a fire amongst their developers. The other camp seems to be competent developers suffering under poor leadership. They see the XP practices and clean code as obvious to the point of being trivial, and wonder why people like Bob Martin are calling for more focus on code, when…