Collective code ownership is one of those agile practices that is often overlooked, but is actually essential. It doesn't have the flash of continuous integration or the controversy of pair programming, but it's part of what makes an agile team "agile."
What makes a team agile? When I think of agile teams and what they look like--what they feel like--I don't think of the dictionary definition of agility. Yeah, yeah, agile teams deliver frequently, change direction readily, yadda yadda yadda. That's what agile teams do, not what they are.
The great agile teams have a certain feel to them. It's one of intense collaboration... of competent professionalism... and of pride in their work. Maybe there's more, but that's what comes to mind at the moment.
Collective ownership ties into the collaboration aspect. A lot of software development shops divide their work up into individual module and hand them out. People work together, but they don't collaborate on their work. They use each others' stuff, but each person is solely responsible for his component. That's the strong code ownership model.
We've discovered that the strong code ownership model has a lot of problems (like, what do you do when Joe is on holiday for two weeks and we need to make a change to his code?) so some shops use a weak ownership model, which allows others to change Joe's code if Joe gives permission.
But that's still not collaborative. Collaboration involves working together: creating, critiquing, and refining. We collaborate because together we can create a work that is greater than either of us could produce alone. That's the ostensible value of collective code ownership: we produce code that is better than we would produce alone.
There's more to it than that. Collective ownership helps teams form. By working together, as a group, on a single codebase, programmers learn to work together. They face problems and generate creative solutions. They gain a sense of shared responsibility, shared success, and joint pride of ownership. This is the crucible from which great teams emerge.
Collective ownership isn't just for programmers, either. We want everyone on the team to have a sense of responsibility and ownership over the product. We want the success of the product to be the team's success, and problems with the product to be everyone's problems, to solve together. Great agile teams don't engage in fingerpointing. They identify problems, they fix them, they move on. They create great works. And one way it starts is with collective code ownership.