Should SCRUM teams in the same organization share criteria regarding Scrum Process?

The Lean mantra is "variability leads to waste".   

That said, I would defer to each team if whatever they are doing is working for them, and they are happy and consistently providing business value.   

There is benefit in consistency, but nothing outside of the Scrum Guide should be top-down enforced.   Perhaps cross-team discussions can raise transparency and awareness around different team practices, and synergy will naturally evolve through such interactions?

I agree with Tim. It sounds like what your organization needs is to develop Communities of Practice (CoPs) where your teams can connect across the organization and introduce new ideas (re: process, technology, technique, skills, etc) that might be useful to the other teams. You might want to take a look at Jeff Sutherland's approach with Scrum@Scale, where he essentially creates 2 CoPs: one for Scrum Masters and one for Product Owners that he calls the "Scrum Master Cycle" and "Product Owner Cycle" respectively, which can help raise awareness and resolve common organization-wide impediments.

That said, if the larger organization feels that transparency is missing or that the right value isn't being delivered, it might be worth setting up minimum guidelines or criteria that Scrum Teams are expected to follow, but this should also be handled iteratively being very careful when it comes to adding any new process; I typically find that adding new processes are quick fixes for deeper issues, so before a new "process" gets rolled out, it's worth trying to investigate exactly what's motivating the need for that process and seeing if there's a way to resolve that issue within the context of the teams themselves.

Generally, my opinion is that "alignment" is only necessary where there are inter-dependencies between teams and the work of one team is impeding the work of another. You don't really even need Nexus teams to be on the same cadence if you are adhereing to good coding practices and minimizing dependencies between teams.

For example, why does the organization see a problem with some teams estimating Spikes while other teams don't estimate Spikes? Is it because the organization feels that Team A isn't actually delivering value to the organization? Is it out of a concern that Team A's velocity is being compared to Team B's velocity? Is there a lot of churn in Team A because they're spending time on lots of Spikes but when they go to put what they learned into practice they discover things have changed, so they're rehashing work?

Is there an organizational Definition of Done which would require teams to adopt similar practices in order to assure that the standard is being met?

Are the teams functioning as a Scrum Studio, where terms and conditions of use ought to be consistent?

Hi all! First, thanks for the time and valuable feedback!

I think both Timothy and Kevin feedback comes from the same root, enhancing CoP practices and increment teams communications could help, I'll take a deeper look on the mentioned Cycles of the Scale guide, thanks!



Answering Kevin last comment, I don't think the organization is going to use it as a measurement or compare tool between teams, they are not questioning for example Team A capacity of delivering ( at least at the moment haha ), I'm just afraid that establishing this common guidelines could eventually lead to something like that in the future, or for example, when a higher management level get involved, I'm not sure if the guidelines will at the beginning help bring transparency to the organization, but at the end become a bear trap for all.

Right now this is coming from a place where teams share the same technical infrastructure and share some common resources, one team (the one estimating spikes/bugs/environment fixes - maybe spikes only was not the best example) is absorbing the impediments in their velocity and the other one is not. So for the management, is pretty clear how much is a general organizational impediment impacting Team B but not that clear on Team A, being the same impediment. 



Ian, I'm unaware of the Scrum Studio, I will check it up and let you know! And no, each team have its own definition of done, but they are very similar to be honest!

Thanks again!

Andy

I'm not sure if the guidelines will at the beginning help bring transparency to the organization, but at the end become a bear trap for all.

A real-world example of exactly this occurred at a previous client of mine. They were a large enterprise, and in the year or so before I got there, in the name of "transparency" they decided to define a set of statuses and several complicated reports that teams needed to compile every week. These statuses were extremely non-intuitive, were different between the different PBI types, and got in the way of good practices. For example some of their statuses included "Committed," "Accepted," "Resolved," "Done," and "Closed" which all meant different things -- none of which were what you'd expect. "Blocked" was its own status, which caused PBIs to get shoveled off to the side and forgotten about since it didn't count toward the team's In Progress WIP limit; it made it really hard to train the team to slow down and actually push work to completion, since anytime a minor impediment came up it just became "Blocked" and they moved onto the next thing until someone pressed them to finish it. We couldn't change this to better suit the team's needs because we were locked into a decision made a year earlier that hadn't been re-assessed. I spent a good portion of my time there trying to fight an uphill battle to get that changed.

So for the management, is pretty clear how much is a general organizational impediment impacting Team B but not that clear on Team A, being the same impediment. 

This strikes me as the real issue right there. Sure Spikes may not be the right example, but if it's more about the impediments faced by Team A not being transparent to the larger organization, then yes, that absolutely is a concern. You're right that I would encourage fostering CoPs. You could start by taking a page from the Nexus Retrospective, and see if you can occasionally have a multi-team Retrospective-like event even though they're not working on the same product. If it were me, I'd ask each team to send an appropriate team member (others could attend optionally, although you may want to limit it to 1 or 2 people/team initially as a test,) and and have them come prepared with topics the rest of their team wants discussed/raised -- the outcomes from this event might naturally ignite the forming of these CoPs rather than forcing it on them. Fortunately you've only got 3-5 teams, which would make an event like this pretty quick to coordinate, and even though they're pretty decoupled you could still take some of the good bits from Nexus and other scaling frameworks. 

If you get a large number of people (say more than 12 if you open it up to more than just 1-2 reps from each team) you may want to have them break into groups for smaller discussions on the raised topics (because it's hard to have a productive discussion with more people than that) and have the groups come back to contribute the identified "Next Actions" necessary to improve. Check out "Open Space" and "Unconference"-style events to see if you can borrow some of those elements and incorporate them.

I hadn't heard of Scrum Studio either. Thanks for that, Ian; I'll have to give it a read as well.