Most of this post is a repeat from my original blog in the mists of time (2005). I've written a lot about teamwork the last several months because it's something that I feel is both important and lacking at my current client. Say you have a guru in the domain logic in one cube with minimal software development experience, and down the aisle is a pretty decent developer with little or no business domain expertise. This is your entire team for a small, but vital analytical report. Do you:
A.) Give them separate tasks. Let the domain expert write functionally correct, but unmaintainable code while the decent technical developer writes beautiful code that does the wrong thing entirely
B.) Have them work together to combine their strengths and wash out their weaknesses
Individual ownership of tasks may be an easy way to manage the team, but I think that's the tail wagging the dog. A team that collaborates is better than a group of individuals.
Onward to the horror story about a dysfunctional team.
Project "Team" Insanity
I used Alistair Cockburn's chart below on the effectiveness of various communication channels in a presentation several years ago trying to convince my then management to move towards iterative and more collaborative processes. Basically, Alistair Cockburn is trying to encourage more interactive and collaborative forms of communication as a better mechanism for transmitting information. My organization at the time simply didn't consider the impact of communication and collaboration on project success.
At the time the entire organization was in a "matrix" organization structured by functional group first, and project teams second. Cubicle assignment was strictly by discipline (development, architects, analysts, testers, etc.) because management was tired of reorganizing teams and paying moving costs to colocate teams. Everybody was working on multiple projects at a time. This was done with the theory that all projects would have access to specialized knowledge and skillsets instead of these specialists being bottlenecks for the entire department by their limited availability. I had the distinctly unpleasant experience of simultaneously working on the rump end of a death march project as a developer (later cancelled), and trying to lead the development of a separate project with significant technical complexity.
The first project was an early Web Services project using a custom in-house SOAP-like framework developed by the internal integration architecture team (if you ever hear a sentence like that, run away!). The lead developer/project manager was in his first lead role and had no prior team lead or architecture experience. There were five distinct methods for the service, and five developers, so naturally each developer was assigned a method and told to go off and code it. I failed in my attempt to escape the assignment and began to code my assignment.
My first action was to throw out the technically unworkable design that was handed to me by an architect. Win32 API and COM calls from within XSLT transforms in a high volume system? Write a separate XSLT transform for every permutation of shipper, location, and shipping option? No thank you. Of course the estimate for my part of the development project was already scheduled in a Microsoft Project file months before I even came on board. Since that estimate was based on erroneous assumptions, I had to change that estimate upward immediately to the consternation of the team lead.
Early on, I asked the lead where the development database was located and was told each developer was just using their own box. Come to find out, every single developer had created or reused a different database schema structure to hold the same logical data. Two developers were using an existing Oracle schema structure, and the other three developers had made their own Sql Server databases. The Oracle transactional database was overworked and we had an opportunity to move some load off by separating the rules data away from the transactional data tables. In fact, that separation of schema was a secondary goal of the project from the beginning, but the entire team didn't get the message. There wasn't a common vision for the team and the project.
Two of us had created fully functional, specialized rules engines that did roughly the same thing, but radically different in implementation. I had no idea that my colleague was even doing anything related because I was in my silo and he was in his. If we'd worked together at all, we could have written much less code.
My first action as a newly minted Systems Architect (make finger quotes for the full effect) was to blow the whistle on the technical weaknesses to my new boss. The first effort was to try to resolve the competing database schema, but to no avail. We ended up with the exact same set of data expressed in two different set of tables. If the data was in one set of tables but not the other, the system wouldn't function correctly.
The project was fortunately abandoned and replaced by a different effort (2+ years in MSF Planning at the time that this was written!). For about the cost of 15-20 man years of effort, not one single line of code made it to production and the poorly performant existing system limped on.
I sincerely think the project could have succeeded if the developers had been working in a common location instead of in a complete vacuum. It wasn't the most talented team I've ever been on, but we easily had the talent to pull it off. Just accidentally overhearing conversations would have tipped us off that our code could be shared between service methods and certainly would have got us on a common database early. Of course, the fact that every developer was actively plotting to get off the project didn't help. Going through a massive reorganization at the same time didn't help either. I escaped to another project and into a lead role, but it turned out nearly as badly in a way.
The Second Project - Death March #2
The second project was an extremely complex system with three other developers, all of whom sat in different wings of the floor, and were working on other projects at the same time. At no time during the course of the project was the requirements analyst present on the team at the same time I was. All communication was through a requirements document that was prepared when I was on the other project. Unsurprisingly, that document turned out to be incomplete and/or flatout wrong. Come to find out late in the game, there was a second requirements specification with extra reporting requirements that no one in development knew about. My review for the year was partially tarnished by my having missed the upfront estimate badly. I was off to begin with, but the estimate was done with the requirements that I had in my hands at the time. We pulled it off by working way too many hours, but I'll never do a project like that again. The saving grace was very good involvement from the business partners, otherwise it would have bombed. The system is undeniably successful in production (one of my friends won an award from the business for it after I left), but it was a long time before I enjoyed software development again. I'm pretty sure the CMM crowd would call this an unrepeatable process.
Of course it didn't help that I was a technical dictator that over-engineered the application to a tremendous degree, but I'm making fun of other people here, dammit! I read somewhere that the worst designer is a fellow on his second project trying to use every idea he had from the first system (editor's note, it's from Fred Brooks in the "Mythical Man Month." Thanks to Darrell for the head's up). Guilty as charged. I'd also just read the GoF book for the first time and got a little patterns happy. They should put a warning label on that thing. If I were to do that system today I think I could do it with a small fraction of the code by keeping things simpler.
If I had collaborated much more early on with the other developers on design I think we would have knocked out a lot of the unnecessary complexity. Unfortunately the roles were defined as "Jeremy designs and creates detailed instructions that everyone else just follows." I created some unnecessary complexity that was followed to the tee by unthinking developers. The team's understanding of the design was limited because the rest of the team didn't have much involvement in creating the design. Instead of telling the other developers what to do I should have given them the tools to understand what they needed to do and make decisions for themselves that supported the design, architecture, and goals of the project.
My former employer has since quietly removed the worst of the organizational madness and is simultaneously working toward climbing the CMM ladder and tentatively introducing some basic best practices like automated builds and better unit testing. All I can say is good luck to you guys, and it'll be worth the effort (maybe not the CMM part, though).
I think it's fun to laugh at the absurdity of past projects, as long as you don't repeat them. Bad examples can be more illustrative than good examples sometimes.
So what did I learn?
I obviously soured on that employer. Less than a year after finishing the second project I got to jump straight from the pure insanity to a high caliber agile shop. An oranges to oranges comparison of effectiveness between the Microsoft Solutions Framework process at the first shop and Extreme Programming in the second is useless because too many other factors were different (stronger teams, more supportive organizations, less customer involvement), but the simple ideas below were an enormous improvement in my mind:
- Sitting near all of my teamates in an open room that facillitated collaboration
- Collaborative design
- Everybody focused on only the one project with a shared set of goals
- Developers, testers, and analysts on the project at the same time!
The simple act of colocation and ramping up the interaction and collaboration between team members is a powerful tool for building software. The absence of collaboration is a prelude to disastrous outcomes. One of the responsibilities of the team leaders is to foster a common vision and understanding of the project throughout the whole team. Creating a design and direction is one thing, but socializing that design and direction may be more important in the long run.