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