Specialization in teams allows team members to do what they are good at and what they like to do. There are at least three types of specialization in software development teams: functional specialization, subsystem specialization, and technology specialization. Here I’d like to focus on functional specialization. A role is a specialized function in a team: a locus of responsibility and authority to perform certain types of functions.

All software development methodologies pay special attention to roles. As an example, the Crystal Clear methodology of Alistair Cockburn defines the roles of sponsor, expert user, lead designer, designer-programmer, business expert, coordinator, requirements gatherer, tester, and writer.

Clearly, the way we divide our work into roles has a major effect on our team’s health and productivity. One way to choose the roles appropriate for our teams is to start with a suitable methodology, and to try and fit the team to that methodology. Another is to simply follow precedent in our organizations. A different way is to consciously decide what roles make sense for our teams, by drawing on the body of knowledge in different software traditions, and by using our own experience and intuition.

The teams I work in are generally small development teams, typically working on vertical commercial applications. So here are some role basics, based on my experience, that might inform the conversation about what roles actually make sense for our particular teams.

The way I look at it, there are three basic functional areas, or disciplines, in development teams.

• Functional design. The functions of the system have to be conceived and their externally visible form has to be designed.
• Engineering R&D. Feasible approaches to implementing the required functions have to be figured out.
• Construction. The required functions have to built in a production implementation.

This view of the world is informed, but not necessarily constrained, by the ideas of Alan Cooper (see, Imagine This, a 2002 talk by Cooper at SDForum).

Work in various disciplines occurs throughout each iteration. The term discipline comes from the Rational Unified Process (RUP), which defined its own set of disciplines. As explained in the RUP literature, disciplines and phases are orthogonal concepts.

Functional Design versus Construction

In 1970, Winston Royce in his influential paper, Managing the Development of Large Software Systems, proposed that the most basic activities in software development are analysis and coding. Functional design and construction are somewhat more general incarnations of Royce’s analysis and coding disciplines. This type of distinction is also present in all major traditions of software development, including agile methodologies, though the details vary considerably from one methodology to the next.

Functional design as defined here includes both requirements analysis and the design of the external interfaces through which the system’s required functions are realized. Because these activities are tightly coupled, they belong to the same discipline.

Another activity that is tightly coupled with the conception of a system’s required functions and its user interface is acceptance testing. Clearly, it is up to the functional designers of a system to verify that what is constructed is what was conceived. So acceptance testing as a function fits into the functional design discipline.

It is fairly non-controversial to separate out the activities of functional design into their own roles, such as product manager, GUI designer, and acceptance tester. The main point of departure here from established mainstream practice is to organize acceptance testing under the functional design discipline.

Construction versus Engineering R&D

In most other technical fields, there is a fairly clear line between engineering R&D and the production of the end product. In software, this line is blurred. Nevertheless, there are compelling reasons, I believe, to consider differentiating between these activities in our teams. To recap, engineering R&D has to do with figuring out feasible approaches to implementing the functions of a system; and construction has to do with building robust working systems.

Engineering R&D can easily be mistaken for what we have come to know as design, which reminds us of the outdated waterfall-era separation of design and coding. In fact, engineering R&D does involve design, of course, but also much coding to try out ideas, prototype, simulate, benchmark, and so on. Similarly, construction involves coding, of course, but also much design to model the domain, to minimize coupling and maximize cohesion, to design for testability, and so on.

The distinction between engineering R&D and construction leads to the roles of R&D engineer and designer/builder.

Engineering R&D per se is not a phase. It is a type of function performed in software development. This type of function may be correlated with stages of development. But that is a different topic for a different day.

In my mind, the principle reason for differentiating engineering R&D and construction is that they each run on a different clock. Engineering R&D is experimental and uncertain in its outcome. R&D schedules need to tolerate a large degree of uncertainty and failure. In contrast, construction work is less risky. Construction is generally amenable to more systematic and accurate estimation. And management has much stricter expectations of timeliness and success from construction work than from engineering R&D.

Alan Cooper made this type of distinction a number of years back between what he calls engineers and programmers. He argues that these two types of practitioners need certain distinct sensibilities, and that it is probably easier to find world-class people in each of these areas, than people who are world-class in both. At the risk of oversimplification, one might say that, while there is considerable overlap between the two disciplines, R&D engineers gravitate towards the challenges of problem solving, while builders gravitate towards the challenges of creative craftsmanship to make real working systems.

Be that as it may, the fact that engineering R&D and construction each has its own pace, alone, I think, motivates an R&D engineer role in our teams. The R&D engineer is relatively free of the intense demands of building production code under aggressive schedule pressure, and can spend time researching high-value/high-risk ideas, and alternative solutions to the non-obvious requirements of the system. Of course, people need not be typecast into the roles of R&D engineer or designer/builder. One can certainly move between the two.

For many vertical applications, the ratio of R&D engineers to designer/builders would be small. I consider the role of the traditional hands-on software architect as an engineering R&D role. And in some projects, the architect may be the sole R&D engineer.

Summary

Here is a summary the basic roles motivated by this world-view.

Each basic discipline has a lead, or coordinator. The coordinator of the functional design discipline is the product manager. The coordinator of the engineering discipline is the traditional hands-on architect. And the coordinator of the construction discipline is the master builder, the supervisor on the ground with ultimate responsibility for the construction of the production system. All team roles report to a single team lead with ultimate responsibility for all team functions. The team lead is in easy access for escalation and resolution of issues between the different disciplines.

It goes without saying that roles are open: actively seeking feedback and collaboration from other roles and other disciplines. Also, of course, the same individual may play more than one role at any given time.

© Copyright 2006 Bolour Computing.