Why work in teams?

Overview

Teaching: 10 min
Exercises: 20 min

Questions

• What are the benefits of working in a team?

• What are downsides of working in a team?

Objectives

• Explain the benefits and downsides of working in a team

Introduction

In this episode we will learn about teams and discuss why you should want to work in a team in the first place. To define a team, it is useful to look at teams in a continuum and think about the difference between a team and just any group of people:

• Any gathering of people: they might not even know or see each other, nor necessarily share common interests.
• Groups: they are aware of each other and may interact, more than a simple gathering of people.
• Working group: a group with at least some common goals.
• Team: a group of people who act together to achieve common goals. Often, a group of individuals first form a working group. Then, they become a team. As opposed to working groups, teams have collective responsibility, leadership, and achievements. Read more about differences between working groups and teams here.

Discussion

Do you work in a working group or a team?

Scrum team

You might have heard of a Scrum team that includes people with different roles. We will learn about it in the episode Introduction to Scrum.

Why work in teams

Discussion

• What do you think are benefits of working in a team?
• What do you think are downsides of working in a team?

Solution

Benefits

• Boost creativity and idea generation
• Learn from each other
• Share the workload of hard complex tasks
• Make use of complementary strengths of employees
• Better decision making
• A review process (where co-workers review each others work) often works better in a team because team members are familiar with the shared work. This increases the quality of the work.
• Humans are highly social animals and in general thrive by regular interaction with others, increasing motivation and productivity
• Increase the bus factor (i.e. when someone falls under a bus, the team can take over)
• Projects do not go on hold when a single employee is away, the team is able to pick up the work
• Shared responsibility and ownership
• Have multiple perspectives on performance from different team members.

Downsides

• Overhead of team meetings, communication and management
• More likely to get into conflicts with colleagues
• Possibility for too much peer pressure or feeling of being overlooked
• Not everything is under your control, so sometimes you have to work on things you do not like or that are initiated by someone else
• Teams can form isolated silos within an organisations
• Harder to measure contribution of individual to team outputs (think about publishing papers)
• You need a set of soft skills to work together successfully, potentially disadvantaging people that have more difficulty to develop these skills
• Leadership issues: leading a team is a difficult skill, which, if practiced badly, can have negative influence on the team members’ work environment
• Differences in number of working hours or work pace can be magnified, which can lead to frustrations

There are many benefits of working in teams, but there are clearly also some downsides. The key is to work together in such a way that the advantages outweigh the disadvantages. An Agile way of working can help with this!

Key Points

• If done well, working in a team is fun and productive

Introduction to Agile

Overview

Teaching: 10 min
Exercises: 20 min

Questions

• What is ‘Agile’?

• Why should I work in an Agile way?

Objectives

• List drawbacks of Waterfall model

• Describe Agile Manifesto

• List benefits of following Agile manifesto

What is Agile?

The term ‘Agile’ refers to a broad family of software development methodologies. The core concepts linking these methodologies is iterative development, with frequent interaction between interested parties to decide and update requirements.

Is that all? Well, there is a bit more to it than this, but the best way to get a feel for Agile is to understand why it exists in the first place: it is a reaction to the type of ‘Waterfall’ methodology that was prevalent at the time. Let us first look at what ‘Waterfall’ means, to see the problems that Agile is trying to solve.

Waterfall model

Typically, many real-world (software development) projects are divided into different phases, where each phase depends on the output of the previous phase. We refer to this as the ‘waterfall model’, because each phase flows into the next phase like a waterfall:

The key is that there is a clear project timeline and agreed-upon deliverables at the beginning of the project. Learn more about the waterfall model here

Discussion

What do you think are potential drawbacks of the waterfall model?

Solution

• Less customer involvement (only in the beginning)
• Users usually only really know the requirements once they have working software, but then it is too late.
• Requirements change during development, these changes are not incorporated so the software does not do what the user needs.
• No way to know upfront what difficulties you might face
• Testing happens only at the very end
• Deadlines are often not met, in practice waterfall projects are delayed a lot
• Only at the very end of the project there is working software, if you do not reach the end you do not have working software.

