"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?
7 comments:
What a great post, with more to come! This kind of dialogue on such important topics is invaluable and I hope lots of other people chime in.
While I agree the comment raises some important points, you are being far too diplomatic when calling it a "great comment." :)
As for generalization v. specialization, I think you're correct: Agile is about team practices, not (necessarily) individual practices. Thus, leveraging specialization within the team is perfectly acceptable as is having someone become a specialist. In my experience, there is no reason to think that Agile is hostile to specialization. (Perhaps the commenter asserts the hostility exists due to the fact that Agile doesn't really require it.)
As making software development a profession, that's a whole other issue. (What 99% of problems will that solve, exactly?) Furthermore, "doctors don't let non-doctors manage them" is a gross generalization and patently false.
I'm going to briefly comment now and expand my thoughts on my own blog, but here is the summary:
The atmosphere of described under "Specialist vs Generalist" is closer to what I would call "Cog-in-the-machine vs Member-of-Startup". These are broad generalizations and I wish to be clear that they do not refer to any particular company.
Speaking hypothetically however, if you, as a coder, are in a large organization and you stay there long enough, you will become a "specialist". It may be an accident or it may be a product of survival - you learned more about something and that is why you are still there. You are a cog in a larger machine, but you are important enough to be kept on because of your specialties. The larger the company, the larger the pool of identical cogs, the more like a slot on an assembly line you become.
In a startup or "small" company, there is always more work than people to do it. This means that even if you are specialized, you will have to take on non-specific tasks to keep everything moving smoothly. A startup has a more limited capacity to take on specialists that refuse to stray to other areas.
The Agile team that Peter Scheyen is describing fits the "startup" mold - and that is what is being held up as a good Agile team. I would have to agree that, from a team perspective, this is excellent. Personally I have been trying to figure out a balance between a purely distributed model (every member knows what to do) and a purely leader-based model (team members are told what to do by the leader). There must be a balance between these extremes, especially if an Agile organization has more than one team.
The promised "expansion" of my previous comment is now available. Of course, it has turned into a series of posts, but we'll see how far that goes...
Yes, really.
The promised "expansion" of my previous comment is now available. Of course, it has turned into a series of posts, but we'll see how far that goes...
Cool! I like it.
Post a Comment