Agile principles: Team

After the topics of customer satisfaction and change vs product design, we continue our series on interpreting Agile principles with the question of teams.

When the Agile principles emerged, many product development teams were operating as much looser units and with much less autonomy than the principles advised. In this article, we explore why Agile puts so much emphasis on teams. We also examine the apparent contradiction between the emphasis on the role of teams and the prominence given to individuals and individual motivations in the manifesto.

Self-organisation

According to the eleventh principle of the Agile Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams.” The interpretation of the principle should start with a clarification of the concept of self-organization. Two of the most common misinterpretations of self-organization can be seen as two ends of a scale: one end is complete, uncontrolled freedom, the other is complete control of the team’s decisions and activities by a designated or self-proclaimed ‘leader’ within the team. Both extremes are far from genuine self-organisation.

Clear boundaries

One of the most important prerequisites for successful self-organisation is a clear understanding of the boundaries. What are the boundaries beyond which the team needs external information, help and decisions, but within which they really have complete freedom? A product development team designing a solar panel, for example, may have an internal decision on the choice of components to use, but they may also need to involve external experts (lawyers, procurement, etc.) to complete supplier contracts and price negotiations.

Although agility does not give specific, explicit hints on where these boundaries should be drawn, one aspect is certain: the distribution of tasks within the team should be entirely a matter of internal team decision making. The team, and only the team, decides which part of the assignment is carried out by which team member(s). This takes micro-management completely outside the Agile management toolbox.

Leaders within the team

In beginner teams, especially where there are significant differences in experience between team members, it is common for a senior colleague to become an implicit leader and “self-organise” the team, although he or she is not a dedicated leader. This phenomenon is equally detrimental to self-organisation and the success of the team.

The central idea of self-organisation is that more people have more perspectives, so naturally they can approach challenges and problems from more directions, and thus deliver more comprehensive, complete and thoughtful solutions. The self-proclaimed leader, however professional and experienced, has only one point of view. By suppressing the opinions of other team members, the team loses information and ideas, which ultimately results in a lower quality product. Imagine the editorial board of a political investigative magazine, where the veteran journalist tries to take all the decisions of the paper, treating his team members as mere executives. He has been in the business for a long time, so he has a lot of extra knowledge beyond his basic profession, he knows how to formulate certain assumptions so that they don’t cause legal issues, he has learned about editing and proofreading, and he even knows a little about printing and photography. But all his knowledge is inadequate when the magazine’s aim is to make up for its dwindling readership by appealing to young people. In this case, the importance of a young journalist’s knowledge suddenly becomes disproportionate to their professional experience.

Self-organisation does not mean that there is no leader within the team. Self-organisation means that there is no designated, permanent leader within the team. Different jobs may require different leadership knowledge, practice and attitudes. The team recognises this, so different team members take on the leadership of each assignment. It is also important to stress that leadership does not always require professional knowledge. It is possible that the least experienced member of a team can become one of the best leaders because he or she is disciplined, structured and a good organiser. And, of course, it is also possible that a given job may not require any leadership at all, it may just be “a matter of doing it”.

Team maturity

It’s easy to see that self-organisation is a real and powerful asset for a mature team: the team accurately assesses its own capabilities, is able to decide how much work it can do reliably and in how much time, divides the work among itself and even holds team members accountable for getting the job done. In addition, as the twelfth principle of the Manifesto states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

So not only does the team work well without outside interference, but they are also focused on constantly improving and improving their own operations. One of the basic tools for this is the retrospective technique known from the Scrum methodology.

A well-functioning self-organising team can free up a lot of energy for management, allowing them to focus on the issues that require real management skills, rather than the day-to-day minutiae. In this way, the self-organising team is not only more efficient in its own right, but can also indirectly increase the efficiency of the whole organisation. Yet the above description may seem too ideal, since the Manifesto only speaks of the destination, not the journey. How does a group of professionals, formerly individuals with individual responsibilities and strictly individual motivations, become a self-organising team? You can read more about this in our previous article or learn more in our Scrum Master training courses.

Individual or team?

The fifth principle is: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Even more confusing may be the first value pair of the Manifesto: “Individuals and interactions over processes and tools”.

So are they individuals or teams?

Fortunately, the apparent contradiction is easy to resolve, but it also hides an important message. It would be difficult to build a successful team of uninterested individuals, so the fifth principle, “Build projects around motivated individuals.”, is actually trivial. However, the sequel also points to a truth that, although it was stated at the birth of agility, its real recognition has taken a long time to come. In our previous article, Scrum versus individual development, career path, we talked about the unfortunately common Scrum implementation mistake that the team and team goals can become so important to the organisation that individual goals get lost. This can easily be at the expense of individual motivation. Although team goals are essential to building and maintaining a strong self-organising team, if the emphasis on team responsibility comes at the expense of individual responsibility and personal development, a team member may feel that they do not have enough control over their own success. So the answer to the individual or team question is both: build teams, but remember that teams are made up of individuals.

As for the first value-pair in the Manifesto, the word individual is not used as a counterpoint to team, but as the elementary and most important unit of communication. The main message of the value pair is that communication channels are not defined by set processes or an organisational chart, but by who is needed to solve a particular issue. In this way, the team should be represented in formal or informal meetings by whoever the team considers most appropriate. It is possible that three people on the team are experts on an issue, but two of them are working on a problem that cannot be done by others on the team, so the third is sent to represent the team. So adequacy is not just a question of knowledge, it also depends on other aspects, such as the consequences of a team member’s absence to attend a longer meeting for the job at hand.

The key to successful Agile product development is a well-functioning team. If you feel your team needs help, take a look at our Agile team solutions.