Practice: Collective Code Ownership

[James Shore]

“Collective Code Ownership” is ready for your review:

https://www.jamesshore.com/v2/books/aoad2/collective_code_ownership

Cheers,

James

--
James Shore - The Art of Agile

voice: +1 503-267-5490
blog: jamesshore.com

[Thomas J Owens]

This is a hard one for me since I am still working toward collective code ownership. There's a desire for it, but not all the pieces are in place yet. Just looking at the table of contents, I think this is likely to be one of, if not the, hardest practice for a team to implement. In a scaled environment with one product and multiple teams, it's likely to be even harder. I can see teams able to implement most of the other practices and not fully implemented collective code ownership, and the number of prerequisites makes this clear.  Even after satisfying all of the prerequisite practices, there is knowledge sharing and confidence-building before a team is ready to declare that they collectively own the code. I would suggest adding something to ensure that teams don't get discouraged by this practice. I'm not sure that a team should put the development of other practices on hold to achieve collective code ownership.

Looking at the current table of contents, I'd also suggest reordering where this practice falls in the Collaboration chapter. I'd recommend making it the last section, after pair and mob programming. Pairing is much easier, mobbing is the next step, and true collaborative code ownership is the final stage in how teams collaborate and own their work. It seems to be a very natural progression or evolution of practices and is how I've introduced collaboration in the past. I'm sure there's also room to talk about if the Collaboration section should entirely be moved later, but I don't think that's as important.

I think the introduction to the Collaboration chapter is going to be extremely important for contextualizing the value, but also the difficulty of, all of its practices.

All that said, a very good chapter. The only thing that I don't like is "Everyone on the team constantly makes minor improvements to all parts of the code" and similar lines. It's not that it's a bad thought, but coming from environments with a need for extreme traceability, I tend to focus the improvements on the code directly impacted by the necessary change. Unless it's purely a formatting change (for example, to bring an entire file in line with the most recent code style), I wouldn't make any possible-functional changes outside of the path that I was editing to implement the task at hand. Of course, the environments that this matters in are the exception rather than the norm, so I'm not sure that it's worth mentioning. I think the people who have to care about this can interpret this appropriately for their context.

--
This mailing list is for the open review of "The Art of Agile Development, Second Edition," by James Shore and Shane Warden. Visit the book home page at https://www.jamesshore.com/v2/books/aoad2.
---
You received this message because you are subscribed to the Google Groups "Art of Agile Development 2e" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aoad2+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aoad2/740D5613-9471-424A-9529-33FFF4BA0EA9%40jamesshore.com.

[James Shore]

Thanks, Thomas.

I find it interesting that you say that this is the hardest practice to implement. I see it as the culmination of everything in Part 2 and the starting point for everything in Part 3. It’s very fundamental, which is why it’s the first practice in the part.

If you don’t mind sharing, can you say more about what makes this practice is so difficult? Feel free to email me privately if you prefer.

Cheers,

James

[Thomas J Owens]

I'll share with everyone - it could be useful.

For me, "implemented" in the case of collective code ownership means "anyone can confidently take up work in any aspect of the system". Not only do they not need permission from someone to do the work or make the change, but they also have confidence in understanding how different pieces of the code affect the overall system and can confidently make change without worry about introducing new defects. Just because someone feels safe making a change, if they feel the need to go to a specific teammate to make sure the changes to the implementation, the tests, any documentation, and so on, is correct, I don't think that there's true collective code ownership.

For teams working on a greenfield effort while developing these skills and practices, I don't think it is that difficult, especially if you introduce high-quality automated testing very early. I think it's far more difficult for teams working in a legacy system. I don't think the timelines for learning and performing the practices changes, but I think it would take longer to "fully implement" some of them, including those that are required for collective code ownership. For example, it's one thing to stand up a CI server and start writing tests, but it's another to have enough high-quality tests to confidently make changes. TDD can help introduce new tests for new development while characterization tests can reduce the risk of refactoring, but it could take a while to have enough tests built up. In my experience, "characterization tests" cover the "big things", but not some edge cases, and those edge cases can turn into production fires pretty fast. Pairing and mobbing can share knowledge, but it could take time to get to the whole breadth of the system. Backfilling system documentation is an option, but that also takes away from other work.

