# Team Assembly

In this section, we'll discuss the importance of teamwork and how to build a successful team. Why are we learning this?

You will work in teams in this course, and likely in your future career.
You will experience conflict at some point.
You will have time management issues.
You will have team motivation challenges.

We want you to be prepared for these challenges and to have the tools to overcome them.

Successful teams are built on trust, respect, and communication. We'll discuss the steps and actions you can take to make your team successful.

Credit for this section belongs with Michael Liu and members of the Teamwork Skills Project. Some material has been adapted for this course.

What are the attributes of a successful team?

Attribute	What does it mean?
Shared mission and goals	The team clearly understands and agrees with the mission and goals of the project.
Leadership	The team has a leader who can guide the team to success. Leadership tasks are performed reliably and consistently.
Communication	The team communicates effectively and efficiently. Team members share beliefs and expectations.
Decision making	The team has an agreed-upon decision-making process.
Team culture	The culture that you collectively build provides structure and support for team members.
Conflict management	The team has a process for resolving conflicts, and addresses conflict productively; it avoids personal conflict.
Team meetings	Meetings are held regularly to facilitate communication and group decision making.
Self-management	Individual team members complete individual tasks and assignments effectively.

# Team Contracts

A team contract is a document that outlines the expectations and responsibilities of each team member. It is a tool that helps the team establish a shared understanding of the project and the roles of each team member.

The exact content is decided by the team, but the contract typically addresses:

Team leadership and communication
Team meeting expectations
Team & individual expectations
Managing team challenges and conflict
Other considerations

It may include contract clauses such as:

"All members will attend meetings or notify the team by email or phone in advance of anticipated absences."

"All members will be fully engaged in team meetings and will not work on other assignments during the meeting."

"All members will come to meetings prepared by reading the assigned material and/or watching assigned lecture videos ahead of time."

See the Public Gitlab Repo > Templates for a sample team contract.

# Phases of Team Development

Teams don't come together and become effective overnight. It takes time, and deliberate effort on the part of team members to build a successful team.

One common model of team development is Scott M. Graffius' "Five Stages of Team Development":

Forming: The team comes together and gets to know each other. This is a time of excitement and anticipation.
Storming: The team starts to work together and differences in opinion may arise. This is a time of conflict and disagreement.
Norming: The team starts to resolve their differences and work together more effectively. This is a time of cooperation and collaboration.
Performing: The team is now working together effectively and achieving their goals. This is a time of high productivity and success.
Adjourning: The team has completed their project and is ready to move on. This is a time of reflection and celebration.

Team meetings and team contracts can help the team move through these stages more quickly.

# Project Planning

A project plan is a document that outlines the tasks, resources, and timeline for a project. It helps the team stay on track and meet deadlines. This can help with time management issues.

As an Agile team, you are not expected to plan everything up-front. Instead, you will plan in short iterations, called sprints. This allows you to adjust your plan as you learn more about the project and the team's capabilities.

However, it is still useful to have a high-level plan that outlines the project's goals, timeline, and resources. This plan can be used to guide the team's work and ensure that everyone is on the same page.

# Defining team roles

It is useful to determine team roles at the start of a project, to help guide the team's work. Roles can include:

Team Lead: This is the project leader, NOT the technical leader for the project. This person is responsible for keeping the team on track and ensuring that the project is completed on time. They do this by ensusing that the requirements are defined accurately, that the team is tracking work properly, and that the team is meeting its goals for each deliverable. They often define the agenda for the team meeting, take minutes and ensure that the team is following the team contract.
Technical Lead: This person is responsible for ensuring that the technical aspects of the project are completed correctly. They are responsible for ensuring that the team is following best practices, that the code is complete and follows course guidelines. In the way that the team lead helps manage the project, the techical leader helps manage the code contributions of the team. They often review code, help team members debug, and ensure that code is reviewed and merged properly.
Design Lead: Teams (at least in this course) may have a Front-End Design Lead, and a Back-End Design Lead, each of which is responsible for the design and delivery of a core part of the product.

Note that these roles are NOT prescriptive. They are meant to guide the team in their work. The team should be flexible and adapt to the needs of the project. It's normal for someone to wear multiple hats e.g. design lead for the front-end, but also handling packaging (because they may have done that before).

This means that, for example:

Team leads still write code. Managing the project is not a full-time job.
Technical leads can still take meeting minutes and write code. They are not just code reviewers.
Design leads can still help with other parts of the project outside of their immediate area of responsibility.

No single person is "the boss" of the project, and significant decisions should be made with the input of the entire team.

# Generating a plan

Steps to generate a project plan:

Identify the project components. In this case, high-level components such as deliverable dates, milestones, and tasks.
Specify tasks which need to be completed within each deliverable.
Specify the order in which tasks should be completed.
Estimate the time. This should NOT be done with any granulatory; it is sufficient at this stage to estimate in days or weeks.
Estimate team members required to complete each task.
Identify dependencies between tasks. i.e. Task A must be completed before Task B can start. This should follow from (3).
Assign team members.

Again, for an Agile team, this should be very high-level. It is mainly meant to provide broad guidance. e.g. if 75% of your high-level tasks are database related, and you only have one person dedicated to those tasks, you may want to rethink your plan.

# Creating a Gantt Chart

A Gantt chart should be included in your project proposal. It lists high-level objectives down the left side and dates across the top. Each task is represented by a bar that spans the dates when the task is planned to be completed.

https://www.productplan.com/glossary/gantt-chart/

See Toolchain > Markdown > Mermaid for an example of how to create a Gantt chart in Markdown.

# Identifying project components

Identifying what needs to be done should be, at least initially, a team effort. The team should brainstorm and list all the tasks that need to be completed.

This is a good time to use a whiteboard or a shared document to list all the tasks. This can be done in a team meeting or asynchronously.

Given an Agile framework, you should expect to review and update this list regularly.

This is an ongoing activity as you learn more about your project, and make design decisions.