Agile Zone is brought to you in partnership with:

Jay Fields is a software developer at DRW Trading. He has a passion for discovering and maturing innovative solutions. His most recent work has been in the Domain Specific Language space where he's delivered applications that empowered subject matter experts to write the business rules of the applications. He is also very interested in maturing software design through software testing. Jay is a DZone MVB and is not an employee of DZone and has posted 116 posts at DZone. You can read more from them at their website. View Full User Profile

Individuals Over People

07.20.2011
| 4131 views |
  • submit to reddit

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.

 

From http://blog.jayfields.com/2011/07/individuals-over-people.html

Published at DZone with permission of Jay Fields, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Kim David Hagedorn replied on Wed, 2011/07/20 - 3:35am

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.

I think there's a very important point to that. As nearly everybody in the software industry believes to be very intelligent, and sure a lot of people really are, people will start to break rules too soon, before they have understood what a certain rule is all about. Thats the main reason why so many scrum-buts are around and also a reason why many attempts to become agile fail.

And that is why i think that writing and blogging about how to break the rules of, e.g. Scrum, is not a great idea. Those who really understood what these rules are about and how a framework such as Scrum implements them probably don't need to read about how to break them. But those who still need time to understand the underlying concepts, and how the restrictions of an agile process will actually deliver value, might get the wrong ideas when reading too much about breaking the rules. I guess this is also the reason why people like Ken Schwaber or the XP guys are so religious about their processes. Because even when you think you got it and you are ready to adapt the processes, most probably you aren't. Also, you should consider why you want to modify your agile processand if the problem is really with the process or if it is with your implementation of it.

Considering individuals and teams, I believe there is a valid point to what you say, but you should be aware that once you start to allow exceptions for individuals it might be hard to draw a line. Because saying 'the team is important but individuals are more important' to me actually sounds like an excuse for cowboy coding and no process at all.

Jilles Van Gurp replied on Wed, 2011/07/20 - 6:56am

There's the communist/dogmatic interpretation of agile which dictates that the team is self organized, the team owns its code, etc.

None of that is directly implied by either the agile manifesto or the various popular agile methodologies.

Sadly though it seems to be the common interpretation and it is flawed because it is based on broken assumptions.

Broken assumption #1: all team members are equal

Reality: it's a meritocracy: some people are simply less equal than others (to the point where you shouldn't even bother asking their opinion). In practice that means if the tech lead says foo, than foo it is regardless of the naive sentiments that might live elsewhere in the team. Also, there are absolutely huge differences in productivity between individuals.

Broken assumption #2 all team members are equal, therefore we don't need a tech lead.

Reality: Not having a tech lead is of course an elementary mistake. It means that in all likelyhood you are delivering inferior software too slow.

Broken assumption #3: the product owner is technical enough to make technical decisions.  Decisions like when to refactor or how to translate stories into technical requirements.

Reality: in all likelyhood the PO is a business type that will set the priorities from a business perspective and not a technical perspective. You need a strong tech lead to do the detailed planning because the product owner doesn't have a clue and will systematically de-prioritize all the good things that will improve code quality because it is 'not a priority'. If you are arguing with your PO about refactoring, that is a dead on sign your project is doomed.

Broken assumption #4: everybody on the team is up to speed with everything

Reality: you have experts on the team who can speak authoratively about their topic and related code. Not listening to them, or overruling them in meetings is not productive and will get your project in trouble. There are always going to be people who are more up to speed with certain things than other people. 

Broken assumption #5: estimations should include everybody on the team

Reality: estimations are more effective if you do them with the subset of your team that is going to do the actual work. From broken assumption #4 it  follows that that is probably not some randomly selected person. So get your techlead, subject expert, and whomever else on the team is going to be involved together. Get them to agree on a strategy for implementing and then estimate.

So, yes. Unless you are taking the individuals on the team into account, you are effectively putting process over people. 

Jilles Van Gurp replied on Wed, 2011/07/20 - 7:12am in response to: Kim David Hagedorn

The reason there is so much scrumbutt might be that scrum is not all that is hyped up to be. People getting relegious and defensive about processes is a good sign that something is fishy. What scrum needs most is some healthy, unbiased criticism. 

Ken Schwaber et al. will be the first to point out that scrum is not perfect. It is merely the best way they know how to do things. The reason there's so much scrumbutt is simply that there is no one size fits all solution to developing software. In my view, the dogmatic people that believe otherwise are part of the problem and not of the solution.

Also, scrum comes with so many disclaimers that there is almost no way you can do it right. That gives scrum faboys the excuse of saying "but you are not doing it properly" when things go wrong. You never read much about all the scrum failures, just the success stories are cited. But our industry is full of failure. Failure rate has not been affected in any measurable way since scrum became popular (despite being widely spread). In fact, it's more or less a constant in our industry. 

Kim David Hagedorn replied on Wed, 2011/07/20 - 8:27am in response to: Jilles Van Gurp

I have experienced a Scrum implementation to more or less fail, because of too much and too early modification of core principles, while I have seen other teams succeed that tried to implement Scrum the "correct" way in spite of problematic circumstances.

I am totally with you to say that Scrum isn't perfect and might need adaption. But I guess in most cases adaption happens too early and too thoughtless, before key principles were understood.

Sirikant Noori replied on Fri, 2012/03/30 - 1:09pm

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.

Java Exam

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.