GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.

How would the attitude and productivity of your software developers improve if they not only had a say in how they worked, but who they worked with?

Over the past twenty years, the software industry has moved from a rigid, top-down, waterfall approach to agile, empowered, self-organizing teams. Additionally, the past ten years have introduced new norms about remote work, redefining expectations about where and when programmers work.

Today developers have unprecedented freedom and autonomy, resulting in increased satisfaction, productivity, and responsiveness to shifting business needs. They have come to expect this flexibility, and astute managers look for new ways to keep developers engaged, understanding that happiness improves job-performance, satisfaction, and quality.

The next step in workplace (r)evolution

Agile development teams embrace the values of self-organization, continuous improvement, and decentralized leadership. Often the entire team is involved with planning, project estimation, and process improvement, allowing everyone to collaborate on how work is performed.

Most agile teams already use a pull strategy rather than push strategy for assigning work. Instead of managers pushing a task to a particular programmer, programmers pull their next task from a pre-approved list. This is in line with the values of giving developers as much control of their work as possible.

In short, modern developers enjoy a great deal of autonomy about...

• how they work
• where they work
• when they work
• what tasks they work on

Yet, today, most agile teams are still formed by management.

Self-forming teams are the next step in the agile transformation, allowing developers to decide whom they work alongside.

Self-forming teams are teams where members decide who they wish to work with to accomplish a task, project, or goal.

Rather than the traditional role of appointing people to teams, managers facilitate the creation of these teams through structured activities. This is similar to how managers might facilitate team improvement through a structured retrospective activity or help the team estimate using a planning-poker exercise.

The benefits of self-forming teams

On self-forming teams, roles are often more fluid, allowing for improved innovation and collaboration, which are often emergent attributes. The team may elect to have no formal roles, instead leveraging the skills of everyone on the team to accomplish the goal. This reduces one common reason many developers leave their jobs: they become bored performing only one type of work. When roles are fluid, team members may engage all their skills, ideas, and expertise without concern that something “is not their job.”

Leadership may also be passed around the group, to whoever knows the next thing to do (dynamic subordination). Or, groups may choose to rotate leadership periodically, allowing everyone a chance to perform specific administrative tasks (status reports, meeting with customers, etc.)

Team members are also often more aware of their strengths and their weaknesses than their managers are, as people tend to hide their weaknesses. Self-forming groups may create an environment where people feel safer and thus more able to improve, learn, grow, and contribute. Also, because everyone wants to be a part of the team, they are motivated to address internal problems and take responsibility for team health.

Millenials, who represent 54% of working software engineers entering the workforce, prioritize peer-relationships. Among millennials, friendships in the workplace make them feel happy (57%), motivated (50%), and productive (39%)

Allowing developers to choose whom they work with is an untapped source of motivation and productivity that companies should be wary of ignoring.

Start with small experiments

However, self-forming teams don’t necessarily come easily, and they are often far afield of the “normal” office structure. Managers who are considering self-forming teams would be wise to begin with small experiments.

This article includes a downloadable workbook that can be used to quickly introduce teams to the experience of self-forming teams in a safe, low-pressure environment.

These exercises allow team members to:

• Experience self-forming teams in a professional, agile environment,
• Discuss what they have to offer team members, and what they seek in return,
• Consider how their strengths and weaknesses play into their decisions,
• Discuss what criteria could be used for forming teams, and
• Discuss ideas and preferences for leadership methods.

After performing the exercises in the workbook, use the questions in the workbook to facilitate a team discussion to gather ideas for another experiment. This could include prototype projects, swarming or mobbing on a feature, forming short-lived teams (from a single day to an entire iteration), or many other types of experiments. Allow your team to propose and conduct new experiments to learn more, and guide them through learning the skills and attitudes that lead to success.

→ Download the Self-Forming Teams Workbook

Conclusion

Self-forming teams are a logical extension of self-organizing agile teams, as described by the Agile Principles and Scrum. Increased developer happiness is directly tied to higher productivity and lower turnover, reducing the cost of these highly compensated employees. Managers should introduce these ideas to the team through small experiments and they should work closely with their teams to understand how self-forming teams could fit into their company's unique culture, values, and environment.