Should SCRUM teams in the same organization share criteria regarding Scrum Process?
I have an open question for debate for anyone who wants to contribute!
Context: Applies to an organization of 3-5 Scrum teams, but each working independently (different domains of the product) and they have their own releases (meaning by this that is not an Nexus or Scrum of Scrum case because there is no need of an unique release after an iteration and they don't even have their sprints synched). But, they share same organizational impediments, estructure and general resources...
As we know, each of these teams should have freedom over their process, they have different workflows due to their individual context, they have of course their own scoring scale and understanding of Story Points, their own way of doing Scrum Meetings, etc...
Question: where this ownership of the process stops, and where should be an alignment (if any) between them?
-Team A likes to estimate Spikes or Analysis tasks and score them with SP, because their understanding of SP is wider than the complexity of something that generates value trough working software, and is more effort related. Now this is debatable because reduces transparency and pumps up Velocity, but is working for them, so its allowed, and they have ownership of their process.
-Team B on the other hand doesn't estimate Spikes or Analysis tasks with SP, they time-box them and reduce availability (or Dev % Capacity, if you may) for taking it in consideration during planning, or report the capacity drop as and impediment if it happens during a sprint. This also works for them, and is also a better practice in theory because it favors transparency and help the organization identify properly general impediments.
With this in mind, should SMs establish a certain general criteria regarding this kind of things in order to keep a more transparent environment or could this be the first stone that lead to eventually falling into anti-patterns like team performance compares (even if the shared different Velocity scales)? Is there any good practice already stablished for this scenarios? Should the organization set a common criteria regarding what should be scored or what shouldn't?
Thanks! Looking forward to hearing your opinion!
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!
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.