Agile manifesto

The Agile way of working contrasts the Waterfall model and mitigates most of its drawbacks. Watch this video introducing the Agile manifesto.

Exercise

These are the 12 principles behind the Agile manifesto. Which of these resonates the most for you?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Discussion

Think about following the Agile manifesto when working on your projects in a team.

• What are benefits?
• What are downsides?

Solution

Benefits:

• Because the focus is on product quality, you will build better products
• By incorporating users/customers you bring more value to them.
• Because of iterative reflective process, the team process keeps on improving.
• Reduced risk of failing projects
• Very flexible, changes are introduced easily (normally this can be time-consuming)
• There is trust in the team and its self-organisation, which boosts morale of the team.
• By supporting motivated individuals and accommodating to what they need, they will keep motivated.

Downsides:

• Lack of clear structure can make it easy to get side-tracked.
• Because of incremental nature it is hard to say when something is done.
• You need a high level of collaboration that is hard to maintain.
• You need support from the management to do it effectively.

Summary: Why should I work in an Agile way?

Essentially, Agile works well for projects in which we do not know all the requirements in detail at the start, and in which requirements are likely to change during the course of the project. This is very likely the case in a research project, which naturally have many unknowns and the requirements of software can change as new information is collected. Both Agile and Waterfall are suitable for teams, but an Agile approach gives the team more power to adapt and organize itself.

In short: following the Agile principles helps teams to make the benefits of working in a team outweigh the downsides. See episode 6 for more on the challenges of applying Agile methods in research.

Disclaimer to comparison with waterfall model

It is good to note that the comparison of the Agile movement with the waterfall model is a bit artificial. Agile methodologies are often framed as the way of solving the pitfalls of the Waterfall model, but there have been modifications of the ‘pure’ waterfall model that accommodate these pitfalls too. In fact, they are not mutually exclusive and you could apply principle 12 by picking aspects from the Waterfall model to continuously improve your teams process.

Key Points

• The Agile manifesto provides good pointers for successfully working on software projects as a team

Introduction to Scrum

Overview

Teaching: 10 min
Exercises: 75 min

Questions

• What are the 3 key roles in a Scrum team?

• What are the different Scrum rituals?

• What are the Scrum artifacts?

Objectives

• Describe the 3 key roles in a Scrum team

• List the different Scrum rituals

• List the Scrum artifacts

One of the most popular methodologies that apply the Agile manifesto and principles is ‘Scrum’.

Exercise

To learn more about Scrum we follow this online course.

Please follow this ~1 hour course. It includes 3-8 minute video’s focusing on various Scrum topics, as well as accompanying exercises.

Discussion

Think about following the Scrum methodology when working on your projects in a team.

• What questions do you still have?
• Are there any incremental improvements that can benefit your team?
• What did you learn in the online course that you think is too much for your team?

The Scrum guide prescribes in the first chapter that one should either do Scrum completely, or not do Scrum:

Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

~ The Scrum Guide

Failure of a team doing Scrum is often blamed upon them not following the actual Scrum rules.

Discussion

Discuss with your team about the “all or nothing” statement in Scrum. Do you understand why it is there? Do you agree with this statement?

From experience we know that following the exact Scrum rules does not always fit a team well as the team might be bound by other restrictions. We will go deeper into the specific challenges that we run into when we want to do scientific research within a team (in episode 6). We will first discuss a different Agile implementation, called Kanban in the next episode.

Key Points

• Scrum is a powerful Agile methodology that demands an ‘all or nothing’ approach to work, but it is not a perfect fit for all teams.

Introduction to Kanban

Overview

Teaching: 15 min
Exercises: 30 min

Questions

• What is Kanban?

• What is a Kanban board?

• Can we combine Scrum and Kanban?

