I am not a brick in the wall

I enjoy what most people would call "Hard" music. I grew up with the Sex Pistols, Black Sabath, and of course Pink Floyd. I enjoyed the Wall when it came out (both the album and movie), and still listen to it from time to time. The title song contains the lyric, "All in all you're just another brick in the wall". Its not what most would call a pretty picture. Yet its the way most Agile Methodoologies view development staff.

I am told that I should not consider individuals when I am planning my projects. It is better to plan for the team. I can just guess how much the team will get done. Then as I track how much the team actually gets done I will start to understand how bad my guesses are and I can plan accordingly. Setting aside for the moment the idea that I should not try to become better at estimating how much work a task is, lets focus instead on the idea of scheduling for the team.

I have spent most of my professional life working on integration code. I have a background in hetworking (I used to be a network administrator and troubleshooter). This gives me a special insight into how the network is going to respond to the various schemes for getting two (or more) applications to talk to each other. I tend not to make certain mistakes because it is obvious to me that the underlying network will have issues with it. As a result of this experience I tend to get integration tasks done more quickly than other programmers. More then just getting them done faster, my solutions typically have fewer problems in the wild.

This is not just me patting myself on the back, however. I am especially bad at creating GUI code. I tend to take a long time. I tend to focus on things that turn out to be of little importance and not spend enough time on things that are important. Not to say that my code is trash, but it is not nearly as good as some other people on my team who have sort of specialized in GUI development. They just natuarally avoid certain mistakes that their experience has told them to avoid.

Now let's consider that I am planning a vacation (which I am). I will be gone for a week and a half. If it turns out that there is little integration work during that time, this will have a minimal impact on the schedule. After all the GUI work that I would have gotten done in that time is limited by my ability to do GUI work (or lack there of I guess). If there where a great deal of integration work then the story would be reversed. However I am told not to worry about such things. This seems odd to me. Am I really supposed to believe that my manager and I can switch places (see last weeks post) and that will not have an effect? That I can trade work with the Intern who is not yet finished with his degree and the outcome will be the same?

No I think not. Maybe I just don't understand, but it has not been due to lack of trying. I think Agile methodologies have it dead wrong when I am told not to do detailed planning and to ignore people's strengths. Of course I think Agile methodologies get other things right. But more on that next time.