The Agile Manifesto values "Individuals and interactions over processes and tools".
I have heard a lot of people talk about "People over Process" somewhat differently than my interpretation.
In this article, I'll refer to a fictional developer called Chuck - nothing is implied by the name.
Chuck doesn't want to write tests
A frequent interpretation seems to be, if Chuck doesn't want to write tests (for example) then that's OK because people are more important than processes or tools. A lot of the time, people talk as if the question of whether Chuck is worth keeping in the team or not isn't a consideration - you just have to do the best you can with the team you've got; after all, people are more important than processes so that's OK (a non sequitur, but I've heard it said).
This can be a difficult one to argue against. Whether someone is any good at software development or not, they are "more important" than process, tools, software - but that is a different "important".
The worst sort of "Agile"
The worst examples of "Agile" software development are where people take the approach that as long as you do the currently accepted "Agile things" (or at least some easy subset like iterations/sprints, stand up meetings etc etc) and keep your current team (because "people are more important than processes or tools") then you are "Agile". This is the opposite of my interpretation of the agile manifesto - but quite common!
My interpretation of "People over Process"
The single most important thing is to get the right people in the team. Just making your existing team follow a set of processes (like iterations/sprints, stand up meetings etc etc) is much less important than having the right people in the team. I think that is what the Agile Manifesto is trying to say.
As Simon Baker says "Put the right people in the right environment and trust them to get things done."
The consequence of this is that you should hire the best developers you can (this article describes the best way to interview them). The less palitable consequence is that you should remove developers from a team if they are not good for the team. That doesn't necessarily mean removing them from the company - it may be that there is another role or team in which they would contribute more. You should also consider whether a developer can improve - my experience has been that pair programming really helps to develop developers.
So should Chuck be made to write tests (or whatever)?
I'm not sure this is the right question. Really the question should be "is Chuck any good for the team?". If Chuck doesn't want to write tests then I think it's unlikely (but not impossible) that Chuck is (what I consider to be) a good developer. It would probably be counter productive to "make" Chuck write tests, but I'd be happy to pair program with Chuck to show him how it works. If Chuck still doesn't want to write tests then I might prefer not to be on the same team as Chuck (one way or another).
Copyright © 2008 Ivan Moore
Subscribe to:
Post Comments (Atom)
3 comments:
This article raises a common pain with agile in teams, and methinks one of several agile 'smelly' practices in which the mythical chuck might engage.
On the assumption that your context is a software team in which the remainder of the team are practising test-driven, I think it worth eliciting some useful techniques to provide motivation to Chuck, to understand his disinterest in testing and explain the damaging effect on the people within the team.
Personally I am not averse to finding an alternative role for Chuck within or outside the team if the 'fit' still isn't right - after all the effects of Chuck's actions on the way the people in the team work together may have a significant adverse drag.
Hi Ivan,
The concern you raise about different interpretations of the agile manifesto is interesting, but when considering the values of the manifesto on their own, not entirely surprising.
Anyone adopting agile who uses just the values as a justification for a certain way of working is missing the point. It's like driving a racing car off road. We know that we want to get somewhere, but don't understand the best way to drive the car to get us there.
That's what the agile principles are for. They tell me that my racing car is better suited to roads than going through rivers. They don't tell me how to get there, but they provide some guidance.
This is something I have been thinking on for a while and your post has prompted me to put down some of my thoughts. In case your interested, you can read it here.
Having helped in the hiring process of a number of teams now, I have to agree with your interpretation of 'Individuals and interactions over processes and tools'.
The right people for a team are more important than the process... but the right person is not necessarily the best coder. He or she may just add that little bit of fun to a team, that makes everyone enjoy work a bit more.
In my opinion the best people on the team are the types who react to change in process in a positive way. In the case the change has a positive effect, they are keen to embrace the change. In the case the change has a negative effect, they say things like "Well we've tried it, but things maybe worked better before, so perhaps we should try something else". The other sort oppose the change regardless of outcome, with a statement such as "That's not the way we do things around here".
Perhaps I am talking rubbish again, but people who are not able to change their process, can have a very negative effect on a team. Maybe this is related to the final agile manifesto statement, 'Responding to change over following a plan'.
Post a Comment