Fostering Team Dynamics using Scrum for WFH Period

Photo by Marvin Meyer on Unsplash

As of March 2021, restrictions are still in place for crowd-inducing activities in an effort to reduce COVID-19 transmission. As a consequence, most workers today, including software developers, have no other choice but working from home (WFH). Some may be able to adjust to this new work environment or even prefer it, but some others may not. Since this environment migration is involuntary for some people, team dynamics is one of the most urgent things to maintain to ensure that the team still functions and everyone can adapt well to this new work environment. We will be looking at the Scrum methodology, how it fits into this work environment, and tips on how to effectively participate in an agile environment.

Agility in Software Development

Agility in software development usually follows the Agile Manifesto and its 12 Principles. In a nutshell, it states that the development team should be able to welcome and honor changes to the development process and continuously producing deliverables to the customers. Therefore, it requires the team to be “agile” by easily adapting to changes and keeping the development process running. This is in line with the most critical variable in a software development process: changes.

Changes to a software development process may come in many forms. The most significant of them is changes to the software requirements itself. Software that is designed to be used long-term will constantly face the need to incorporate changes due to change in market demand, user demographics, etc. The following chart shows the progression of software over time:

Photo by Software Engineering Hub

In an ideal environment (shown by the idealized curve) where requirements does not change, software failure rate should always decrease over time as long as a comprehensive quality assurance mechanism is in place. However, this is not the case with most software where requirement changes are likely to happen. Every time a change is introduced, new sets of failures will emerge as a burst which needs addressing. In the long run, the failure rate will steadily increase (shown in the actual curve) to a certain point where the failure rate is too high for the software to be used further. This is called software obsolescence and its onset may be accelerated due to various reasons such as:

1. The software fails to incorporate requirement changes from the customers so the customers lose faith in the software.
2. The software is developed in such a way that hinders adaptability and ease of change.

In addition to changes in the requirements itself, changes to the development environment also plays a part in the agility problem. Some scenarios regarding environmental changes which also needs attention are:

1. A software designed for long-term use needs to be maintained for extended periods which introduces a high possibility of changes in the development team’s human resource.
2. Extraordinary conditions such as the COVID-19 pandemic and the subsequent WFH movement introduces new challenges for existing teams to be able to maintain team dynamics.

Development teams must be able to adjust themselves to the conditions imposed by the above issues in order to maintain agility and the ability to deliver working software to its customers.

Agility Case Study: Evolving Requirements

This case study is based on the development of Crowd+ software by Nice PeoPLe team.

As stated in the previous section, it is very hard to be able to obtain a concrete and holistic requirements list in a software. Initial requirements will usually construct a general outline of the software’s expected functions and more items will be added in the later stages by observing the initial results and closely observing the software’s intended market.

In the case of Crowd+, such sequence of events actually happen to some of the requirements. Initially, an annotation project owner only has the power to approve annotator candidates to their projects. However, after deliberations, it seems that the project owner must also be able to revoke the approval of an annotator (read: kicking out an annotator). This requirement is not identified in the initial stages but is able to be incorporated in the next version of the Product Requirements Document (PRD).

Changes in requirements can also be invoked during prototyping. Initially, an annotation project’s “short view” includes the number of questions in that project and the payment rate for each question answered. After seeing the prototype, it is decided that separating these two attributes is “not appealing enough” for annotator candidates which seeks to gauge their potential income for each project. This view is then changed so that it prioritizes the display of the annotator’s potential income. This change in requirements may seem small but can have significant consequences, both in terms of the development work and the user’s experience in the software.

Implementing Scrum

Scrum is one of the frameworks that are commonly used to develop an agile development team environment. It focuses on breaking down the development process into several increments (called sprints) and welcoming requirements changes between the sprints. At its core, a Scrum framework mandates the following set of activities:

1. Sprint Planning
2. Sprint Daily Meeting
3. Sprint Review
4. Sprint Retrospective

Sprint Planning

This activity is done at the beginning of every sprint and is used to plan the upcoming sprint’s goals and activities. This activity is usually preceded by a backlog grooming process in which requirements are gathered and analyzed to be considered in sprint planning. In this activity, the Scrum team members gather and go through several important agenda in a sprint planning scenario, which includes:

1. Going through the available backlogs from the grooming process and evaluating their user stories and acceptance criteria.
2. Assigning weighted score (story points) to each backlog according to the perceived weight of the backlog according to the opinion of the parties involved. A commonly used scoring system is the Fibonacci scale which is usually used to gauge the expected development time of the backlog.
3. By limiting the number of story points for each sprint, the team can select the backlogs that will be done in that sprint. Backlogs that do not pass this selection will be saved for the next sprints.
4. At this point, the selected backlogs will have their requirements frozen for the duration of the sprint in order to provide security for the developers.

Sprint Daily Meeting

After the sprint planning activity is complete, the team will enter a sprint period (can be between 1 week to 1 month according to the needs of the team). During the sprint period, the team is encouraged to hold regular meetings to discuss the progress in that sprint. In order to ensure that the meeting is effective, some rules of thumb are followed:

