Team

In Clarity, a Team is a group of people capable of delivering a logical set of tasks to deliver a shared outcome. For example, a group of people working on a single Project, a group of people working on the same assembly line and similar.

It is highly recommended to organize teams to be as cross-functional as possible - composed of people with different functional expertise working toward a common objective. Teams should have enough expertise to deliver outcomes with minimal or no dependencies on resources outside the domain of the team.

As a general rule Teams should have no more than one backlog to follow and each Backlog should contain only related work.

• Multiple unrelated or loosely related projects should never share a single backlog.
• Multiple teams should never share a single backlog.

Multiple backlogs per single Team are permissible provided that it is made abundantly clear when and how much time should be allocated to each backlog by each Team. This is not recommended and should be avoided if at all possible - mixing units of work and Teams will inevitably lead to an environment where it is increasingly difficult to maintain balance and focus between different business objectives.

Team-backlog relation also serves as a natural limit of how large a project or logical work unit can become.

The perfect team size in Clarity is no more than 7-10 people + Team leader (~7+1). Depending on the industry and context, 5+1 being the recommended team size. Larger teams than this usually mean more individual mental and general management overhead, and projects or work that can not be completed by a team of a given size should be split between several self-organizing but strongly interacting teams.

The recommendation for the ideal team size in Clarity is based on research by Pádraig MacCarron, Kimmo Kaski and Robin Dunbar on layered structure of social relationships, and research by Tyler H. McCormick, Matthew J. Salganik, and Tian Zheng on personal network size estimations.

Based on this research, which presents strong evidence that while humans are able to maintain about 150 social relationships at any given time, the inner circle to whom an individual is able to form close to very close relationships is much smaller. The (~5+1) team size is a number that was chosen based on this research to maximize ability of individuals to strongly interact with each other during normal working relationships while minimizing the overhead maintaining these relationships requires, while also taking into account relationships a person can have outside of working environment.

Team leader

Team leader is an individual responsible for organizing work in single Backlog for a single Team and for the management of the Team itself. Team leader organizes, prioritizes and controls progression of work.

All team and team specific work related information, such as requirements, priorities and tasks are all managed by the Team leader.

It is essential that the Team leader has a very firm grasp about both business operations and implementation semantics of all work the Team is supposed to do. This is in large part due to the fact that Team leader serves as a bridge between the two domains of knowledge - the business domain and the domain of implementation and delivery.

Team leader also serves as a tiebreaker and has the last-resort final say on how the Team operates within its domain of responsibility.

What is the relation between Team leader, Product owner and Project manager?

These are three separate roles, usually, but not always, assigned to three separate individuals within organization. Team leader is specifically responsible for all aspects of a single logical subset of work and its execution - Backlog, and a logical subset of staff - a Team. Product owner is generally responsible for vision, and the big picture of the product. Project manager is generally responsible for implementation of a product as a whole or a subset of it.

Product owners and Product managers might (or might not) operate on a different plane of organization - product and project levels, since one product can have one or more projects and each of these projects can have one or more different backlogs. It depends heavily on the working and organizational semantics of your organization.

All of these relationships and domains of responsibility are highly dependent on internal workings of an organization, for example, how large the projects and products are, what kind of staff is available and such. For large organizations it would commonly be the case that Team leader, Product owner and Project manager are three separate individuals. For relatively smaller organizations or it is entirely possible all three roles are assigned to a single individual.

Clarity does not prescribe one true way of organizing staff outside the domain of a single Team and Team leader. Beyond that, it is up to the implementing organization to decide what roles should there be and how, and to whom they should be delegated.

Creating new teams

The preferable way of creating new teams is using so called core-split approach, where one or more experienced team members from an existing team are reassigned to form the core of a new team. This approach allows for greater cohesion between various teams and allows for larger natural networks to form within an organization, which in turn facilitates cross-communication between teams and organizational community as a whole.

Teams can be formed entirely from new team members if the core-split formation is for any reasons not possible - such as lack of resources or other hard constraints, however, even then, at least one senior member of an existing team should be re-assigned (even temporarily) to help the new team form in a way that is cohesive within the context of the organization. A better approach could be to simultaneously add new members to an existing team and re-assign some existing members from that team to form a core of a new team.

In Clarity, teams should not be considered fixed and eternal, and members of a team can be re-assigned to other activities and communities as needed, however, not too often as to not disrupt the operation of the team needlessly.