Objectives

• Describe the Kanban method

• Understand how to use a Kanban board

What is Kanban?

Kanban is a process management method. It balances demands with available capacity and improves the handling of bottlenecks. You can simply apply Kanban to your current process of developing software.

You may often hear that Kanban is a “pull” system. It means that a new work-item is pulled to the process as capacity permits. We will explain this in the next section where we introduce a Kanban board. Read more about Kanban here.

Did you know…

Kanban is the Japanese word for signboard or billboard.

What is a Kanban board?

A kanban board is a project management tool designed to visualize processes, define tasks, and manage backlog-items. It helps to show/record what, how and who aspects of a work-item and keep everyone on the same page. A Kanban board uses cards, columns, and continuous improvement to help teams commit to the right amount of work, and get it done!

Here is an example of a Kanban board created using GitHub project boards:

Cards

Team members divide the work into some work-items and write onto cards (stickies, or tickets), usually one per card. For Agile teams, each card could represent one user story. Once on the board, these cards help everyone understand what the team is working on.

Each card should also have “acceptance criteria” (AC). AC is a set of statements that define how a user story can be completed.

Who writes acceptance criteria

Generally speaking, the “Product Owner” defines the product backlog, and acceptance criteria (AC). However, it is a good practice if team members contribute to writing AC.

Columns

Columns together show the process or workflow. Each column represents a specific activity, for example “To Do”, “In Progress”, “Done”. Cards flow through the workflow until completion, i.e. from the left to the right side of the board.

• What if your team works on more than one project/product?

If your team works on several projects/products, you can add one row (Swim Lane) for each of them. As an alternative, your team may decide to have a time-boxed workflow and work on one project at a time, see the section “Combining Scrum and Kanban (Scrumban)” in this lesson.

More examples of Kanban workflows (i.e. columns)

• To Do, Doing, Done.
• To Do, In Progress, Review, Done.
• To Do, In Progress, Demo, Done.
• Committed, Analysed, In Progress, Done.
• Ready, Estimate, Development, Test, Done.

Continuous improvement

Continuous improvements can be achieved by three elements: Commitment point, Work In Progress (WIP) Limits, and Delivery point.

Commitment point

Teams often have a product (or project) backlog that includes some work-items. The commitment point is the moment when a work-item from backlog is picked up by the team. In other words, a card is moved from backlog to “To Do” column.

Product backlog

A product backlog is a prioritized list of work like a todo list that is derived from the project requirements and ideas. Read more about it here.

Work In Progress (WIP) limits

WIP limits are the maximum number of cards in “In Progress” column. For example, the column with a WIP limit=3 cannot have more than three cards in it.

• How to estimate WIP limits?

WIP limits is an estimation of how much work the team can commit to. So, it can vary depending on the team capacity and can be adjusted after a few trials.

• What if the “In Progress” column is “maxed-out”?

When the “In Progress” column is “maxed-out”, the team needs to check if some cards can be moved forward before adding new cards. If not, the team should inspect the problem. Sometimes, either the WIP limits or the amount of the work to commit in the current workflow need to be estimated again. Also, the team might re-visit the acceptance criteria of a work-item.

Delivery point

The delivery point is the end of a kanban workflow, i.e. all cards from “To Do” moved to “Done”. The team’s goal is to move cards from the commitment point to the delivery point as fast as possible.

Other Kanban boards

Have a look at the examples of Kanban workflow (mentioned above).

• Which of those can be used for the projects in your team?
• What other workflows, if any, are you implementing in your team?

Designing a Kanban board

Imagine that you are working on a project.

• Let’s create a Kanban board using GitHub project boards.
• Discuss the board with your colleagues.

Exercise

Imagine that you are working with a Kanban board. One of the work items in “In Progress” got blocked. The blocked item means that the team is not able to continue working on it because it is waiting for something from outside the team. How do you deal with the blocked item in the Kanban workflow?

Solution