On a brownfield application, it could take a lot of effort to discover and share the knowledge across the team. The extreme of stopping development to backfill high-quality tests, documentation, and do the necessary refactoring is something that probably won't happen. The other extreme of neglecting these is far more likely. The right answer is somewhere in the middle, balancing the technical work needed to adapt the system to support agility with ongoing new development. Unfortunately, I've seen it tend to tip more in favor of new development than it should. So even if the new development is good, there are regressions in the older parts of the system caused by missing or low-quality automated test coverage, high coupling, or even exposing new ways to trigger old defects.

I see the two biggest barriers to collective code ownership as high-quality automated test coverage and knowledge across the breadth of the system. It's (relatively) easy to start those practices. It's much more difficult to get them to where they are needed on some legacy systems. I wouldn't be surprised if you talk about this in Continuous Integration, Refactoring, some of the design practices, and maybe Ubiquitous Language and No Bugs. Collective code ownership is something that you want to think about and work toward early, but will likely be something that you achieve later, especially when working with legacy systems.

[James Shore]

Thanks, Thomas.

I think the disconnect is a distinction between “practicing” and “mastering.” All you need to practice collective code ownership is a shared team agreement that everyone can and should work in any part of the code, seeking out and providing assistance as needed. If you’re doing that, you’ve got collective code ownership, as far as I’m concerned.

Even for a team that’s mastered collective code ownership, I think you’re setting too high of a bar. I would never expect anyone to be able to change every part of the system without help. In fact, I expect people to ask for help when working in an unfamiliar part of the code, and to be generous in providing help when they’re asked in turn.

I’ll take a look and see how I can emphasize this better in the text.

Cheers,

James

[Thomas J Owens]

