Efficient Collaboration Within Agile Methods
Mar 13, 2015
Our ongoing series of blogs about Agile methods offers an in-depth discussion of the method and its impact on an organization. In this blog, we focus on collaboration in agile teams.
Most people think of Scrum when they talk about collaboration within Agile. Scrum has definitely been a major contributing factor that has led to more effective collaboration. Note that we refer to it as just a contributing factor; Scrum has a strong emphasis on the pragmatic aspects, and less on human factors. In this blog, we aim to highlight the connection between both factors within Agile.
Agile is based on the idea of iterative and collaborative software development within a clearly established time frame. These iterations are called ’sprints’ in Scrum, the most popular Agile methodology. Many organizations apply the Scrum framework because it is relatively straightforward, and avoids overhead. At the core of a Scrum organization is a multi-functional and self-governing team. Every team member is involved with planning, exposing blockages, and the distribution of tasks. The Scrum methodology assumes that all the required knowledge is available within the team, which is reflected in the idea of multi-functional and self-governing teams. In this way, Agile methods are radically different from classical ‘waterfall’ methods with their linear, top-down approach based on division of labor and ‘big design up-front’.
Agile software development happens in teams with a focus on value streams . This is rather different from classic project management approaches (which are a major source of IT failures, as we argued in another blog). Teams establish their own well-defined goals for each sprint, or sometimes even for the day. Goals are attainable and realistic, because the team members themselves divide the work in manageable parts, and provide their own estimates on how long these tasks will take. Thanks to the inherent flexibility, the pragmatic approach, and the focus on the tasks, the team members all work together towards a common goal. Within each Scrum team, there are a few well-defined roles: the product owner, the Scrum master and the team members.
Many organizations praise agile methods because of the increased productivity of their teams. This is true if and when the methodology is applied correctly within each team. What we see all too often is that many organizations that apply the methodology pay little attention to human factors within the team, such as trust, motivation, transparency, team spirit, etc.
According to Scrum, any team that pays attention to planning, backlog grooming (a meeting to prioritize user stories), roles, responsibilities, goals, et cetera, will work together effectively as a team. An important issue, however, is that in the absence of mutual trust, little progress will be made. The success of a team does not merely depend on the rational application of the methodology, but also needs to take human factors into consideration. A team could execute the rational aspect of Scrum to perfection, but ultimately, humans need to do the work, so paying attention to these human factors is of equal importance.
Human factors
So what do we mean exactly by these “human factors”? Think about honesty, trust, the balance between the individuality of a team member vs. the team as a unit, courage, guts, leadership, development, learning from mistakes, change management, motivation, peer pressure, et cetera. All of these things will be experienced differently from team member to team member, and will have an impact on the success of the team. These human factors are absolutely critical for a successful Agile implementation. Experience teaches us that within the Agile framework, it is paramount to pay attention to and stimulate collaboration, constructive criticism, and continuous improvement, to ensure successful collaboration from sprint to sprint.
Agile teams typically consist of a number of professionals who contribute towards the end result from the perspective of their own individual knowledge and skills. These professionals are expected to exhibit an open and engaged involvement, which would naturally imply that they excel at collaborating in a team setting. Each professional needs to have the required space and flexibility within the structured environment. When a professional does not have the required space, he or she is not able to use his or her knowledge and capabilities in an optimal way. This reflects badly on the individual contributor and the visibility of the contributions. Many team members/ professionals struggle with this. It is a common challenge for many agile teams.
Within an agile setting, the team itself receives a lot of attention. Agile teams are established and team members are assigned to the team based on the required knowledge, skills and experience. After that, work is distributed among various teams and team members, along with specific goals. The whole team is established and defined, but sometimes team members may not trust one another due to misconceptions, bad experiences with a colleague in the past, anxiety, et cetera. Thus, team members may work as individuals and not as a team which affects the performance of the team as a whole. Often, a lot of attention is paid to the structure of the teams but not as much to what happens within those teams. This is at least as important in terms of success and results as the team structure itself.
From these examples, it becomes clear that a successful agile implementation does not just depend on establishing the right structure. Human factors play an important role as well. The Scrum master is vital in improving human interaction and to guide the team in applying good practices. He or she can do so by helping the team to establish a few golden rules. For example: dare to share, as early and frequently as possible. This serves as a contract between team members, which will stimulate collaboration. Moreover, the internal communication about the golden rules within the team is important. Team members need the space to talk about their fears and mistakes in team meetings. The golden rules are a tool to help the team members and Scrum master to facilitate these kind of sessions. This is an ideal way for the team members to become better acquainted with the Scrum method.
Another key task within the team is providing feedback, and newly established teams need to practice this. This will grant team members an opportunity to share their personal stories and opinions. An open and trusting environment is created in which team members will feel free to discuss improvement issues. The Scrum master may also need to coach some team members individually in giving feedback. For example, when they are restrained in giving feedback or too critical towards colleagues.
Agile methods more than traditional methods require cooperation, trust, taking responsibility and discipline. The team members together are responsible for the overall result. As an individual member, you cannot simply throw your part of the result over the fence to another member. Developers who prefer to work alone, may therefore perform less well in an agile team. Evasive or solitary behavior is fatal to such a team.
This need for open and clear communication is one of the reasons that agile teams cannot be too large. You need personal communication and that works best for a team size of at most 7 to 10 people. The role of the Scrum Master is to guide the team in establishing such a team-focused culture. This is one of the crucial ‘soft’ factors in the success (or failure) of an agile team, especially with inexperienced teams.
In this blog’s introduction we highlighted how the Scrum method provides structure and shapes a project-based team. A successful Agile environment not only depends on formal aspects (planning, setting targets, etc.), but it is also key to take into account the human factors within a team. Bringing together formal aspects and human factors within software development will allow the organization to optimally work Agile. In practice, however, this is hardly the case.
In future blogs in this series, we want to discuss the use of agile methods in the context of large, IT-intensive organizations with complex business process and system landscapes. In such a context, relationships between portfolio management, enterprise architecture, business process design and agile development become increasingly important. However, there are various tensions between these disciplines, on the one hand in matching their differing rhythms and cycles, and on the other hand, perhaps more importantly, in their cultural differences.
Please don’t hesitate to share your experiences with and opinions about working within an Agile team!
