Friday, December 23, 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

Thursday, December 22, 2011

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 that I am currently applying, with varying degrees of success:

Focus the goals - Each developer has a different sub-goal (or two) to focus on for a given time period.  For example, each of the four major goals for my group has 10-20 bullet points that it covers.  Telling people that they need to "focus" on 50+ behaviors means that they will call out what they will make up a narrative that shows they did everything on the list, rather than trying to improve anything in particular.

Ask each team member to choose only one (two at most) behaviors or sub-goals to focus on, and reword them to apply to the individual's project.

Change over time - The goals should shift throughout the year.  Try to change them quarterly  as a guideline.  Allow people to decide that a certain goal isn't as worthwhile and change it sooner, while others find that they take longer and extend a goal into the next quarter.

 Individual ownership - The master list of goals should be built through conversations with the developers.  Even if the major goals are handed down from on high (ours were), you should still be able to make them more specific for a development group, and it is imperative that the people in the group have a say in their wording.

 Review at least monthly - People, especially busy software developers, will forget long-term things like goals.  Having a monthly 1x1 where you review how they're doing really helps keep things on track.

Focus on strengths, not weaknesses - Encourage each person to focus on things that they are either already good at, or that they're passionate about being good at.  Focusing on "problem areas" usually means that you're asking people to spend more time on things they don't like doing.  A recipe for failure.

Embedded management - I'm less sure that this is essential, but I think it is a big help in my case.  Having manager/developers allows us to pair with the people on our teams regularly.  It makes it easier to "call bullshit" on exaggerated self-reviews, but it also makes it much easier for us to see the little things that our teammates are doing every day to add value, so we can call them out on the reviews.

These things seem to work well for my team.  The alternative was more subjective - gathering feedback from stakeholders at the end of the review period.  I'm still  doing that, but I pick it up in casual conversation now instead of waiting for the end of the fiscal year.  This allows me to call out problems while there is still time for people to fix them, rather than forcing them to defend themselves when it's too late.

Friday, December 2, 2011

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.

Friday, July 22, 2011

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's a big payoff, too.

Saturday, July 9, 2011

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.

Friday, July 1, 2011

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.)

Thursday, April 21, 2011

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 answer is pretty simple: we use Jira as a "story bucket" for both new features and to keep track of bugs. I just needed to create a new project for it, and dump the story in.

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.

Sunday, January 9, 2011

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.


The down-side to craft-days is that we can only do them every other month.
While it's great that we can do this sort of thing at all, it's only going to give us a limited return.  We need to do hands-on practice regularly to really take the lessons to heart.  It also servers to stoke the fires of geekiness in our pocket-protector-covered hearts, motivating us to stay on top of the technology curve.

It becomes much easier to engage people and figure out what they really need if you spend more time with them.  Bob Martin has a pretty good (and pretty honest) explanation of why occasional exposure to learning doesn't really help much here.

Accordingly, I volunteered to to a twice-weekly Code Randori sessions.  The first session wasn't very valuable, so with the help of the group (there were 25 or so people in attendance), we're going to try the following tweaks for the next one:
  • A simpler problem (but still a real one that we encounter at work), with no code written for it.  (TDD the whole thing.)
  • The problem visible to all even while code is being written. (Whiteboard)
  • The skills we're focusing on visible to all.  (Whiteboard)
For anyone who is interested, I'll put the retro conclusions in the session notes.

Photo by some guy named zimpenfish on Flickr

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 it is clear, to them, that future improvements lie in better management practices, better understanding of value streams and improved relations between customers, management and developers. These people are currently looking at things like lean and kanban, and finding a lot of valuable stuff there. 

My own perspective is that we don't really need a "post-agile" movement or focus.  Agile (with it's multiple meanings) is still not the norm in most organisations, large or small.  Getting organizations - particularly large organizations - to do more than pay lip service to agile methodologies should still be our main focus.

I wonder if the drive to come up with a "post-agile" methodology or movement is really being pushed so a new crop of developers can have their names associated with it.  Is it more of an exercise in branding than engineering or craftsmanship?
Photo by Lovefusion Photography

Windows 10 Driver Issue with Falcon / Z-77 Keyboard

Windows 10 has an issue with this mechanical keyboard (which works great, BTW).  It's a Chinese-made keyboard (aren't they all?), bu...