Balancing Individual versus Collective Code Ownership

• 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

When practiced properly, collective code ownership is in fact an ideal form of stewardship (but not the only form). Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group of people. However, early on we expect stewards to have a more direct role. The form of code-ownership that Feature-Driven Development (FDD) practices may seem fairly strict at first, but is really intended to be the initial stages of code-stewardship in the first two quadrants of the situational leadership model.

We believe the form in which stewardship should manifest itself is situational, depending on the skill and motivation of the team and its members. In Ken Blanchard's model of situational leadership , there are four quadrants of leadership-style, each of which should be used on the corresponding combination of hi-lo motivation and hi-lo skill for a given task:

• Directing (hi directive + lo supportive, for "enthusiastic beginners")
• Supporting (hi directive + hi supportive, for "disillusioned learners")
• Coaching (lo directive + hi supportive, for "reluctant contributors")
• Delegating (lo directive + lo supportive, for "peak performers")

If we apply the concepts and principles of "stewardship" using the appropriate situational leadership-style, the outwardly visible result may appear to transition from individual code ownership,