One of many things I love about Ayende is the tagline in his blog “Specialization Is For Insects,” which brings me to my point this morning: over the long run a flat team of generalists with healthy overlap between skillsets will blow the doors off a hierarchical team composed of specialists.
I hit the issue of a self organized team versus a strict hierarchical team before in Self Organizing Teams are Superior to Command n’ Control Teams, but this morning I’m more irritated over the specialist thing. Two issues yesterday brought it out for me in stark contrast:
I’ve got about five weeks sunk into a new financial product in our system in the .Net UI client. Sometime this morning (knock on wood) I’m going to declare it ready to deploy, but it’s not. We can’t deploy it because the server side work to integrate with a 3rd party system hasn’t even been started. This is obviously an extreme case with a wide variance between skills, but it renders my work on the .Net client effectively useless. Yes, it will be ready to deploy when the integration, and the issues that uncovers, are complete. In the meantime though, we could have played my time and effort into features that could be deployed and start providing value now.
Myself and my ersatz team were brought in specifically for WinForms work, but I insisted on being involved with the development of the Java web services as well. It’s led to some pain on my part learning how to get Apache Axis to work for web service development but it’s paid off. This week we had a defect related to a field not being saved properly between the UI and server. Because I have visibility and understanding of the entire system from front to back, it was relatively easy for me to diagnose the error in an iBatis map on the server side. A UI specialist would have just spun their wheels for a while. Since all my Java server side “resources” are temporary assignments, I would have been screwed if I hadn’t worked on the Java end as well.
Case 1 is a bad break because of specialization. Depending on specialization makes planning and scheduling more difficult, especially when you’re planning across multiple project streams. If your plan has a fixed dependency on a time bound utilization of a particular specialist, you’re plan is now exceedingly brittle. A self sufficient team that can take care of all of its needs can be far more resilient in the face of scheduling changes and unforeseen events. And how often does an unforeseen event happen in a nontrivial software project? Moreover, it takes far more detailed planning when you have specialists and dependencies between the workflows of the specialists. A team of generalists can happily shift around depending on what needs done at that moment. Unsurprisingly, the type of adaptive planning used in XP/Scrum projects works vastly better with a flatter team of multi-skilled individuals.
Case 2 was a good outcome that was enabled by having at least one person (me) involved on both the client and server side. I can build most complete features from front to back without any assistance from anyone else, making the turn around for new features less than it would be waiting for the server side guys to come available. Troubleshooting and testing in a full integration mode is much easier for me than it would be for two people handling either side alone, and most of the problems are integration issues.
More things:
A team of generalists can be a smaller team of folks dedicated to the project instead of a strung out group of specialists who come on and off the project. This cuts down the communication overhead and enables Agile practices to be more successful. Communication overhead is a significant cost in any project. Cutting it down can only help.
You can raise your Truck/Lottery Number. You shouldn’t be crippled because one team member is on vacation.
The team members have a much better understanding of the technical solution as a whole, and I think this contributes to better decision making.
