Tuesday, July 19, 2011

Individuals Over People

I've been pondering a few different ideas lately that all center around a common theme: to be maximally effective you need to identify and allow people to focus on their strengths.

I hear you: thanks Captain Obvious.

If you are reading this it's likely that you're familiar with the phrase "Individuals and interactions over processes and tools" from the Agile Manifesto. I'm sure we agree in principle, but I'm not sure we're talking about the same thing. In fact, it's more common to hear "people over process" when discussing Agile, which I believe is more appropriate for describing the value that Agile brings.

Agile emphasizes people (as a group) over processes and tools. However, there's little room for "individuals" on the Agile teams I've been a part of. I can provide several anecdotes -
  • When pair-programming with someone who prefers a Dvorak layout a compromise must be made.
  • When pair-programming with someone who prefers a different IDE a compromise must be made.
  • Collective code ownership implies anyone can work on anything, which often leads to inefficient story selection. (e.g. the business accidentally gives a card to someone who isn't ideally skilled for the task. Or, a developer decides to work on a card they aren't ideally skilled for despite other better suited and equally important outstanding cards)
  • Collective code ownership requires a lowest common denominator technology selection. (e.g. If 3 out of 5 people know Ruby and 5 out of 5 know Clojure, selecting Ruby for any application, even when it's the appropriate choice, is likely to be met by resistance)
  • Collective code ownership requires a lowest common denominator coding style selection. Let's be honest, it's easy to code in a language such as Ruby without a deep understanding of metaprogramming and evaluation. Both metaprogramming and evaluation are powerful; however, you can only take advantage of that power if you are sure everyone on the team is comfortable with both techniques.
I could ramble on a bit more, but hopefully you get my point.

I'm still a believer in Agile. It's the best way I know how to take an average performing team and put them on a path to becoming a well performing team. However, I think the Agile practices also put a ceiling on how effective a team can be. Perhaps my favorite anecdote: Ola Bini believes he is 10x faster when using Emacs as compared to IntelliJ - when writing Java! 10x is huge, so what does he use when he's pairing: IntelliJ. If there's knowledge transfer occurring then perhaps the 10x reduction in delivery speed is a good decision; however, if he's pairing with someone of a similar skill level who isn't statistically likely to maintain the code in the future it's a terrible choice. Ola is programming at 1/10 of his possible efficiency for no reason other than it's the Agile way.

Clearly, it's gray area - the knowledge transfer level will vary drastically based on who he's pairing with and what they are pairing on. That's the important point - people are more important than processes, but individuals are the most important. If you want to achieve maximum productivity you'll need to constantly reevaluate what the most effective path is based on the individuals that make up your team.

If you already agree with the ideas above then you're probably familiar with the idea that you need to learn all the rules to know when to break them. That's an old idea as well. Unfortunately, I don't see much written on this topic in the software development world. The last 3 years of my life have been lesson after lesson of how smart people can break the Agile rules and get much larger gains as a result. I've decided to tag posts that cover this subject as "Individuals over People". There are even a few historical entires available at http://blog.jayfields.com/search/label/individuals%20over%20people.

Hopefully these ideas will spark a few discussions and inspire other post-Agile developers to post their experiences as well.


  1. Hey Jay,

    On editors and keyboard layout: last year at XP2010, me and colleague Jimmy Larsson did a code kata where we switched between RubyMine with Swedish keyboard layout and Vim with English layout. We set up a quick keyboard shortcut for the switch and it worked just fine.

    On individuals: the biggest problem I see is expert cultures - the ones where you hear things such as "That story is done - it just needs a bit of layout, and the CSS guy is only here on Thursdays". I try to promote T-competencies - you have a field of expertise, but you know a little bit of everything that the team is doing. That way you can cover for the CSS guy when he for some reason doesn't show up on Thursday, but you still need to do a release on Friday.

  2. Hey Marcus,
    Thanks for the comment. I see where you're coming from on expert culture. I was strictly talking about moving from effective to maximally effective. If you're already unable to do a bit of work when someone is out then I'd say you're still working your way towards effective.

  3. I'm curious, what is the advantage of using a common editor between pairs? On the team I work with the driver uses whichever editor they are most comfortable with and that seems to be working just fine.

  4. I tend to agree with kotrin. The one in charge of typing is the one who should choose which IDE to use as they'll be doing the typing. The typing is the lowest level of pair programming. As long as I can see the code being typed I'm free to think about how the code fits with the overall architecture. I'm more inclined to offer suggestions rather than grab the keyboard and start typing. It depends what level both are at on the Dreyfus model. If one is at level 1 and the other at level 5 then pair programming prolly won't work anyway. The point being if they are at similar levels they can communicate using the same terminology and it's just a case of the keyboarder turning the discussions into code. I do agree with your original bit though. If the Drefus levels don't match one of your will have to slow down.

  5. @Kotrin & @Alistair

    I tend to prefer ping pong pairing, which makes this more of an issue. If only one person is driving than you can disregard that anecdote.

  6. Is anyone aware of work on how this works with assistive technology? If I'm helping someone fully sighted on their computer, and I give them the keyboard back for a few minutes, then they have to turn off the Windows Magnifier, even if it is just a bar an inch wide at the top of the screen, because they find it really annoying. I don't work in a place using pair programming, and wonder how it would work out.

  7. hgs, it would likely be the same as switching IDEs. You'd have a keyboard shortcut to make things easier. Tho, I wouldn't want to pair with someone who preferred their text much larger or much smaller than what I like. So, yeah, it would likely be an issue.

  8. well, I use a 22pt font in Vim, light text on black... I'd be interested in others' thoughts on this as well.


Note: Only a member of this blog may post a comment.