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