That makes a lot of sense to me. If it's not there already, I'd like to see the idea of practicing and mastering in one of the early chapters (perhaps Choose Your Agility or Invest in Agility - those don't seem to be on the website, so I think I'd need to log in to see the early access on O'Reilly). The three states of "not practicing", "practicing", and "mastering" are good concepts. I'm not sure how you'd define "mastering" or "mastered", but I'd make it simple: another team that is either not practicing or practicing can look to the team that has mastered it for an example of how to go about doing the practice. It doesn't mean that their way is the right way or the best way for the observing team, but they can watch, learn, and see. Mastery isn't perfection, but rather the ability to share the practice with others.

If the placement of this practice is about when you should start to think about practicing, then this chapter's placement is much stronger. I suppose there's room to debate if you should start the practice of collective code ownership before pairing or vice versa. If starting to practice is as simple as the agreement that having collective code ownership is the right direction, then it may make sense to have that agreement early, even to the point of asking why it's not a Focusing practice. The only thing really missing is a few sentences about how this may be an easy practice to start, but it can take time (and a lot of other practices being practiced or mastered) before the team reaches mastery of it.

[Martin Fowler]

Solid chapter, and I agree with the importance of a team taking collective ownership.

There are cases, particularly when developing all this, when teams find it hard to follow the approach of continuously refining the code without any notion of ownership. In that situation weak code ownership <https://martinfowler.com/bliki/CodeOwnership.html> allows people to make changes wherever they need to, but assures someone has the responsibility to keep an eye on each section of the code. I prefer collective code ownership, but I've heard enough indications that weak ownership works well enough that I'd not discount it.

In the second edition of the White Book, Kent changed the name of the practice to "Shared Code". As an old-fashioned XPer, I prefer the original name, but the new name might be worth a mention (although I don't sense that it caught on).

Martin Fowler
https://martinfowler.com

[James Shore]

Thanks, I’ll look at adding weak ownership to the alternatives section.

I had forgotten about the name change. I don’t think it caught on, either. I’ll mention it in the “Sources” sidebar for the chapter.

Cheers,
James

[Bas Vodde]

Hi,

Great chapter! I wish collective code ownership was better understood. It sounds so simple but the impact is huge.

General feedback:

- I felt there could be a bit more focus on creating standard and agreements. And also there could be a bit more focus on the learning from each other through the code and design of others (which is similar as it tends to lead to the agreements and standards)

- I personally discounrage the usage of pull requests for every change because it delays integration and tends to lead to ownership of code. Should/will you mention that somewhere? (pull requests have their place… but IMHO not for every change)

Specific feedback:

- “Collective code ownership means the team shared ..”. IMHO, that would be called “Team Code Ownership” and not “Collective Code Ownership”. In Collective Code Ownership, the people building the product collectively own the code… whether it is one team or multiple teams is not relevant.

- For Egoless Programming, perhaps refer to Weinberg’s Psychology of Computer Programming that introduced this concept.

- "avoid the temptation to make personal judgements about their code.”. You mean don’t judge the person because of the code? I like to think of this as the retrospective prime directive applied to code. Assume that they wrote the best code they could … etc etc.

- In “collaborating without conflict”. In LeSS, we have a practice we call “communciate in code”. It is closely related to continuous integration (the integration part). It recommends people to do an update (git pull) many times a day and everytime first spend a bit of time to see what changes were made (in the part you are working on). That way you proactively discover when working on similar parts… also cross-teams.

- "Collective code ownership is socially difficult. Some organizations have trouble letting go of individual rewards and accountability.”. Individual ownership seems to be also quite much encouraged by CS education.

Thanks,

Bas

[James Shore]

Thanks, Bas.

- I felt there could be a bit more focus on creating standard and agreements.

I have a whole practice on that: the Alignment practice. I’ve tweaked the reference to make it more obvious:

To help the process go more smoothly, decide on important coding, design, and architectural standards as part of your alignment chartering session. When you first adopt collective code ownership, try mob programming for a week or two so you can hash out important differences. Bring up areas of disagreement in your retrospectives and come up with plans for resolving them. Pay attention to team dynamics.

And also there could be a bit more focus on the learning from each other through the code and design of others (which is similar as it tends to lead to the agreements and standards)

I’ve added a bit about this.

- I personally discounrage the usage of pull requests for every change because it delays integration and tends to lead to ownership of code. Should/will you mention that somewhere? (pull requests have their place… but IMHO not for every change)

Agreed—I think I’ll mention this in the continuous integration practice, though.

- “Collective code ownership means the team shared ..”. IMHO, that would be called “Team Code Ownership” and not “Collective Code Ownership”. In Collective Code Ownership, the people building the product collectively own the code… whether it is one team or multiple teams is not relevant.

I don’t disagree, but given that this is a book about team-level work, I think my way of stating it is clearer. I’ve added this paragraph to the end of the Alternatives and Experiments section:

The main experiments I see around collective code ownership itself are in the area of large-scale Agile. Although I’ve described collective code ownership as a team-level practice, it can be applied to any group of people. Large Scale Scrum (LeSS) famously encourages collective code ownership across multiple teams, and Fluid Scaling Technology for Agile (FAST Agile) takes it even further, combining large-scale collective ownership with dynamic restructuring of teams.

Let me know if I’ve mischaracterized LeSS.

- For Egoless Programming, perhaps refer to Weinberg’s Psychology of Computer Programming that introduced this concept.

I haven’t actually read Weinberg’s book yet, although I know it’s a classic. I’ve added it to the list.

- "avoid the temptation to make personal judgements about their code.”. You mean don’t judge the person because of the code?

Yes, that’s what I meant. I tweaked the wording slightly to make it more clear.

Cheers,

James

[Bas Vodde]

Hi,

The main experiments I see around collective code ownership itself are in the area of large-scale Agile. Although I’ve described collective code ownership as a team-level practice, it can be applied to any group of people. Large Scale Scrum (LeSS) famously encourages collective code ownership across multiple teams, and Fluid Scaling Technology for Agile (FAST Agile) takes it even further, combining large-scale collective ownership with dynamic restructuring of teams.

Let me know if I’ve mischaracterized LeSS.

It is ok.

I wouldn’t call restructuring of teams going further though. When restructuring teams, it is actually much more easy to get code ownership-ish then when not restructuring (and working on priority order)

Bas

[James Shore]

Yes, that’s my understanding too. Maybe “goes even further” would be a better phrasing.

[Avi Kessner]

I think you need to be more clear about what "goes even further" means here. Many of the large agile frameworks encourage restructuring teams when needed. What FAST does is continuously shifting teams, which is indeed taking it further, but if one doesn't know about FAST they will think that only FAST suggests changing teams around as needed.

brought to you by the letters A, V, and I
and the number 47

To view this discussion on the web visit https://groups.google.com/d/msgid/aoad2/57927F7A-69D3-47C7-ACFC-14B1CE1F5390%40jamesshore.com.

[James Shore]

I’m planning on discussing FAST in the scaling chapter (yet to be written, but it will go in Part I), so I don’t feel a need to be perfectly clear here. It’s just a brief reference.

Cheers,

James

[Bas Vodde]

Hi,

LeSS actually *discourages* restructuring teams… and going so will automatically lead to more collective code ownership.

Anything that includes team restructuring is likely to lead to more code ownership.

Hence: it should read “FAST does not take it that far because it combines code ownership with dynamic restructuring of teams”.

Thanks,

Bas

[James Shore]

Anything that includes team restructuring is likely to lead to more code ownership.

Can you say more about that? It’s not obviously true to me. Also, how familiar are you with the FAST approach to team assignment and ownership?

Cheers,

James

[Bas Vodde]

Hi,

I wouldn’t call myself a FAST expert :)

Reading the guide, it states "teams dynamically form around work”.

When you form teams around work then people tend to have the behavior to work on the more familiar things. When there is always something in the code you are familiar with, then it tends to become your code and habits of code ownership tend to come back.

When the teams are fixed and they pick up work on priority, there tend to be a bit bigger mismatch between knowledge they have currently and knowledge required. This is often seen as a negative thing in traditional companies but in LeSS considered a good thing. In a way, we want to create a team that can learn together and then can together pick up work they are also not familiar with. The chance that code ownership habits come back becomes smaller that way.

Of course, there is more to it… this is just a simplistic mail description.. in real products it is a fascinating dynamic.

Thanks,

Bas

[James Shore]

I think that’s fair. Real collective code ownership, where people actively improve code they didn’t write, is hard, and I think that difficulty relates to their familiarity with the codebase. The bigger the codebase, the less willing people are to make changes, in my experience, even if it’s well tested.

My experience with feature teams using cross-team collective ownership is that, although they work in parts of the system they didn’t create, they have trouble making significant improvements. Worse than that: they don’t feel a sense of ownership, so they hack in changes rather than taking the time to deeply understand the code. Their code accumulates cruft quickly.

(Perhaps there are things in LeSS to counteract this trend. My experience wasn’t with LeSS explicitly, just feature teams.)

On the other hand, isolated teams without collective ownership lead to a lot of cross-team issues and organizational design problems. The individual teams’ work might high quality, but the cross-team dependencies tend to be a mess.

When I heard about FAST, I was intrigued because I thought its extreme approach to collective ownership might prevent the problems I saw with both feature teams and isolated teams. I asked Ron Quartel about ownership, and he did say that, in FAST, people do tend to self-select into consistent groups. That was somewhat disappointing, but I want to see it in action before I draw any conclusions. There’s a strong emphasis on seeing the whole in FAST, rather than individual team-level work, and it may be it leads to the best of both worlds: the code quality of team ownership and the flexibility and cross-team collaboration of feature teams.

I’ll tweak the wording in the book to avoid implying that either approach is better.

Cheers,

James

[Bas Vodde]

Hi,

re: feature teams. Yes, that certainly happens. But what caused that dynamic? I would argue that it isn’t the familiarity of the code that causes people to hack in changes… and why do they not feel ownership if the code is clearly part of the product they work on ?

re "I’ll tweak the wording in the book to avoid implying that either approach is better.”

Yup! I didn’t mean to suggest either approach as better, just pointed out that the text suggested that dynamically forming the teams is a most extreme version of collective code ownership whereas I think it is the opposite. (not saying antyhing about whether that is good or bad).

Thanks,

Bas