|
|
|
*This document is part of the ['Organization'](/organization/Organization) chapter of the Sinergise Operational Handbook.*
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
We work in stable, self-organizing teams.
|
|
|
|
The teams decide on how they organize their work internally.
|
|
|
|
This document describes the general properties and responsibilities of the team, applicable to all team members. [A separate document is dedicated to the role of **team coordinator**](/organization/Team-Coordinator-Role).
|
|
|
|
|
|
|
|
## Key Properties of a Team
|
|
|
|
|
|
|
|
- self-organizing [[1]](#references) cross-functional teams of 5-7 members (Jeff Bezos’ 2-pizza rule)
|
|
|
|
|
|
|
|
- the team has the authority to decide on its internal organization, processes and work methodology; management might suggest changes when it detects problems.
|
|
|
|
|
|
|
|
- teams strive to shift to maximizing dependencies between people (in execution of tasks), while minimizing dependence of work on specific individuals (as more people will participate working on a module, they will be familiar with aspects of it).
|
|
|
|
|
|
|
|
- there’s no absolute rules about the skills or domain knowledge of the members on a team - there should be overlap between members, but not everyone should need to know everything about a product. (some teams will have a better skill set for certain products, other teams for other products)
|
|
|
|
|
|
|
|
- individual can occasionally move from one team to another without causing significant inconvenience. This needs to be coordinated and agreed at least between both teams that are affected by a move. Management will need to be in the loop in this process, and probably have to provide the final blessing.
|
|
|
|
|
|
|
|
- each team has a designated [team coordinator](/organization/Team-Coordinator-Role), whose primary role is to act as an interface to the rest of the company.
|
|
|
|
|
|
|
|
## Team responsibilities
|
|
|
|
|
|
|
|
- collective responsibility and accountability for performance and results
|
|
|
|
- work coordination within the team
|
|
|
|
- prioritizing tasks based on high-level priorities set by product owners
|
|
|
|
- team performance and growth (in the sense of improvement of all aspects of efficiency and capability of the team and its members)
|
|
|
|
- support each other's work, growth, and learning, by:
|
|
|
|
- giving regular and honest feedback to each other
|
|
|
|
- *if you find yourself gossiping or complaining over a person to your colleagues, make sure you've given the same feedback to that person*
|
|
|
|
- *when giving negative feedback, be constructive and don't be too general and provide concrete examples*
|
|
|
|
- *no matter how honest, though, treat people with respect*
|
|
|
|
- recognize work well done
|
|
|
|
- identify each other’s shortcomings and help each other overcome them
|
|
|
|
- actively encourage learning of new skills
|
|
|
|
- disseminate technical and domain knowledge [[2]](#references) within and across teams - *maximize the 'bus factor' [[3]](#references)*
|
|
|
|
- participating in the hiring process for new team members- *team members should care and have a saying on who they want on board*
|
|
|
|
- onboarding new members and assigning them a mentor and an onboarding buddy within the team - *it is in the best interest of the team to onboard a new member as quickly and efficiently as possible*
|
|
|
|
- if a team cannot find a mentor in its own ranks, the new member should be placed in another team with an appropriate mentor available until achieving independence (see mentoring guidelines).
|
|
|
|
- follow prescribed guidelines where applicable - *not all practices will work for every team, but practices that have been proven successful in other teams should at least be given a consideration*
|
|
|
|
- ensure that work results are of appropriate quality, documented accordingly and follow all applicable guidelines (engineering, documentation, etc) to make any handoffs and help between teams possible and smooth; if the team does not ensure this, it can't realistically expect any outside help.
|
|
|
|
- leadership is expected from everyone and is collaborative. All members should, to the best of their ablities:
|
|
|
|
- actively participate in internal organizational discussions
|
|
|
|
- have a vision for their own and the team's future
|
|
|
|
- contribute to the performance, development and well-being of the team
|
|
|
|
- accept and execute all other responsibilities listed here as 'team responsibilities'
|
|
|
|
|
|
|
|
- constantly look for ways to improve team processes (ideally with small iterative changes) - *not everything will work and that is ok, we learn from mistakes, revert and try something else*
|
|
|
|
|
|
|
|
## Teamwork Guidelines
|
|
|
|
|
|
|
|
The following guidelines represent practices, which we believe would work well in the new organizational setting. Most of the following practices have already been successfully tried out within the company. The guidelines should evolve while we learn from different practices and different team settings.
|
|
|
|
|
|
|
|
The teams have full authority to decide on which practices they follow and to introduce new practices. But the teams are also expected to be able to argument their decisions on practices to the management.
|
|
|
|
|
|
|
|
- work should always be assigned to teams and never to individuals
|
|
|
|
- even when an individual receives an urgent tasks directly (from customer, product owner or management), they should communicate and coordinate the task with the entire team
|
|
|
|
- the entire team should work on the same product
|
|
|
|
- if a team has responsibilities on several products, try not to split the team on different products, but rather have the entire team work on the same product at the same time; e.g. allocate a week for Product A and next week for Product B.
|
|
|
|
- the entire team should strive to collaboratively own and work on individual tasks
|
|
|
|
- dependencies on individuals should be avoided to ensure contingency and prevent one being stuck in the same task for years, e.g. java developers should proactively try to work on database tasks and database developers should get into java code often, learning one from another
|
|
|
|
- expertise should be facilitated to ensure best results, but it should not be taken as an excuse to be the only one capable of doing something [[4]](#references)
|
|
|
|
- collaborate on all aspects; planning, development, testing, documentation, deployment, maintenance
|
|
|
|
- increase dependencies on each other's work to increase team collaboration and reduce dependencies on individuals
|
|
|
|
- at regular intervals, preferably every week or two, the team should provide an integrated, running, tested version of the software, the *“Increment”* [[5]](#references), containing all the features and capabilities which have been completed so far on the product. The Increment must be in usable condition and must meet all the agreed standards of completeness and correctness.
|
|
|
|
- the job of the team (as a whole), at any given time, is to prepare the next increment.
|
|
|
|
- scope of the increment (=features) is set at the start of the increment, together with the product owner.
|
|
|
|
- increments should be small (1-2 weeks). The scope is determined by feature priority and not by availability of individuals. In principle, availability of all team members should be the same, as they’ve just finished the previous increment.
|
|
|
|
- scope of the next increment is selected as a whole and not based on individual’s availability.
|
|
|
|
- only once the scope is selected should the team agree on task assignment. The tasks should be assigned to effectively utilize all team members, based on their skills and preferences.
|
|
|
|
- if a team member can’t find a task suitable to their skills during an increment, they should help other team members to the best of their ability (design, design review, paring, devops, testing, documentation).
|
|
|
|
- at any moment, the entire team is working on the smallest amount of most important tasks, which does not mean that everyone is working on the same task. When an individual is behind on a task, other members should pitch in, instead of waiting or working on less important tasks.
|
|
|
|
- in situations when more subsequent increments haven’t been best aligned with the skills or preferences of an individual member, then the individual can be lended to another team requiring their skills for a limited time (few increments).
|
|
|
|
- working in such a way, ensuring regular, completed increments containing only the highest-priority features, the team should be always able to hit the deadline with the best possible result at that time [[6]](#references).
|
|
|
|
- have regular (preferably not-too-scheduled) team meetings
|
|
|
|
- between each increment
|
|
|
|
- retrospect and discuss how things were done and how the internal team processes could be improved
|
|
|
|
- it is encouraged to disagree and have a constructive confrontation; everyone’s opinion should be heard and considered, but consensus is not a goal here
|
|
|
|
- facilitate peer reviews (code, documentation and other results) (100% within-team peer-review is reasonable) and encourage pair programming; this should greatly increase overlap in both technical and domain knowledge
|
|
|
|
- frequently cross team boundaries (e.g. in each increment, select a chunk of changes and get a review from some other random team); limit individualism on a team level and collaborative gardens
|
|
|
|
- testing (especially FAT) should be periodically executed by the entire team, which should force all members to familiarize with the entire product and broaden the domain knowledge
|
|
|
|
- use Scrum or Kanban agile frameworks [[7]](#references)
|
|
|
|
- consider avoiding timeboxing [[8]](#references)
|
|
|
|
- actively develop attributes that help the team perform and grow - e.g. RAMPS is a very good start [[9]](#references)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### References
|
|
|
|
|
|
|
|
- [1] https://www.mountaingoatsoftware.com/blog/two-types-of-authority-leaders-must-give-to-self-organizing-teams
|
|
|
|
- [2] https://www.linkedin.com/pulse/hard-thing-software-development-jesse-watson/
|
|
|
|
- [3] https://en.wikipedia.org/wiki/Bus_factor
|
|
|
|
- [4] https://blog.agilistic.nl/what-it-means-to-be-a-cross-functional-team-and-what-it-doesnt/
|
|
|
|
- [5] https://ronjeffries.com/articles/017-08ff/new-framework-increment/
|
|
|
|
- [6] https://ronjeffries.com/articles/018-01ff/deadline-defense/
|
|
|
|
- [7] McLean, Hall, G. (2017). Adaptive Code (it has a nice intro and comparison of Scrum and Kanban)
|
|
|
|
- [8] https://www.linkedin.com/pulse/day-we-stopped-sprinting-joshua-kerievsky/
|
|
|
|
- [9] https://ronjeffries.com/articles/017-08ff/ramps/
|
|
|
|
|
|
|
|
----
|
|
|
|
Document history:
|
|
|
|
|
|
|
|
|Date|Author|Change Description|
|
|
|
|
|----|------|------------------|
|
|
|
|
|2021-04-30|mkadunc|Migrated and adapted from [the original reorganization PDF](https://git.sinergise.com/operations/docs/-/blob/master/reorganization.pdf)| |
|
|
|
\ No newline at end of file |
