We have 6127 guests and 11 members online

Agile Sponsors

HP

CollabNet

TechWell

Home > Blogs > Featured Blogs > Brad Appleton's ACME Blog > Assigning Code Ownership-Policy Ownership

Assigning Code Ownership-Policy Ownership

 E-mail
Written by Brad Appleton   
Wednesday, 25 June 2008 18:45

Jurgen Appelo has an interesting article on StickyMinds entitled "Code Ownership Re-Visited"

Jurgen prefers the term "artifact assignment" rather than "code ownership" and explains there are 4 methods of artifact assignment:
  1. Local Artifact Assignment (LAA) delegates policy to subsystems and subsubsystems (etc.)
  2. Authoritarian Artifact Assignment (AAA) assigns change/access-control access-control of of ALL related artifacts to a single individual "benevolent dictator" who approves/authorizes all changes and who may also assign individual change-tasks to developers
  3. Collective Artifact Assignment (CAA) assigns the whole team (rather than any one person) as collectively accountable for all its artifacts
  4. Individual Artifact Assignment (IAA)
He also provides a nice set of criteria to help decide which policy to use.

This seems very different from the 4 kinds of ownership I described in "Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership" where I define what amounts to Non-Ownership (which can sometimes be the result of Dictatorship), Individual Ownership, Stewardship, and Collective Ownership and show how each maps to a corresponding leadership-style of the Situational Leadership Model.

So what gives? What explains this difference?
  • I think Jurgen would probably consider Stewardship as a weak form of Individual ownership (many others would too, though I staunchly disagree for reasons elaborated in the aforementioned article).
  • Authoritarian Assignment would be akin to the form of Non-Ownership that results from Dictatorship (or "director-ship" to be more precise) where assignments are made per modification/tasks by a director (or "benevolent dictator")
  • I would argue that the first two methods Jurgen describes above aren't really artifact-assignment policies, but instead are assignment-ownership policies: They're not so much about making a decision among ownership-policies as they are about making a policy for ownership decisions. Rather than deciding "who should own which artifacts", they decide "who should own the decision" to make such artifact assignments.

In other words, the first two policies Jurgen defines are about decision-rights to assign modification-rights to owners, and not about the modification-rights (or ownership assignments) themselves. As such, it raises an important point taken for granted in my article and in so many other discussions on this topic. Most of the prior discussion probably has assumed that the decision about which ownership-policy to adopt was made either "by the team" or by the team's "leadership" (that might be a manager, a technical-lead, a project-lead, or any combination thereof).

Another common assumption is that such ownership is defined along "architectural" boundaries such as individual artifacts/files, classes/modules, or packages, components and subsystems. Other possibilities are:
  • Functional boundaries (e.g., by feature/feature-set, story/theme/epoch, or use-cases)
  • Project boundaries (e.g., work-breakdown-structures, tasks, activities)
  • Role/discipline specialization boundaries (e.g., requirements, tests, models, database, UI, programming-language, user/help documentation, etc.), and even ...
  • Configuration/variation boundaries (e.g., version, variant, branch, platform). In fact some of these stretch across multiple dimensions of a project/product and might even be used in combination.
With Agile development, the emphasis is to break-down communication boundaries and any corresponding separation related to role, or phase, or physical boundaries and to instead prefer customer-determined boundaries of "scope" and "deliverable value" (e.g., stories, features or MMFs, use-cases, etc.).

So you will see a definite (but time-constrained) assigning of things like tasks to owners and stories (though the "owners" sign-up rather than "being assigned"). Those kinds of boundaries encourage closer and more frequent communication rather than separate & isolated (and less frequent) communication.

In the end, with Agile methods, it's all about maximizing learning and knowledge sharing & transfer rather than compartmentalizing knowledge into pigeon-holed roles and responsibilities. One opts for "separation of concerns" without "separation of those concerned" (work is isolated and separated, but not people).

Posted: 2008-06-26 01:45:00

Read Full Article

Trackback(0)

Comments (0)Add Comment


Write comment

feedShow/hide comment form

security code
Write the displayed characters


busy
 
Cialis

Agile Marketplace - Announcements and Special Offers

Upcoming Webcasts
Sponsored by Urbancode - On Demand
Mastering Complex Application Deployment
Sponsored by CollabNet - Wednesday, August 24, 2011
Closing the Agile Loop: Continuous Integration, Continuous Information

ScrumWorks Pro – The World’s Best Agile Project Management Tool
Simply put, CollabNet’s ScrumWorks Pro is the best Agile project management solution on the market, bar none. More than 150,000 Agile professionals rely on the power and simplicity of ScrumWorks every day.  But don’t take our word for it – try it yourself for free. CollabNet is now providing the first 10 users of ScrumWorks Pro at no charge!
Download ScrumWorks Pro today!

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper