2

From my understanding collective ownership will solve common problems with the antiquated such as quality, failure due to absence and knowledge-sharing.

However, there are some things that I don't understand.

  1. Is the team a democracy? If so, what if the majority are wrong?
  2. Why choose technical correctness over "people correctness"? i.e. What's technically correct may not be most motivational/enjoyable choice for the people working on the project. An unhappy team is more likely to create bad quality than a motivated team.
  3. What about the individual's creativity, understanding, exploration and experimentation? These are likely to be neglected if the only decisions that get made are based on a mutual agreement.
  4. How is rogue activity handled? For example, if 99% of a project is done and the entire team except one person goes on holiday the next day, what stops that one person from changing things that were already agreed on during pair programming sessions, just before delivering the last 1%?
  5. Won't code production time be massively increased? If the entire team has to learn all code that gets produced then technically only one thing can be produced at a time.

Edit: Added point 4 and 5.

Improve this question
2
  • These are multiple questions. While they might be vaguely related, they are clearly different questions that must be asked separately to avoid being Too Broad. Furthermore, the subject of cross-functional teaming vs. individualism on projects fills entire books, and is clearly Too Broad unless narrowed down into a concrete problem that you are facing.
    – Todd A. Jacobs ♦
    Commented Feb 9, 2015 at 0:11
  • The comment threads on all the answers are getting out of hand. PMSE is a Q&A site, not a discussion forum. Please use comments only to clarify or improve answers; everything else should be moved to chat.
    – Todd A. Jacobs ♦
    Commented Feb 10, 2015 at 8:44

3 Answers 3

Reset to default
4

"Collective code ownership" does not mean that everyone on the team gets a say on every line of code that's written. The code is still written by individuals (unless you're pair programming), and they are making the decisions they feel are best at the time. The point is that no individual "owns" a section of the code.

If John wrote the Foo module, and for some reason there's a critical bug discovered while John is away, there should be nothing stopping Sue from jumping in and fixing it. It's not "John's code" it's the teams.

So then there's the question of "how does Sue fix the code, if John wrote it?" and the answer isn't that Sue and the rest of the team decided on every line with John, but rather that John, in the spirit of teamwork and cooperation, and knowing that he wouldn't be the only person working on the code, took the time to write tests and document the code so that Sue would be able to work on it.

Sue might also have some experience with the code from code reviews which - again - are not a chance for the team to decide how the code should have been written, but merely to make sure it's serving it's purpose and up to whatever standards the team follows.

As for point 3, experimentation, exploration etc. belong in prototypes and personal projects, not in the production code.

Improve this answer
9
  • If it's not done on a line by line basis then when John's working on the code, it's John's solution. When Sue works on John's code, it's Sue's solution since they can change the code to best suit their preferences? In your response to point 3, that kind of mentality will result in no one ever being willing to work longer and harder since their job will always just be a sacrifice rather than an exciting opportunity. I dont think that this is reliable or efficient. In principle I believe correctness should be with people not with technology since happy people make good technology not vice versa.
    – anon
    Commented Feb 8, 2015 at 22:08
  • When John's working on the code, it's the team's solution, when Sue's working on it, it's also the team's solution. If Sue is making unrelated changes purely out of personal preference, then she's acting selfishly and against the teams best interest.
    – Mike Gossmann
    Commented Feb 8, 2015 at 22:33
  • 1
    For point 3: Code can be creative, experimental and part of a prototype in the morning, and be a well-documented clearly-written piece of production code by evening. The point was more that if you're putting code into production that no-one else can work with, then you're not being a team player.
    – Mike Gossmann
    Commented Feb 8, 2015 at 22:35
  • 1
    @ThreaT "design phase" screams waterfall, not agile. I think you've got a overly draconian view of what "collective ownership" implies. Just write code as you normally would, but keep in mind others will have to work on it (comments, cleanliness, etc), don't get upset when someone does edit it, and don't be afraid to edit code that's "not yours". It's about putting egos aside and working as a team.
    – Mike Gossmann
    Commented Feb 9, 2015 at 20:16
  • 1
    @ThreaT: People don't go into the code to make it more normalized, as there usually isn't time for such 'idle work'. And there should be communication between the developers to avoid conflicts. If I am working on a big change to classes X, Y and Z and I see a second feature on the backlog involving one of those classes, then I would warn the team should be left alone until I am finished with my big change. After I am done, anyone is free to start with that other feature.
    – Bart van Ingen Schenau
    Commented Feb 10, 2015 at 7:43
4
  1. What if the majority are wrong

It can happen of course. I would expect any issues that arise from a wrong decision to be raised and discussed at retrospectives. Hopefully the team would then recognise the error it had made and adjust.

  1. Why chose technical correctness over people correctness

Why indeed. The team should discuss the pros and cons of the different approaches. They may decide that a technically non-optimal solution is more appropriate. A healthy team will discuss this openly and make a decision based on their collective experience.

  1. Does individual talent get neglected

A good team is looking for ways to do a good job. They will do that both by collaboration and by reinforcing the strengths of individuals in the team.

  1. How is rogue activity handled

If rogue behaviour is causing issues these will get raised and discussed at retrospectives. Peer pressure is usually sufficient to encourage the rogue to work in a more productive way, particularly if the ill effects can be demonstrated.

Improve this answer
6
  • Nice answer. I would like you to expand on point 3 before accepting it as correct though. I still don't really see how individual growth is encouraged with collective ownership.
    – anon
    Commented Feb 8, 2015 at 22:37
  • A lot will depend on the personalities of the team members. If they are open minded and non-confrontational then they will see the potential of the individual and nurture it. The key is to have a fail fast approach and no recriminations when something goes badly. The retrospectives will feedback about things that went well and things that went badly. If the individual is doing things that really help they should get mentioned in the retrospectives. A positive team will look to support that success.
    – Barnaby Golden
    Commented Feb 9, 2015 at 0:40
  • @BarnbyGolden: In my experience the sprint board takes priority over the retrospective every time. Even if you mention something in retrospective it's highly unlikely that you will be given a chance to do new things creatively on your own instead of doing things in a collective ownership manner.
    – anon
    Commented Feb 9, 2015 at 6:23
  • Continual improvement is the heart of the Scrum process. If individuals are finding it hard to get action on proposed improvements there may be a problem with the way the retrospectives are being run. But if individuals are suggesting changes it is important they also describe how the change will improve things and just as important, how they can measure that change. Given a reasoned argument and a defined measure of success the team will usually allow a change to proceed. If the team is unwilling to try then it suggests lack of trust and that they are missing out on the benefits of agile.
    – Barnaby Golden
    Commented Feb 9, 2015 at 8:48
  • It's not always possible to advise how an exploration will necessarily improve things because you won't know until you've tried. Exploration of new ideas may fail but it also may work out to be really beneficial. Even if you bring up lack of creativity in the retrospect, if there are higher priority tasks that are constantly required then creativity will always be put aside. One possibility is to let developers do things solo now and then but this obviously conflicts with collective ownership.
    – anon
    Commented Feb 9, 2015 at 9:45
0
  1. What if the majority are wrong?

It is okay if this happens! The idea is to 'fail fast,' adapt, update your plan, and move on, trying something else. The 'fail fast' concept is just another way to apply the Scientific Method to your work.

Only addressing first question for now I am on mobile.

Improve this answer