The simplest but effective approach is to put a “red dot” on the item. In an online board, it is possible to add a tag/label and more information like why this item is blocked, for how long, and who will unblock it. This visualizes the situation. So, the team can immediately see that the item is blocked and have it under control. Now, the blocked item does not count as a WIP item and the team could potentially add an extra work-item to ‘In Progress’.

Summary

Kanban is great for processes focused on continuous delivery with changing priorities. On the other hand, Scrum divides work into a series of time-boxed iterations called sprints (see episode 3). But maybe a combination of Scrum and Kanban (known as “ScrumBan”) is what your team would benefit the most from. We will learn about it in the next lesson.

Discussion

Think about following the Kanban methodology when working on your projects in a team.

• What questions do you still have?
• Are there any incremental improvements that can benefit your team?
• What did you learn in the online course that you think is too much for your team?

Challenges specific to research projects will be discussed later, in episode 6.

Key Points

• Kanban consists of cards, columns, and continuous improvement.

• Main elements of continuous improvements: Commitment point, Work In Progress (WIP) Limits, and Delivery point.

Comparing Agile methodologies

Overview

Teaching: 5 min
Exercises: 20 min

Questions

• How do Scrum and Kanban relate to the Agile manifesto?

• What are differences between Scrum and Kanban?

• What are other Agile methodologies?

Objectives

• Explain the difference between Scrum and Kanban

• Know that Scrum and Kanban are both Agile

• Know that there are many other (less popular) methdologies

Scrum and Kanban are both Agile methodologies

Scrum and Kanban are both Agile methodologies. They both provide a set of practical tools that allow you to work according to the Agile manifesto and principles.

Exercise: Compare Scrum and Kanban with the Agile manifesto principles

Pick one or more principles from the 12 principles behind the Agile manifesto that we discussed in episode 2. Write down how Scrum and Kanban practically implement these principles.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Solution

Example solution for principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Kanban: Continuous delivery (release after every finished item)
• Scrum: Release after every sprint (for example every 2 weeks)

Differences between Scrum and Kanban

Exercise: key differences between Scrum and Kanban

See the following incomplete table:

Aspect	Scrum	Kanban
Release Methodology	At the end of each sprint	Continuous delivery
Cadance	A	B
Roles	C	D
Amount of work estimation	E	F
Change Philosophy	G	H
Meetings	I	J

It denotes the differences between Scrum and Kanban for 6 key aspects. The first row (Release Methodology) is filled. Your task is to fill the last 5 rows of the table. Use the following values to fill it:

1	Strict roles: Product owner, scrum master & development team
2	Continuous flow
3	Teams should not make changes during the sprint
4	No strict meetings
5	No required roles, perhaps a Product Owner
6	It is assumed that the amount of work is somewhat equal for different work items
7	Strict meetings: sprint planning, sprint review, sprint retrospective, daily standup
8	Change can happen at any time
9	Amount of work for a work-item is estimated in story points
10	Regular fixed length sprints (1-4 weeks)

You can write down your answer by combining the letters in the cells (A-J) with the numbers of the possible values (1-10).

Solution

Aspect	Scrum	Kanban
Release Methodology	At the end of each sprint	Continuous delivery
Cadance	10: Regular fixed length sprints (1-4 weeks)	2: Continuous flow
Roles	1: Strict roles: Product owner, scrum master, development team	5: No required roles, perhaps a Product Owner
Amount of work estimation	9: Amount of work for a work-item is estimated in story points	6: It is assumed that the amount of work is somewhat equal for different work items
Change Philosophy	3: Teams should not make changes during the sprint	8: Change can happen at any time
Meetings	7: Strict meetings: sprint planning, sprint review, sprint retrospective, daily standup	4: No strict meetings

The letter-number combinations are: A10, B2, C1, D5, E9, F6, G3, H8, I7, J4

NB: Adapted from https://www.atlassian.com/agile/kanban/kanban-vs-scrum

