Designing Agile Teams Using Socio-Technical Systems

One of the core aspects of Scrum is self-organizing teams that deliver software in small iterations called sprints. For those that try to move from traditional development models to Agile, one of the major challenges is forming self-organizing teams. The sprint teams are truly cross-functional teams that choose the best way to do their work without being directed by others from outside. How does such a team differ from the project teams in the traditional models? Are there any design principles or theoretical frameworks that can help us go about forming such teams?

Designing Agile Teams using Socio-technical Systems Theory

One of the core aspects of Scrum is self-organizing teams that deliver software in small iterations called sprints. For those that try to move from traditional development models to Agile, one of the major challenges is forming self-organizing teams. The sprint teams are truly cross-functional teams that choose the best way to do their work without being directed by others from outside. How does such a team differ from the project teams in the traditional models? Are there any design principles or theoretical frameworks that can help us go about forming such teams?

Self-organizing teams versus traditional development teams

Agile/Scrum teams	Non-Agile/non-Scrum teams
Teams are self-organizing.	Teams are directed and managed by a manager.
Teams are cross-functional, with all the skills necessary for delivering a product increment.	Teams contain sub-teams that have specific skill sets. Each person specializes in a particular skill area such as designing, programming, testing, etc.
All the team members are called developers, regardless of the work done.	There are specific titles, such as programmer, senior programmer, project manager, tester, designer, etc.
The recommended team size is +/-7.	There is no recommended size for the team.
There is no manager who leads the team from the front; there is a ScrumMaster who helps the team function smoothly.	There is a manager, who directs and leads the team from the front.
All functions for the iterative development -- namely, planning, estimating, design, coding, testing, release, and customer collaboration -- are done by the team.	Planning functions are performed by the manager. Design, coding, and testing are done by the team members with specific skill sets for each. Releases are done by a separate team.
Knowledge and power are located anywhere, creating their own center of authority.	Knowledge and power are assumed to be located at the top.
Responsibility and attachment are shared as a whole within the team.	Responsibility and commitment are attached only to a single job.

The table above lists some of the major differences between the structures and functioning of Scrum teams versus traditional development teams. The traditional model is characterized by a strong hierarchical structure, where the control is centralized. The Agile team model has an almost flat structure; control is distributed rather than centered in one role.

This does not mean that Agile teams don't need leadership. On the contrary, Agile teams need strong, facilitative leadership to help them function at high performance levels. In the hierarchical, centralized team model, the design of the team structure is specialized by functions and tasks (designing, coding, etc.), while control and power is externalized and dependent on formalized and standardized processes. In self-organizing teams, what would be the desired design for team structure and control? If such teams are meant to be more "open" for customer collaboration and adaptive to environmental changes, what are the design criteria one should apply? How can the team regulate itself and make decisions concerning its own work arrangements?

Socio-technical systems

Socio–technical systems theory evolved as a response to the postwar industrial situation in the 1930s. Developed in the Tavistock Institute of Human Relations in London, this body of theoretical and empirical work seeks to improve productivity and human enrichment by focusing on the interdependencies between people, technology, and environment. A definitive outcome of this theory is the development of self-regulating work groups.

Socio-technical systems theory defines work systems as having both technical and social subsystems. A technical subsystem concerns the tools and processes that are needed to create products and services. The social subsystem concerns the work structure that relates people to the technical subsystem and to each other.

Let us look at some of the core design concepts of socio-technical systems and how they can be applied to design self-organizing teams in Agile:

Unit of design

The main unit of job design is the work group rather than the individual.

A work group is created when there is a high level of interdependency between tasks and individuals. In software development, individuals need to share information and perform interdependent tasks that are required to achieve a common goal. A typical software development lifecycle consists of requirements-gathering, design, coding, testing, and release. The tasks of each phase have dependencies on the tasks and outcomes of the previous phases. Not only that, but we know that in practice, the development lifecycle is not strictly linear. As an example, design may undergo a change as a result of discovering a defect in coding. Similarly, some new requirements may get added during the coding phase.

This makes the tasks and the members in a development team highly interdependent. This also means that the whole team needs to work in a collaborative environment. Therefore, the unit of work design becomes the whole work group and not the individuals in the work group.

In traditional development environments, even though project teams are an integral component, many aspects of work design seem to revolve around the individuals. It is done in such a way that individuals in the group could be replaced by other individuals. For example, the job descriptions are written for individual roles and describe in some detail what an individual has to do in that role. These job descriptions do not recognize the interdependency of roles and tasks. Similarly, training is offered mostly to individuals, on specific skills. Rewards and incentives are made to the individual based solely on his or her performance. By not recognizing that the tasks and individuals are interdependent on each other, all this creates a fundamental incongruence between the actual work design and team performance.

Locus of control

One important objective of any work system design is to reduce variance from the goals by dealing with uncertainties (risks) effectively. The socio-technical systems theory suggests that this be done by placing the locus of control closer to the source of uncertainties. The reason for this will become obvious if we look at the sources of uncertainties.

There are two major sources of uncertainty. One is the task environment, from which arise changes that are not always predictable. For example, can the project team predict the rate and nature of changes coming from the customer? The second source is related to the technological conversion of customer requirements to products and services. Examples are uncertainties arising from new technology or the unavailability of skilled personnel.

