Ownership between Communities of Practice and Feature Teams

Should the CoP lead (or other members of the CoP for that matter) have the authority to gate the change if they don't approve upon review? How about the scenario where they fail to offer review input until the last day of the feature team's Sprint? 

Never mind their perceived authority. Shouldn’t the CoP have a clear responsibility to ensure that this situation doesn’t happen? A CoP, like any other organizational group or function, ought to facilitate the progress of Scrum Teams.

In order to help manage this, a CoP may choose to put transparency over their work by means of a backlog. They should order it in such a way as to smooth the progress of teams so development and delivery is not put at risk. They may facilitate the emergence of architecture by provisioning just enough architectural runway for example.

The less work that is actually done by a CoP, and the more that is done by Development Teams themselves, the better. Ideally a CoP should do no implementation work at all, and will concentrate on facilitation, transparency, guidance, and oversight.

In your case, if the system you refer to can in any way be seen as a product, then it might be useful to reconsider the problem in terms of a Nexus.

Thanks Ian. I'm a bit confused by your question, "Shouldn't the CoP have clear responsibility to ensure this situation doesn't happen?" To ensure which situation doesn't happen? Does it not make sense for the CoP to be involved on code reviews despite their concentration on guidance and oversight? 

Thanks for clarifying that a CoP backlog is not out of the ordinary, and at the discretion of the CoP. In the case where a CoP backlog is set up, it seems natural that those backlog items would be implemented by the CoP (rather than feature teams). Do you agree?

Why is it better to have less CoP work than feature team work? I'm not disagreeing with you there, as I understand that to be what agile textbooks seem to say, but I'm struggling in practice to see how CoP work can be avoided. Regarding the example I gave about migrating the underlying API framework, is it reasonable to think that could somehow be divided across feature teams? Or is that a good case for a CoP backlog item that is worked by the CoP?

In Scrum, Development Teams ought to do all of the work needed to create increments. A “Community of Practice” or other body shouldn’t do any related work unless it is also a Development Team, and can collaborate with other teams in resolving any integration dependencies.

If a CoP or other body is not a Development Team, then their responsibility must be to facilitate, smooth, and enable the work of those teams. They should not do anything to impede that work. If they are required to give authorizations, or gate changes, or otherwise put work in delay then that would be contrary to good Scrum practice. A CoP may give advice and guidance, and its members may also be members of those Development Teams through which the work is done.

Thanks again for the response Ian. I am beginning to think our organization is using the term, "Community of Practice", inappropriately here. And I wonder if that is also throwing off our conversation a bit here. I'm not sure there's a textbook term for what I'm describing here, but would "shared service team" be more representative? And more importantly, does that then change the nature of our discussion here? 

I suggest reviewing the Nexus Guide, in so far as shared services might represent integration dependencies between teams.

Maybe its best if you describe what thos shared service teams do and who is on those teams. That makes it more likely we're all talking about the same thing. ;-)