Collective Ownership

Code is collectively owned. Any developer of the team can change any module at any time.

Benefits

• Improved Team Unity: Collective ownership eliminates factions and hierarchy through equal access rights to the code.
• Reduces Duplication: Shared logic between different modules in the project through shared access.
• No Bureaucratic Hurdles: Not having to ask and wait for permission to apply constructive code changes saves time. In teams where there is no collective ownership, it is not uncommon for reasonable improvements to even be blocked.
• Module Responsibility: It may make sense to have people responsible for specific modules, but they should only monitor changes, not block them.
• For big code bases, collective ownership may go across teams like in an open source project, but company internal. Other teams create MR's and the team responsible has to approve it.

Specialization vs Generalization

While specialization increases productivity in a specific area, generalization fosters growth in technical knowledge and team support. Aim for a balance between the two. Example:

• A backend specialist may be responsible for a story that requires both frontend and backend changes. Ideally, the backend specialist will have enough general knowledge to solve the task on his own, but if not, he should be paired with a frontend specialist to solve the problem and expand his frontend knowledge. If the task is still too complex or difficult, the next options might be to reassign the task to another developer or get help from the team, and this decision should be made transparently and collaboratively by the team.