Code Library

Collective ownership refers to all developers feeling ownership over all artifacts of the development process, but especially of the code and automated tests. Because of the fast pace of a Scrum project, the team needs to avoid the trap of saying, "That's Ted's code. We can't touch it." Collective ownership encourages each team member to feel responsible for all parts of the program so that any programmer can work on any module of the program. When modifying a module, the programmer then shares responsibility for its quality with the module's initial writer.

Collective ownership is not intended to cause a free-for-all in the coding. Programmers will still tend to have certain areas they specialize in and prefer to work in, but everyone on the team shares the following responsibilities:

• Ensure that no developer becomes so specialized he can contribute only in one area.

• Make certain that no area becomes so intricate that it is understood and worked upon by only one developer.

A natural benefit of fostering a feeling of collective ownership is that it encourages developers to learn new parts of the system. In doing so they generally also learn new ways of doing things. Good ideas used in one part of the application are more quickly propagated to other areas as programmers moving in and out of parts of the application carry the ideas like pollen.



"It's m y code; I don't want to have to fix any on e else's bugs."

I don't blame you, but keep in mind they are also fixing your bugs. In fact, from my experience a t e am practicing collective ownership will write cleaner code (and presumably therefore have fewer bugs). No one wants to look bad in front of coworkers. If some code is " mine " and no one will see it, I might be tempted to get a little sloppy; not so if anyone can see my code at any time. For proof of this look no further than your guest bathroom. Which do you keep cleaner: the bathroom only you use or the one that visitors are likely to see?



"I don't want anyone else looking at my code and making judgments about my skills, character, upbringing, and soon."

This is a natural fear. The best way over this fear is to write better code. If you always did your best to write high-quality code, any judgments others made would be positive. If you're not confident in your ability to write high-quality code, pair as often as you can with other programmers as a way of improving.



"Development is faster if each person own s one part of the system."

This depends entirely on the time frame over which w e are measuring. If you and I are building a throwaway system over the next t w o weeks, it will indeed most likely be faster for each of us to own one part of the application. If, however, w e are part of a much larger effort and are going to have to maintain the system for the long term, the learning, cross-training, and other benefits of collective ownership weigh heavily in its favor.



THINGSTO TRY NOW
• Pretend that the owner of any critical area is away on vacation and nearly impossible to reach. For a couple of sprints, make the deliberate decision that the "obvious person" is never allowed to take on tasks related to that area of expertise. If the area expert is needed, that expert is available by phone only—literally call the person who is sitting t w o cubicles away.

• The next time you work in code that is difficult to work with, fix it—even if it was written by someone else. If you feel that this is overstepping your authority, ask the original programmer to work with you in making the code easier to use.

Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010