ScrumBan and hybrid methodologies

The Scrum framework itself is really strict in adapting the full set of Scrum rules and not go “cherry picking”. In general failed Scrum implementations are said to have failed because of: “not doing it right or not doing it completely”.

Nevertheless, it is common to do a mixture of Scrum and Kanban, picking the best of both worlds according to the team’s needs. This is called ScrumBan. ScrumBan manifests itself in different ways depending on your team characteristics. The team may use team meetings (like retrospective and planning) from Scrum and a continuous workflow with WIP limits from Kanban.

In fact it is quite common to use ‘hybrid’ methodologies, picking suitable aspects from any of the different Agile methodologies.

We encourage you to iteratively shape the preferred methodology for your team, trying out different concepts from Kanban, Scrum and other methodologies.

Exercise: Ensuring team improvements

How would you ensure that your team keeps improving their team process and Agile methodology?

Solution

Having a recurring retrospective meeting that completely focuses on the team process ensures that the team will revise their working methods regularly. Without such a meeting it is easy to forget about this very important topic.

Other Agile methodologies

See this figure from the 2020 state of Agile survey. It depicts the popularity of used Agile methodologies.

So far we have only discussed Scrum and Kanban, since they are the most popular Agile methodologies.

Nevertheless, there are many other methodologies that go beyond the scope of this course but are worth exploring, to name a few:

• Extreme Programming (see extremeprogramming.org)
• Lean Startup (see this summary video)
• Spotify Model (see this summary video)
• Dynamic Systems Development Method (DSDM, see this summary video)

Key Points

• Scrum and Kanban share similarities, but also have some important differences

• Mix and match concepts from different methodologies to get to a hybrid methodology that matches your team best

Challenges for Agile way of working in research

Overview

Teaching: 40 min
Exercises: 0 min

Questions

• What are challenges for an Agile way of working in research and how do I solve them?

Objectives

• List challenges for an Agile way of working in research

• Know the solutions to challenges for an Agile way of working in research

In this episode we will discuss and learn about challenges that arise when applying Agile principles to research projects. While some of the Agile values and principles go hand in hand with the traditional way of doing academic research, others will require an investment of the team to change their way of working.

Challenges

Discussion

What are the challenges for an Agile way of working that are specific to research? These might be challenges that are more generic to doing teamwork in research, instead of just the Agile way of working.

Uncertainty Challenge

Scientific research is all about discovering the unknown. This makes the work predictably unpredictable to an enourmous extent. The development time of a certain part of the research can range from “already solved by someone else” to “impossible to solve”. Also the requirements can suddenly change by 90 degrees based on the outcomes of a different part of the research project or the availability of data.

Cultural challenge

Many scientists are traditionally used to working individually in an isolated silo. Tasks in academia are often attributed to individuals and not to teams. A PhD-project is by default set up as a one-person project. Given this individualistic culture it is often intimidating to start with Agile practices in a scientific context.

Waterfall project setup challenge

Scientific projects are often set up in long-term project timelines following a Waterfall method. It is not common to ensure early (weekly/monthly) continuous delivery of the research outcomes to the scientific community.

Large-scale projects challenge

Scientific projects can be on a very large scale. It is hard to work together in very large teams. Also, having a continuously changing design in iterative sprints does not always lead to the best large-scale functionality and/or desired research outcomes.

Team dedication challenge

Agile is often explained in the context of a team fully dedicated to a single project. In academia, team members may often be involved in numerous projects in and outside of the team.

Product Owner challenge

For a team running multiple research projects, who acts as product owner when applying the scrum framework?

Open Source software development challenge

The nature of open source projects is that they draw (and benefit from) collaborators outside of your team, workplace and even country. Starting and contributing to open source software projects therefore leads to many dependencies on collaborators outside of the team. Not completely “owning” your product is problematic in many Agile methodologies. Approaches like Scrum may not work well or at all in such a situation.

Specific expertise challenge

