Do we need this Agile malarky if all we need to do is get rid of all the "deadweight developers"?
This question implies two other questions:
- Does an Agile approach improve less-skilled developers?
- Should we even bother improving less-skilled developers?
Does an Agile approach improve less-skilled developers?
Back in the day, there were questions about whether Extreme Programming (XP) was really only for highly skilled developers and less-skilled developers required more heavyweight approaches like the Rational Unified Process (RUP).
Ralph Johnson (co-author of Design Patterns
) described his experiences teaching software engineering at the University of Illinois where the students had both XP and RUP projects:
) described his experiences teaching software engineering at the University of Illinois where the students had both XP and RUP projects:"...they do not have the experience to design anything reasonable. If they try to follow RUP, the time spent designing is totally wasted. When they follow XP, they get test cases to run, producing horrible code at first. They don't make rapid progress, but they make progress. After a few months, they start to realize that their code is lousy and then reading the refactoring book helps them a lot. By the end of the year, they have working code and have become much better programmers.
So, my experience is that XP is especially good for novice programmers. It only asks them to do things of which they are capable. RUP can work if you have an expert who is trying to lead a group of novices, but if you don't have an expert then it will not work.
This is not to say that RUP works better than XP if you have an expert leading a group of novices."
In other words, XP is designed to use concrete feedback to develop skill. I'm not as confident about other Agile methods and less-skilled developers.
Okay, so let's say you accept that given less-skilled developers, an Agile, or more specifically, XP approach would help improve their skill. There is still an open question of why you should bother improving their skill instead of just cutting the "deadweight developers" loose.
Okay, so let's say you accept that given less-skilled developers, an Agile, or more specifically, XP approach would help improve their skill. There is still an open question of why you should bother improving their skill instead of just cutting the "deadweight developers" loose.
Should we even bother improving less-skilled developers?
There's a well-known response from W. Edwards Deming on how to deal with "deadwood employees":
"Were they dead when you hired them? Or did you kill them?" (via Dealing with Deadwood)
In other words, how much of the low performance of the developer is less a reflection of the individual and more a reflection of a broken surrounding system.
Most "poor developers" I've met have had poor teachers and a poor supporting environment. The question is, why should I design a system that only works with people who can compensate for being in an inferior system? I would suggest that this is reflected in poor diversity and difficulty in finding people.
When thinking about this topic, I tend to remember the story of NUMMI where the worst of the worst GM plant became the best in GM in about a year, with pretty much the same people, by adopting the "team way of working" (aka Toyota Production System).
Workers who could reasonably be considered the worst kind of deadwood all of a sudden becoming examples of the best way of working.
But we're not manufacturing cars. Surely there is minimum level of sheer intellectual capability that not everyone has.
I can accept that. There are developers that perform better than others. That's empirically true.
Where I split ways is what the response is for developers who are not currently performing at the same level. The best performer is the standard. However, if you are willing to learn, we should be willing to teach. If you are not willing to learn...
There are also problematic consequences of believing in this idea of "deadweight" even for high performers.
Believing too strongly that there are some developers that are deadweight and others that are not reinforces a fixed rather than growth mindset, which is a dangerous, performance undermining thing to reinforce, especially for high performers.
Also, the mentality of abandoning people is incompatible with the reflex of empathy required to succeed in an Agile, and arguably any successful, product development environment.
Most "poor developers" I've met have had poor teachers and a poor supporting environment. The question is, why should I design a system that only works with people who can compensate for being in an inferior system? I would suggest that this is reflected in poor diversity and difficulty in finding people.
Workers who could reasonably be considered the worst kind of deadwood all of a sudden becoming examples of the best way of working.
But we're not manufacturing cars. Surely there is minimum level of sheer intellectual capability that not everyone has.
I can accept that. There are developers that perform better than others. That's empirically true.
Where I split ways is what the response is for developers who are not currently performing at the same level. The best performer is the standard. However, if you are willing to learn, we should be willing to teach. If you are not willing to learn...
There are also problematic consequences of believing in this idea of "deadweight" even for high performers.
Believing too strongly that there are some developers that are deadweight and others that are not reinforces a fixed rather than growth mindset, which is a dangerous, performance undermining thing to reinforce, especially for high performers.
Also, the mentality of abandoning people is incompatible with the reflex of empathy required to succeed in an Agile, and arguably any successful, product development environment.
What I'd advocate instead
- Improve your selection criteria. Some people do have greater skill and the right mindset to perform and improve much more quickly than others. The right mindset is more important than greater skill BUT both is better and there is a minimum level of capability.
- Improve your human development approach. I like the XP / Agile environment as a way to do this.
- Never reinforce the idea that anyone is deadweight. The best is the standard, but if you are willing to learn, we are ready to teach.
No comments:
Post a Comment