HASE – Human Aspects in Software Engineering

The model proposed by Hackman (1987) for the design and development of effective work teams is one of the most influential in the research about team work. Central to the model is the concept of task design as one of the conditions that support effort from team members. The task design concept postulates that a work group would “work especially hard on its tasks” when five conditions are met. One of these conditions is usually referred as task identify, defined by Hackman as follows:

“The group task is a whole an meaningful piece of work, with a visible outcome.” (Hacman, 1987, pp. 324)

In trying to use Hackman’s model in the design of tasks for software teams, one faces the problem of understanding the meaning of task identity in software development. Several alternatives to operationalize this concept in the software development would have distinct implications for task and team design.

First, and the most obvious, alternative is to consider that the development of a whole system. It certainly meets the criteria of task identify as a whole piece of work, meaningful and with a visible outcome. Some software teams in industry are responsible for the development of an entire system, but not all. In fact, it is more likely that the majority of the software teams in industry do not work on an entire system, but on parts of a system.

On the other end of a possible spectrum of task designs, is the case in which the development is broken in phases, each one assigned to specific teams. Coding and testing conducted by different teams are typical examples. One could argue that even in this case it is possible to have certain degree of task identity in each task, but this is certainly different from the first case. In this cases, it is more difficult for individuals or even teams to have an understanding of “the big picture.”

In the middle, there is the case in which a team is responsible for a part of the system, and performs all (or most of the) tasks associated with that part: design, coding, testing, maintenance, etc. Again, certain degree of identity exists that is “smaller” than the first case and “larger” than the second.

Aninteresting research problem is to understand the relationship between different types of task design and the motivation (or demotivation) these designs have on software engineering teams. In particular, it seems relevant to understand task identity in the context of agile and traditional development, as well as in the context of open source development. It is likely that in the three context the “levels” of identity will vary and, thus, the level of motivation that the task design will have on software engineers will also be different.

We are currently working on this problema and comments are welcome.

Fabio Silva.

Reference

Hackman J (1987) The design of work teams. Handbook of organizational behavior 315-342.