In software development environments, the development team, being part of the task environment and doing the technological conversion, should become the locus of control to deal with uncertainties.

With both these sources, when the levels of uncertainty is high (say, a highly complex development system, where the customer requirements are changing constantly or the technology is very new), external controls such as a supervisory function or standardization becomes ineffective. A control mechanism is best implemented by the group itself, which is closer to the source of uncertainty.

In traditional development environments, managing risks is assumed as the sole responsibility of the project management team. Though the project manager has an important role to play in managing risks, in Agile environments we have seen that it is the team that deals with uncertainties by making decisions on several aspects of software development -- deciding what functionality should be implemented, how much effort the team will/should spend, what software development processes need to be used, etc.

Since Agile teams should collaborate directly with the customer, they are closer to the uncertainties and risks arising from the customer's environment and therefore are much better placed to avoid variances from the goal.

Conditions for self-organizing teams

Having looked at the two primary focuses of the work group design of self-regulated groups, let us look at the conditions that need to exist for creating such groups. Understanding these conditions will help organizations design such teams with fewer chances of failure.

There are three conditions that have to exist for a self-organizing group to be viable:

1.       Task differentiation

2.       Boundary control

3.       Task control

It is important to note here that the extent to which a group is self-regulating depends on the degree to which these three conditions are met.

1.       Task differentiation: The extent to which a group's task is autonomous, forming a self-completing whole. Binds interdependent tasks into a common unit. The more autonomous the task, the more differentiated the group's boundary from other units. Technical variances are contained within the unit's boundaries rather than being exported across them.

2.       Boundary control: A well-defined work area that individuals can identify as their own territory; members who possess an adequate repertoire of skills that frees them from depending on the external environment for task accomplishment; group responsibility for boundary-control decisions, such as quality control, which reduces dependence on external regulators. Allows members to have discretion over their task boundaries, limiting external intrusion and ensuring autonomy. A supervisor helps with transactions across boundaries between different units.

3.       Task control: The choice that the group has in deciding what tools and methods to accomplish the work; influence over group goals to adjust them to match the emergent needs of the environment; feedback on the group performance to correct deviations from goals.

Let us now look closely at each of these conditions as they apply to Agile teams.

1.       Task differentiation: Earlier in this article, we saw that the work design of socio-technical systems includes a relatively complete task. This condition indicates that for a group to be self-organizing, its tasks need to be sufficiently differentiated from the tasks being carried out by other teams. The tasks have to be defined in such a way that the team will have less dependency on outside resources and more autonomy to carry them out. (One way to contain the impact of variance against goals is to have sufficient task differentiation). This also ensures that the impact of variances against the goals is contained within the team.

In Agile teams, task differentiation is achieved by defining a complete set of tasks that are needed for a delivery. This typically includes requirements analysis, design, coding, and testing and release. The team does not have to depend on external resources to complete the delivery. It is worthwhile to note that the extent to which task differentiation is achieved determines to the extent the group achieves self-organization.

2.       Boundary control: A self-organizing team has to manage itself by simultaneously differentiating itself and at the same time coordinating with the rest of the organization. While coordinating with other departments and other teams, the team has to decide what information to share and how, negotiate for resources, make decisions on who will do what work, etc. The team should be able to negotiate the transactions with the task environment. For example, if there is a quality control department for the organization, the team (along with the department) has to make a decision on who will do which part of quality control for products the team is delivering. For effective boundary control, individual members should possess multiple skills to reduce dependency on external teams.

In traditional development environments, one finds that the responsibility for decisions on boundary control for a team normally rests with the project manager. In contrast, if Agile teams want to achieve a fair degree of autonomy, the decisions and processes for coordinating within the boundary have to be left with the team.

3.       Task control: Apart from the choice in deciding on the work methods and tools, task control also implies that the team is able to influence the goals (deliverables) and modify the productivity of the team based on emergent situations.

In traditional development environments, task control mostly rests with the project manager. In many organizations we also find that the team's processes and tools are decided at the organizational level through standardization. One of the key enablers for team autonomy is the availability of direct feedback on performance-related measures. This information will help the team modify the goals related to production. For example, for Agile teams, this kind of information will help them better plan for sprint cycles and improve velocity and collaboration, both within the team as well as with the customer.

As noted above, the extent to which a group is self-organized depends on the degree to which each of these conditions is met. At the same time, it is important to note that any one condition that is overplayed may lead to a group formation that is too rigid for a self-organized group. For example, too much task differentiation may lead to such high group cohesion that members may reduce their openness to task-related inputs, such as performance feedback and managerial support.

Hackman and Oldham's theory of job design can be used as another approach to verify whether the socio-technical work design is really high on job enrichment for its group members. When work content is high on core job characteristics, such as skill variety, task identity, autonomy, and feedback, outcomes such as job satisfaction and work effectiveness result. These two theories reveal that work variables can be designed to contribute to both motivation and self-regulation.

Reference
Cummings Thomas G. Self-Regulating Work Groups: A Socio-Technical Synthesis. The Academy of Management Review. 1978; vol. 3, no. 3:625-634.