Balancing Individual versus Collective Code Ownership


This can be accomplished by pairing with the code-steward, or simply by seeking them out as an FDD programmer would a Chief programmer/architect. The code-steward is like the "editor-in-chief" of the module or class. They do not make all the changes, but their knowledge and expertise is still applied throughout. The benefits are:

  • Concurrent changes can still be made and wait-times avoided while still permitting notifications and coordination
  • Knowledge is still disseminated (rather than hoarded) and spread-around the team
  • Collective ownership and its practices, such as refactoring, are still enabled
  • Pair programming can still be done, where pairing assignments can be based in part on who the "steward" is for a piece of code. (At some point stewards can even hand-off-the baton to another)

The bottom-line is that collaborative ownership and authorship is still essential. Code ownership isn't supposed to be solely about controlling concurrent access (and is very suboptimal as a concurrency-strategy, even though some merge-a-phobic shops will swear by it). Code ownership is also about safeguarding the integrity and consistency of the design and implementation, and also about disseminating knowledge of the owned module/class, as well as knowledge of practices and patterns for its succful "care and feeding." If we take "ownership" to either extreme, and keep it there—the result is impractical and imbalanced.

When Brad presented the notion of Code-Stewardshop on several agile forums, he received a great deal of feedback. Most apparent was that he had utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from whom others must acquire some "write-token" for permission to edit a class/module.

That is not how it works. The code-steward serves as a mentor and trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about receiving knowledge and guidance:

  • The purpose of the protocol for consulting the code-steward is to ensure two-way communication and learning (and foster collaboration). That communication is a dialogue rather than a mere "token" transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!

Perhaps a better way of describing it would be the way Peter Block defines stewardship in his book of the same name Stewardship: Choosing Service over Self-Interest

  • Stewardship is being accountable to the larger team or organization by "operating in service, rather than in control, of those around us"
  • "We choose service over self-interest most powerfully when we build the capacity of the next generation to govern themselves"
  • Stewardship offers a model of partnership that distributes the power of choice and resources to each individual
  • Stewardship is personal—everyone is responsible for outcomes; mutual trust is the basic building block, and the willingness to risk and be vulnerable is a given
  • Total honesty is critical. End secrecy. Give knowledge away because it is a form of power

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!