How is your small software team organized?

May 1, 2006 8:12 PM

I'm interested in how small software development teams (under 10 people) organize themselves.

What are the titles and roles of the people on the team? Who reports to whom? Do you like the way you're organized, or was the structure forced on you, and you'd set things up differently if you could?

posted by medpt to technology (6 answers total)

One of the relatively successful software development teams I was a part of went something like this, on a per-project basis:

A Software Development Manager/Senior Developer/Mentor, to whom everyone else reported directly.
A project manager, who kept schedules, facilitated requirements and acceptance negotiation, and did communications. Everyone dotted-line reported to this person, too.
A documentation person (who occasionally was also the PM, but only when expertise permitted).
A mix of 1-3 developers or senior developers, depending on the project's needs.
A junior developer when available.
Someone assigned from a QA pool.
An infrastructure person (a role often fulfilled by the manager, since he had solid SA competency as well).

It worked perfectly for me, and I loved that organization. On the other hand, I was the Software Development Manager, and the team's organization structure was of my design.
posted by majick at 8:57 PM on May 1, 2006

If you're concerning yourself with titles and reporting structures for a team that small, the odds are that your project is going to go down the sewer. You're not focusing on what's important.

Structures that complex and rigid are usually intended to apportion blame, not to succeed.

Here's how we organized ourselves with a team of 12 on one project at Tektronix: one project leader, who concerned himself mainly with bug tracking and with keeping management off our backs. 11 grunts who spent all their time working hard on getting stuff done. Schedules made by a core group of four of us before the other 8 were brought on board, and stuck to for the entire rest of the project.

And lots of walkthroughs.

No titles. No reporting structure. All 11 grunts worked for the project leader, and he never issued any orders because he trusted us to know what needed to get done.

We brought the software in 3 weeks ahead of schedule.
posted by Steven C. Den Beste at 9:29 PM on May 1, 2006

I don't have any experience with software teams of n>2, so I can't directly comment, but if you haven't read The Mythical Man Month I'd recommend it. It's not all relevant to modern coding, but it's got some pretty fundamental ideas in it that will, I think, be helpful to you. The wikipedia page I linked is of very dubious quality, but it links to the actual book and provides a brief (if rough) synopsis.
posted by heresiarch at 9:36 PM on May 1, 2006

Wow, that certainly was a lot of commas. Oops.
posted by heresiarch at 9:43 PM on May 1, 2006

I think successful teams adopt an organization that is suitable for the complexity of the project. In a lot of teams, where the projects are full cycle SDLC, the team membership changes completely over the life of the project, as skill set needs change, and various project phases are completed. At the outset of a project, there may be people with requirements gathering and project management skills involved, whereas once requirements are set and coding begins, coders are added to the point that they become the dominant skill people on the team. Later, after roll out, maintenance phase people may actually be involved in user documentation and second round requirements planning, beginning the staffing turnover cycle naturally, all over again.

One project I joined, for an MRP II system, had been going on for 11 years when I joined it, and was thought by its management and leadership to be likely to be a quasi-permanent organizational unit indefinitely. I came in to manage a small sub-team of 4 SQL and database specialists, revamping the BI layer for a new distributed reporting systems architecture. We worked on the project for 27 months, and once our contributions were rolled out, our sub-team was disbanded and analysts went on to other assignments.

We used some PM services from the main team, plus QA and test personnel from the main team and user test delegates, and our sub-team was essentially task managed by the PM mandated schedule.
posted by paulsc at 3:33 AM on May 2, 2006

This isn't a specific suggestion, but the 37 Signals guys talk about small teams a lot. It's worth looking through the archives on their blog. And I've found that their Basecamp product is just about the best tool out there for small team projects, particularly when the team is dispersed geographically.
posted by j-dawg at 8:02 AM on May 2, 2006