The Anti Team

EDIT:  Ayende's Anti Team additions is funnier than mine

We talk a lot about how to structure great teams — defining team roles and the qualities that we want team members to have.  Just out of pure mischief, and to fill a request from a friend, let's turn this around and I'll describe my vision of the worst possible team role structure.  Just in case you're wondering, this is an amalgam of a lot of different projects over the course of this decade and is not pointed at anybody in particular (ok, that's a bald-faced lie.  How about not pointed at anyone that is likely to be reading this).  Here you go, my Bizarro team–>

  • Non-coding Architect:  I fully believe that I can do a much better job designing and architecting software as a developer involved in the day to day construction of the code than a non-coding architect of equivalent skill.  Put it another way, designs get better faster when the designer has to feel the pain from clunky designs and adapts to alleviate that pain.  And frankly, I haven't come across too many non-coding architect's that had strong design skills when it came time to do detailed work.  You might say to me that the architect's job is simply the high level architecture and that the tech lead or developers should fill in the fine grained details.  I think that's mostly bunk because the fine grained "details" have an awfully lot to do with what the architecture should be in the first place.  I think the non-coding (or Powerpoint) architect position is a refuge for scoundrels.  Non-coding Architect is an order of magnitude worse when he/she is a member of a centralized architecture team that is the "keeper of the flame" for the enterprise architecture.  Traveling in packs reinforces the worst tendencies of Non-coding Architect guy.  For the sake of full disclosure, I was briefly a non-coding architect and have often clashed with non-coding architects.
  • "Spec" Coder:  The coder who will faithfully muddle through whatever design specification you put in front of him without deviation.  He's useless without a spec, because that's just not his job to design.  Much worse in my mind is the fact that "Spec" Coder will code without thinking or providing feedback to whomever is doing the design.  Non-coding architect plus spec coder is the worst possible project team permutation.  Being a "spec" coder is a fate that you need to avoid.  It's not a particularly fulfilling role, and the job security is not great.
  • UI Guy/Middle Tier Guy/Database Guy:  Dividing a team by horizontal layers has to be the worst possible developer team structure.  Too much specialization in a team is a bad, bad thing because your team becomes brittle when people specialize.  Think about this very realistic scenario, iteration #1 involves a lot of user interface programming but iteration #2 is almost completely about the backend.  Do you really want the backend developers idle in iteration #1 and the GUI folks idled in iteration #2.  When I'm a technical lead I've always found it more difficult to deal with specialists because their focus is so narrow.  I've always thought that specialists need a lot more hand holding to perform development tasks because they so frequently don't understand the context.  I'm a huge believer in "whole team" mechanics and purposely blurring project roles. 
  • Legacy Guy:  AKA, the "Bottleneck."  You've got to talk to the legacy code at some point, or even worse, modify it.  This guy is the one guy in the entire company who knows how to sacrifice animals correctly to change the legacy application.  He's spread across many different projects with the same needs, so getting his attention is always difficult.  Making matters worse, he usually doesn't speak the same language you do, and the cultural referents between the way he builds code and the way you do are very sparse.
  • Microsoft Project Project Manager:  This is the Project Manager whose world is completely bounded by and shaped by his Microsoft Project file.  Besides being extremely annoying, MPPM is completely incapable of adapting to changing conditions or even understanding that conditions are changing.  MPPM's primary tool is the "embarrassment meeting" where the entire team gives their actuals and gets called down on the carpet one at a time to be balled out for missing the original estimate.  Personally, I want my PM to be a road grader that gets out ahead of us and eliminates road blocks.  MPPM doesn't get that proactive style of management because they're too focused on the trappings of project management.  When I was an engineer on large petrochemical projects (250+ million), project controls and scheduling was a separate function from project management.  There might be something to that.
  • Out of Sight Testers:  Testers who are very isolated from the rest of the development team, usually coming onto the project at the very last moment.  I know that some people are adamant that the testers must be independent of the developers to the point of being completely isolated, but think of the cost.  Testing is about removing defects, and that is going to be much faster when the developers and testers are corroborating very closely.  Developers can fix bugs faster when the testers demonstrate the reproduction steps and test automation efforts go much smoother with developer involvement.  Think on this too, when you use waterfall testing you always have a ramp up time for the testers to understand the system, and you *always* tussle with the testers because they arrive at very different interpretations of the specifications than the development team did.  You can dramatically cut down that mismatch in understanding by having the developers and testers working together throughout the project.  Moving testers offsite is even worse.
  • Func'ky Spec Business Analyst:  The BA's that drop off a specification document and then disappear.  Any requests for clarification are automatically addressed by "didn't you read the spec?"  Grrrrrr.
  • Disinterested or Hostile Customer:  One way or another they're either paying for the project or they've got a large stake in the project's success, but they aren't the slightest bit interested in helping you.  Disinterested customer just doesn't want to be involved in the software.  Hostile customer thinks the best way to succeed is to administer regular beatings to the development team.
  • The Process Cop:  Somewhere, there's a group that is in complete charge of determining and enforcing the Process that all development teams will use.  They don't have to dogfood their own process, so they've got no incentive whatsoever to streamline things.  Chances are very likely that they haven't ever used the Process, but they've been to lot's of conferences.  They're also not particularly interested in your input, because that threatens their job.  One of many things that bugs me about CMMI is the Process Cop team.
  • Agile Zealot:  Yep, I'm willing to bomb on my side too.  Most of the antipattern role definitions are a side effect of bad waterfall thinking, but a truly dogmatic Agile Zealot is eXtremely unpleasant to work with.  If your judgement of right or wrong approaches is completely based on what's more XPish, you're likely to make bad judgement calls.  Actually, for that matter, XP or Scrum generally encourages and requires a very adaptive approach to how the team performs it's work.  If you turn off the adaptive aspect of XP/Scrum you've lost most of the advantages.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://agilerunt.blogspot.com Agile Runt

    Wow, I’m amazed at how many of these categories I have been in over my career. Maybe we should start a 12-step program. “Hi. I’m (your name here), and I’m a spec coder.”

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Steve,

    I’m clearly living in fairy tale land because I didn’t even think about PHB’s. Life’s better outside of the Fortune 500.

    Jeremy

  • http://stevenharman.net/ Steve Harman

    What about “Pointy-haired Boss”?

  • http://www.soulsolutions.com.au Bronwen Zande

    Love it…i’ve met every single one of those people.

  • AndrewSeven

    Too much specialization can be bad, but none at all can be even worse.
    To specialize is human.

    “Spec” Coders tend to be made, not born.
    Time and again, they are given long winded explanations of exactly why the spec is right and they are wrong. Eventualy they just code the spec.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Thanks a lot Kelly. Now I’m gonna have that “Code Monkey” song stuck in my head all day!

  • http://codewright.blogspot.com/2005/12/codewright-and-code-monkey.html Kelly

    You forgot one, the Code Monkey The Codewright and the Code Monkey

  • Carlton

    I’ll add one of my own: Stay-Out-Of-The-Middle Middle Manager

    This poor creature is more political than practical. His\her primary responsibility is to deflect blame and never be caught holding the ball. When it suits their purpose, they make all the technical decisions for the technical people and when a critical decision has to be made, they are no where to be found. Eventually, when you do catch up with them, they pass the buck to the customer and let them make the decision, so they are off the hook if things go wrong. As the epitome of middle management dweebs, they are only concerned about how to improve their political position in the project and\or company. Delivering quality software is only an afterthought. The worst of all management types to have on a software project since they will never let you make a decision on your own.

  • http://www.agileadvice.com/ Mishkin Berteig

    I’m an Agile Zealot!!! I admit it. I revel in my zealotry…

    But I’m not an agile process zealot. I like Scrum, I like XP, I like Crystal, I like Lean. But even better, I like learning, delivering frequently and facilitating team, process and tool improvements as fast as an organization can handle.

    So being an Agile Zealot in my mind is not the same thing as being an XP zealot or a Scrum zealot, etc. I’m willing to change the terminology I use, the techniques I use, etc. as circumstances demand. I’m willing to leave process elements for later or never.

    A really good example is with Scrum. If you have a small team (<5 or 6 people), then Scrum with its ScrumMaster and Product Owner roles (who are counted as part of the team), makes it too heavy a process. So reduce/drop those roles to part-time! Why not?! Sure, in some ways it will be harder to succeed. But smaller teams are more agile (almost) by definition!

    My first experience with agile was on a team of three people including myself. It was great and we certainly didn’t have a process facilitator – we all were worried about the process. We certainly didn’t have a product owner – we were working as a team with potential customers. And we still managed to deliver new functionality on demo-able software every three days. And we did it in the snow while walking 20 miles to and from work, with no mittens and wolves chasing after us…

  • Mike Gale

    Seen one way you make a really good case to eliminate job roles and heirarchy entirely in a coding organisation.

    As an ideal all team members can do most everything and move between roles as the need dictates. (Something entirely familiar to the one man or small team.)

    The biggest danger I’ve seen is really grokking what the project is about AND understanding that current computer science can often give only a pale and weak imitation of the blue sky idea.

  • http://codebetter.com/blogs/jeff.lynch jlynch

    Best teamwork post I’ve read in many years!

    I just have to add one more “role”, the CIO project manager. He personally takes charge of every business critical project but hasn’t written a single line of code in twenty years. If the project is going well, he’s at every meeting making sure to slow things down. If the project is behind schedule or needs help, he can’t be found since he’s usually giving an interview for Baseline or CIO magazine. If the project succeeds, he gets all the credit. If it fails, it’s the team’s fault.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Chad & Eric,

    How about Garbage Pail Kid style trading cards?

    “some of the people you describe do serve some purpose as long as they don’t have too much power”

    probably says it all. I do think Enterprise Architect teams can be useful, but mostly in a “Systems Analyst” role that looks at business and integration processes between systems. That being said, these guys should never, ever have too much power over application design.

    I’m one of those guys that is absurdly paranoid about dealing or depending on anybody from outside my immediate project team. I’m vastly happier when I only have to depend on people that have a measurable stake in my project succeeding.

  • http://www.hdri.net Chad Myers

    This sounds like it should be a Sat. morning cartoon show. Where do I buy the trading cards?

    You know, some of the people you describe do serve some purpose as long as they don’t have too much power. The head-in-the-clouds architect is sometimes useful to help keep all the various projects in the enterprise going in the right direction, as long as that person doesn’t concern himself too much with the minute details (i.e. he should be concerned with everyone using Web Services/SOAP for interop instead of home-grown XML services, rather than what the particular SOAP interfaces are).

    In some circumstances, a disconnected test team is helpful, if not required, but I wouldn’t have ONLY a disconnected test team. Your primary test team (the one responsible for defects) should be close-knit like you said, but any industry-compliance, specification-compliance, etc test teams might work better if they’re more disconnected so that they can keep perspective.

    Legacy guys are, well, legacy. What can you do with ‘em? They’re already on their way out anyhow (thus the ‘Legacy’ moniker). You just have to put up with them I guess.

  • http://www.codebetter.com/blogs/eric.wise ewise

    Excellent.

    I never will quite comprehend the “Enterprise Architecture” team in most organizations. It seems like these non coding architects and developers with overinflated egos like to run off and spend months creating a brittle and unecessary architecture up front.

    I personally favor the code, promote and refactor approach. That is, let the team that needs the process code it first, and when another team needs it, look into extracting and refactoring it into the framework. This way, the framework only contains what is needed at the time it is needed.

  • DonD

    I might add Disinterested Platform Owner: you are reuired to use them, but they care nothing about you (they have many other more important customers). They don’t want to know about problems with their product, and your management is afraid to replace them.

    Not that I’ve been suffering through this the last few days or anything. Nor is it especially grating when the Platform is basically 2 guys in your company, who show all the care and sense of common purpose as the IRS.