"Sure, Agile approaches an answer to many of the noted problems all too common in the software development world, and maybe in another decade we might improve upon it some more. But amongst the positives, it occurs to me that Agile robs us of specialization, making all developers fit a ridiculous mold that only a handful can actually aspire to fit, hence the consensus that there is some need for "less than agile" methods. It's great to be able to learn new things and do so at light speed, but that is not every developer trying to make a living. So all you do is reflect back your own smugness when you talk about these so-called "incompetent individuals." Beware that label: One day you, too, will reach age 50 and the youth getting by on 1/3 of your pay will undercut you because they are 80% as good as you.This is a great comment because it raises some very important themes. I was going to touch on them all in this post but I'm afraid that would result in a huge post that few would have time to read. So what I'll do today is list the themes and start a discussion on one. Over the course of the next few days I'll post some thoughts on the remaining themes.
Another observation I have about Agile gets right to the heart of why nothing attempted by the Agile community matters, and that is: Agile fails to address the evils of management. It doesn't matter how well you estimate something, management will always demand twice as much no matter how much realistic evidence you present to them. Management sees Agile only through the lens of "how can I make these assholes produce more and whip themselves in the process?" And so we have reopened the doors to the sweatshop. Information Sharecropper has a real nice ring to it, though, right?
You want a fix? How about making software development a profession equal in status to doctors and lawyers. That will solve 99% of the problems. Doctors don't let non-doctors manage them, it simply is unacceptable.
What I'm looking for is that holistic manifesto--the one that gets the job done, gets me paid, and doesn't leave me feeling completely played the way I have been for over decade now. Anything else is just blather. Smart people in America are just easy marks."
First some background, over the past dozen years I've held a number of software management positions from team lead to CTO. Prior to those years I was writing software primarily in C++ and Java for client and server solutions. I've directly led small teams and also led organizations up to 100 software professionals. I've managed using both traditional, planned methods as well as agile methods.
Here are the important themes that this terrific comment touches on.
- Specialization vs generalization
- Agile for the elite superstars
- Evils of Management
- Respect for the software profession
Agile teams work very closely with each other on a daily basis. Team members collaborate on problems and solutions all the time. They communicate with each other at least once daily but typically much more. Team members are expected to pick up tasks even when not directly in their field of expertise
So does agile necessarily rob us from the benefits of specialization? I think this is less of an agile issue than it is a team issue. Do you value the speed that comes from deep specialization (at the risk of damaging your company should a specialist leave) or the flexibility of generalization (at the risk of team members being jacks-of-all-trades-and-masters-of-none)? In my experience, the benefits of specialization, even on agile teams, are too great to move to total generalization. That said, agile teams do not necessarily mean a push to generalization. Software developers are not automatons. If an agile team is truly doing their own planning (and not under the thumb of a heavy-handed manager) they will naturally leverage the skills and experience that are on the team. The following quotes are representative of the meme I'm expressing here and all commonplace on the teams I've been involved with.
"Jim, you know databases better than any of us, can you take on this schema deliverable?"
"I'll do the UAT for this requirement. I'll fit right in to the framework Janet and I wrote a couple iterations back."
"I'll take on the server task. Nathan, can I get some of your time this iteration since you know the server so well?"An additional benefit of an agile team arrangement is that the daily interactions developers have result in some specialized knowledge getting absorbed into more team members. This reduces the company risk of maintaining specialization pillars. Teams naturally drive towards becoming (and by now you've probably been wondering when I would bring up this term) generalizing specialists. There's enough written about generalizing specialists that I'll just leave you a Google link.
Coming up tomorrow - Agile: Average Developers Need Not Apply?