For many scientific problems a very specific expertise is needed. This expertise is often even specific for a single project. This makes it hard to work together as other team members need to have or acquire this specific expertise.

What is our “product” challenge

The Agile principles and related methodologies often talk about satisfying the “customer” with bringing “value” to a “product”. But what is “value” in research? And who is the customer? It is often hard or awkward to define scientific outcomes as products with a certain functionality.

Solutions

Discussion

Can you think of solutions to these challenges?

Uncertainty Challenge

Solutions:

• Use spikes: The team could create spikes: items in the backlog that provide time for research and discovery. They are either timeboxed or their definition of done is when the specified research objectives are met.
• Do the least understood work first: Start with the most uncertain tasks and increment from there.
• Deviate from the plan: The sprint plan is not set in stone, teams should ‘negotiate the scope of the Sprint Backlog’ when needed.
• Relax “Definition of Done”: To keep a fast discovery pace, exploratory work doesn’t need to meet the same strict criteria as regular tasks.

Cultural challenge

Solutions:

• Implement flexibly: You should fit the methodology to the way of working. ‘Process-rigidity is the antithesis of agility.’
• Emphasize the “why”: Focus on the “why” for the change to Agile instead of “what” to do to make the change.

Waterfall project setup challenge

Solutions:

• Clear communication is key. Inform your collaborators on your way of working and update them frequently.
• While projects that follow the Waterfall method often do not make the targets set out at the start of the project because of the uncertainty of scientific research. Working in an Agile way enables the flexibility to change plans early on before too much time is spent on so called “dead-ends”.
• The open science movement is working on a continuous and incremental publication model to enable early adoption of scientific results and/or methods. This model fits very well with an Agile way of working.

Large-scale projects challenge

Solutions

• It makes sense to do a few design sprints to set out the bigger plan before embarking on a project.
• The Architectural Runway approach revolves around more large-scale “intentional architectures”.

Team dedication challenge

Solutions:

• Implement flexibly: Again: You should fit the methodology to the way of working. Start from where your team’s activities do overlap and where teamwork seems most beneficial.
• Keeping track: Experiment and iterate on ideas to find the best method to keep track of the different projects in your team. You can start with a Kanban board and backlog for each project seperately.

Product Owner challenge

Solutions:

• Each project has its own ‘project owner’ (usually a team member) that takes the role of product owner for that project.

Open Source software development challenge

Solutions:

• You need to identify what parts of the project you have “ownership” of, and which parts you do not, and then plan development to mitigate issues. You should adapt the chosen Agile methodology to fit the project, and not the other way around. If the software development will be (mostly) carried out by a core team of developers who work intensively on that project, with only occasional contributions from others, then Scrum can be an option. For projects that differ substantially from this, a “looser” approach may work, such as Kanban.

Specific expertise challenge

Solutions:

• Not everyone has to be involved in everything! You can help each other out on a conceptual level even without knowing all the details.
• Be explicit and open about each team member’s expertise and how it fits best within the different projects.

What is our “product” challenge

Solutions:

• Discuss this in your team! Our proposition:
  • Our customers: The Scientific Community at Large, specific scientific sub-communities, non-scientific user communities, etc.
  • Value for our Customers: Useful, well programmed software. Output (papers, blogs etc.). Increased FAIR-ness and quality of research. Disseminated expertise on eScience Technology.
  • Product: It helps to think of all outputs of scientific research as products: Posters, papers, protocols, software, data, etc. For example, in contrast to what the first value of the Agile manifesto reads, documentation is often a very important key outcome of scientific research. A scientific instrument/software/protocol can have many issues, but when it is well documented, other groups can build on it. Vice versa, even when a scientific instrument/software/protocol is functioning perfectly, if it is undocumented, it is often useless for scientific research.

Resources

• Scrum for Data Science
• Reinventing Research: Agile in the Academic Laboratory . Includes a proposition for an Agile Manifesto for academia.

