Saturday, May 21, 2005

Situational Ownership: Code Stewardship Revisited

I had some interesting feedback on my previous blog-entry about Code Stewardship. Most apparent was that I 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.

I am at a loss for what to say other than that is not at all 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 I would have been better off saying more about how Peter Block defines stewardship in his book of the same name (Stewardship: Choosing Service over Self-Interest, see an interesting review here and another one over here):
  • 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 I would expect stewards to have a more direct role. And I believe 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.

I beleive 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 appropiate situational leadership-style, the outwardly visible result may appear to transition from individual code ownership, to code guardians/gate-keepers, then code coaches/counselors, and finally to truly collective ownership.

So I would say it is the presence of stewardship which is the key to succeeding with either individual code ownership or collective code ownership. If stewardship is present, then both can succeed; If it is absent, it's likely that neither will succeed. And the collective and individual "styles" are the extreme ends of the spectrum, with "code counselors" as the style in between those two extremes.

5 comments:

Johanna Rothman said...

Brad, thank you. You gave me the words I've been having trouble articulating.

Brad Appleton said...

Thanks Johanna! That's quite an honor coming from you (I've been a fan of your writings for several years now).

Admittedly, Ive been having trouble articulating those words too, and am still struggling (but hopefully learning and improving with each struggle). Now I guess I'll see what ahppens as a result of this one :-)

Carlton said...

After collective code ownership fell out of favor in one organization I was part of, I was tasked with setting up a "stewardship" model. While it avoid many of the issues that you described with ownership and control, it was not set up to facilitate knowledge transfer. "Stewardship" was a tool for management - they wanted to quickly know who was responsible for what and know who to assign bugs to.

Brad Appleton said...

Hi Carlton! Thanks for relating your story. Sounds like your management was chiefly concerned with tracing accountability (moreso than authorship or knowledge-transfer). Interesting that the stewardship model was able to meet that need. I wonder if it actually did help facillitate knowledge-transfer? (despite not being setup for that purpose?)

Gopal said...

This is a familiar situation in offshore projects. In most situations this is caused by attrition. The difficulty we have is people using that as an oppotunity to pass the buck ("I didnt write the code, I am merely looking after it!"). Getting them to really own code is very a big task. Also this is more of an issue in Agile methodologies where the documentation is given a go by. Of course the real good developers write good documentation irrespective of the kind of project, but to get everyone to do it is again an issue ("but it is very obvious what I am doing here, why write 2 lines of comments?").