Development Team Models

Software development is a young discipline. As such, practitioners and managers try to use techniques from other disciplines to control and improve it.

There is a wide variety of analogies that people use to think about teams of software developers:

ChiefProgrammerTeam

This model is based upon that of a surgical team. A "chief programmer", like a chief surgeon in a SurgicalTeam, makes all the decisions and does all the important work, while the rest of the team provides specialized support.

The downside of this model is that the success of the team is very dependent upon one person.

Assembly Line

This model, favored by many managers, treats software development as a manufacturing activity. This is attractive to managers, as they can use manufacturing management methods to attempt to monitor and control the activity. Developers tend to dislike this model, as it treats them as cogs in a machine.

Managers like this model because they want to be able to measure things and to use those measurements to predict outcomes. For example, if they think that a software project will require 100,000 more lines of code, and the team is producing 500 lines of code per day, then the managers can predict that it will be complete in 200 working days.

Unfortunately, this does not work well in practice. Use of statistical methods for measuring and predicting productivity tends to work only for very large teams. See ProgrammingAintManufacturing.

See also AnalogyBetweenProgrammingAndManufacturing (which takes a broader view of both programming and manufacturing than this straw-man "Assembly Line")

Construction

In this popular model, software is designed by "architects" and built by skilled craftspeople.

CodeComplete has a good description of this model.

See also CowboyCoding.

Symphony Orchestra

Here, the leader is seen as a conductor who organizes all the workers such that they work in harmony. Sounds nice, but is not very much like reality.

Why not? It's a classic project manager + project team members organization. It's also pretty much the way I run my team - but we do infrastructure engineering, not software development

Well, I've never worked with a symphony orchestra, but I assume that there is a cycle of "rehearsals" and "performances". The real work of the conductor is to interpret the pieces and give instructions to the musicians during rehearsals. At a "performance", the conductor doesn't really do much (in comparison to the non-performance work).

Well, yes, if you take the analogy too far then it's clearly not accurate. A software development team is not an orchestra. But a central coordinator (conductor) who arranges that all the developers (musicians) are working from the same song sheet is a valid model, I think To make this a metaphor for software development, the conductor would be the "technical lead", and the "musicians" would be the development team members. Maybe some analogies can be drawn between "performance" and "software delivery". But I don't think the overall model works very well as an analogy for software development, for these reasons:

The individual musicians in the symphony have little effect on the overall product.
A symphony orchestra doesn't have long-term "projects"; its cycles are very short and are unrelated to one another.
An orchestra plays a piece of music written by someone else. They don't have the opportunity to re-write (re-design) the piece; they are constrained by the notes on the pages. And a conductor can refer to how others have interpreted the same piece. In contrast, a software development project tends to be unique and under constant re-design.

And programmers generally look silly in tuxedos.

Movie Set

SoftwareAsFilmMaking

In this model, the technical leader is seen as the "director" of a movie, and the development team is the "crew". The project manager is the "producer". The system architect is the "script writer".

Movie production is similar to software development in these ways:

The director makes the creative decisions; the producer makes the business decisions.
The crew is a set of skilled craftspeople. And many of those crewmembers can make significant creative contributions.
A project lasts for a long time, and has several phases: pre-production, production, post-production, and release.
Re-writes of the script are common, there's a lot of editing, and the final product doesn't always match the script.

It is not similar in these ways:

Movie crewmembers are not interchangeable. A cameraman wouldn't temporarily fill in as a sound editor, for example. In contrast, software developers are less specialized.
There are no opportunities to fix problems with a movie after its release. (Sure, there are "Director's Cuts" and re-releases, but those are the exception.)
Most movies are created for a mass-market audience. Most software development is highly customized for a small group of users.

Maybe I'm reading too much into this analogy, but where does the cast of the movie fit in? -- MikeSmith

I intentionally made everyone "crew" to avoid the problem of treating actors as special, due to their celebrity status. I suppose you could look at computer-world celebrities (BillGates, LarryEllison, SteveJobs, JohnCarmack, SidMeyer?, LordBritish) and gauge how they affect the products their companies create. But that's another difference between software development and movie-making: most software customers don't "see" any of the team that produced it. -- KrisJohnson