Of course, methodological issues are not the only challenge in team work. Soft skills can be just as important, if not more. We discuss this next, in episode 7.

Key Points

• Agile methodologies should be slightly adapted so that they work well in a research setting

• Remember to fit the methodology to your way of working

Practical recommendations for team work

Overview

Teaching: 5 min
Exercises: 20 min

Questions

• What are practical tips for doing team work?

• What soft skills are valuable when working in teams?

• How can I apply what I learned in my daily work?

Objectives

• List a few practical recommendations for doing teamwork

• Know which soft skills make great teams

Practical recommendations

Discussion: Your practical tips.

Based on your own experience, what would be your top-3 practical tips that you would like to give someone that is new to working in a team? This can be based on experience with formal teams, in pairs, or any other form of collaborative work.

Our tips:

• Any mutation to the team makes a new team. Whenever a team member leaves or is added to the team, you should treat this as the start of a new team. The ways of working before can be maintained for a start but be prepared for large changes in the team dynamic, which will also influence which ways of working make up for the optimal team process.
• Teams need a coach. Self-organization of teams doesn’t happen automatically. It can be very beneficial to have someone in or close to the team that can coach the team in the right direction.
• Enjoy. Value joy in team meetings and interactions. Working together in an enthusiastic group of people makes all the rest simple.
• Invest in soft skills. Certain soft skills are vital for teamwork, see below.

Soft skills

Teams stand or fall with good soft skills of team members.

Discussion: Soft skills.

Which soft skills do you think are important to have when doing teamwork. For example, think about applying the agile frameworks that we learned about, what soft skills are important?

These are some important soft skills needed in teams:

Giving good feedback

Learning from each other is one of the benefits of team work. For this, giving good feedback is vital.

How to give good feedback?

• Make it specific
• Give feedback from your perspective. Feedback is always subjective.
• Don’t wait too long with giving feedback.
• Stay positive. A good rule is to always start with something positive.
• Prepare your comments.

  How to receive feedback?

• Don’t feel attacked. The person giving you feedback is trying to help you.
• Ask for clarification if the feedback is not specific enough.

If you want to learn more about giving feedback in a way that is pleasant for others, we recommend that you take a course dedicated to this topic with your whole team. For a first impression, here is a short guide about giving constructive feedback.

Build trust

Trust between team members is important for:

• Trusting each other to successfully finish tasks.
• Giving good feedback to each other.
• Knowing that feedback will be given to you in case you can improve on something.

  How to build trust in a team?

• Create a safe environment for failures. Don’t blame people personally.
• Admit when you don’t know something.
• Give praise. The importance of positive feedback is often forgotten.
• Also talk regularly with your team members about non-work related stuff.

Be inclusive

Inclusivity is when individuals with different identities, backgrounds or other characteristics making them vulnerable for exclusion, are welcomed in a group setting. It is good to be aware of this in a team.

Tips for being inclusive

• Dare to speak up if you feel someone is left out. If done constructively, this is usually appreciated by everyone.
• Acknowledge that you have an unconscious bias.
• Try to imagine yourself being in the place of your team members.
• Having trust in the team helps (see above).
• Set up policies or explicit common practices for the whole team if unconscious exclusion persists. E.g. put up a reminder that the whole team should speak in English when you are in the vicinity of people that do not speak your first language.

Team bonding

This may sound trivial, but don’t underestimate the importance of team bonding. It really helps to step out of the formal office setting, and improve the relationships in the team over a drink, doing a sports activity, or solving an escape room together. Engaging in social activities is also one of the best ways to build trust between members.

Wrapping up

Exercise: Wrapping up.

Take a few minutes to write down your thoughts on what you learned about teamwork in this course:

• What questions do you still have?
• Whether there are any incremental improvements that can benefit your projects?
• What’s nice that we learnt but is overkill for your current work?

Key Points

• Learn from other people’s experiences working in teams.

• Certain soft skills are vital for teamwork.