1. Daily meeting should be held routinely and lasts no more than 30 minutes.
2. Every member should document their progress to be reported in the meeting.
3. Every member should speak up about difficulties faced during the process so that the solution may be discussed together.

A sprint’s progress is documented through a scrum board. The board divides the backlogs for the software development to several stages. Examples of such stages include not started (the backlog has yet to be implemented), in progress (the backlog is being implemented), and done (the backlog’s implementation is finished). Scrum team members are required to update this board regularly by moving the backlog’s position to its current stage.

Scrum Board example from the development of Crowd+ software by Nice PeoPLe team

This board is the primary asynchronous method of communication between team members in which everyone can monitor each other’s progress. This board will also be used in daily meetings as a form of progress report.

Sprint Review

A sprint review is conducted at the end of every sprint to evaluate the implementation of backlogs in that sprint. The software’s client are invited to this activity and a demonstration of the backlogs will be conducted. In the sprint review, the client (usually through the Product Owner) can then choose to accept or reject the backlog’s implementation. A rejection is usually caused by less-than-expected results or evolving requirements. Therefore, the backlog will usually return in the next sprint, incorporating the changes identified during this review process.

Sprint Retrospective

The highlight of a sprint retrospective is to evaluate the performance of a sprint. This is usually unrelated to the actual product and more focused towards the team’s performance. This activity is important to incorporate opportunities for improvement in the next sprint and team members are encouraged to speak up and give solutions on problems identified during the sprint.

Team Dynamics, Scrum, and WFH

Scrum is a flexible framework and can be implemented regardless of whether the team is co-located in an office or operating remotely from different places around the world. Development of technologies such as video conferencing and version control services has made online teamwork easier. This is especially true during the mass WFH movement due to the COVID-19 pandemic. However, there are still some problems associated with remote working as shown below:

1. Operating from different locations mean that every member of the team face different challenges. For example, members may operate on different time zones which limits the time window available for synchronous meetings.
2. Some people consider communication which is not done through co-location to be more difficult, especially if asynchronous methods must be used.
3. Remote working may reduce opportunities for team bonding activities which is essential to maintain team dynamics.

By using the Scrum framework, some communication-related problems are alleviated by encouraging routine meetings and constant reporting through the scrum board. However, active participation from every team members are still required to successfully implement the framework, especially in the case of involuntary WFH scenarios.

Here are some things that a Scrum team member can do to improve individual participation and overall team dynamics:

Encouraging Team Bonding Activities

While most Scrum synchronous activities are designed to be short in terms of time, this only covers activities related to the actual activities as mandated by the Scrum framework itself. Since a synchronous schedule is precious and it is more difficult to agree upon multiple meeting schedules, adapting existing meeting schedule by adding team bonding activities or leisure activities are likely to increase the team’s morale and encourages the team to build relations towards other team members. Morale is important to ensure that every team member can continue working.

For example, should the team agree upon the activity, a Scrum daily meeting schedule can also include team games or other activities outside the Scrum framework. A dedicated leisure period can also be enforced to ensure that team members have adequate rest period during the sprint. At minimum, work-life balance should be encouraged among team members.

Developing Richer Scrum Boards

Scrum boards are initially implemented physically in actual boards where backlogs are usually placed on the board using sticky notes. This limits the amount of information that can fit into the sticky note paper. Some strategies may be implemented to add information such as color coding to identify assignments, but there are still hard limits. Digital scrum boards are free from this limitation and most services do encourage rich information in Scrum boards.

For example, GitHub and GitLab both provide some form of boards that are associated to a particular repository or a group of repositories. This board can be configure to Scrum’s standards and each entries (associated to Scrum backlogs) can be loaded with information such as:

1. Assignee
2. Milestones
3. Story Points
4. Due Date

Example of a Scrum Board entry in a GitLab Issues Board for Crowd+ software development. Note that specialized fields (such as milestone, due date, etc.) are provided to enrich the board entry.

Trivial Things

Beyond professional life, every team member is an ordinary human being. Understanding each other’s condition and helping those in need may be trivial but is important to maintain team dynamics. A “grow together” mindset must be implemented in the development environment since everyone is working towards a common goal (developing a usable product) and collaboration paves the way towards this common goal.

In the team bonding activities section, we have discussed about the effects of team morale towards the development environment. More trivial things are actually available to boost each others’ morale by appearing “more human” while maintaining professionalism. Things as simple doing personal favors for other team members are able to boost trust within the team and developing a sense of comfort and belonging in the team which in turn boosts morale.

Key Takeaways

1. Changes will always exist in software development, whether it relates to the software’s requirements and expectations or relates to the development environment itself.
2. Agility is an integral part of software development to maintain software usability in the long run.
3. Scrum framework is a flexible implementation of the Agile methodology that can be adapted for use regardless of team co-location.
4. In order to successfully implement the Scrum framework, active participation from all team members are required.
5. Every team members can and should contribute to improving the working environment for themselves and for the team.