Collective ownership in agile teams promotes shared responsibility for code quality, encouraging all members to address issues they encounter. Key benefits include knowledge sharing, reduced dependence on individuals, and improved coding practices; however, challenges such as lack of motivation and specialization exist. Effective communication and practices like pair programming, continuous integration, and refactoring are essential for maintaining code quality within a collectively owned codebase.

1. Collective
ownership in agile
teams
Kapil R Nakhwa.
http://jyaasa.com

2. Question:
What is Collective
ownership ?

3. Types of ownerships
- Strong Ownership
- Weak Ownership
- Collective Ownership.
Jyaasa : We Design, Build and Develop Products

4. Why collective ownership?
● Mitigate truck number risk.
● Everyone is expected to fix the problem they find.

5. Expected benefits
● knowledge sharing
● Code quality and better coding style.
● Reduced dependency on individual.
● Efficient and useful code reviews.
● Great learning scope.
● Agile/Scrum Principles.

6. Common shortcomings
● Not my responsibility.
● No enforced motivation.
● Team’s technically capability.
● Specialization VS generalization.

7. Do not let specialization prevent you
from learning other things. If your
speciality is AI and team is doing user
interfaces this week. Pick a UI task It
will only improve your skills

8. Making it work.
● Let go of the ego .
● Take pride in team’s work not on your own.
● Stop pushing your design vision and discuss design
possibilities.
● Commitment from each members to produce good
code.
● When you see a problem you fix it
● When writing new code, Do not do a half assed job half
heartedly.
● Do not assume somebody else will fix the mistake.
● Write the best code you can

9. On other hand.
● Does not mean you have to be perfect.
● If you’ve produced code that works with reasonable
quality and not sure on how to improve it. Let it go . You
will improve it when you know more and when needed.

10. Working with Unfamiliar
codebase.
● If you are working on knowledge silos . You may be
afraid. Very afraid.
● But to begin : Pair program or rubber duck debug.
● Or ask expert to help you out .
● Rely on inference skills
● Rely on test suites as a safety net to test your
assumptions.
● As you work look for opportunities to refactor .

11. Last words:
● Proceed with caution unless you use test-driven
development, simple design, and agree on coding
standards.
● To take advantage of collective ownership's ability to
improve code quality, the team must practice relentless
refactoring.
● To coordinate changes, you must use continuous
integration and a concurrent model of version control.

12. ● "shared responsibility is no responsibility at all." Don't
let that happen to your code.
● Collective code ownership requires good
communication. Without it, the team cannot maintain a
shared vision, and code quality will suffer. Several XP
practices help provide this communication: a team that
includes experienced designers, sitting together, and
pair programming.
● good design and tests make collective code ownership is
easier.
Last words:

14. References:
http://www.extremeprogramming.or
g/rules/collective.html
http://www.jamesshore.com/Agile-
Book/collective_code_ownership.ht
ml