Where to start.....
Ok, I've just joined a company that needs a lot of work around it's scrum process, as it's been very dysfunctional for a very long time.
I'm (temporarily) acting as scrum master, although we have a req in to hire someone for this position full time. I'm the software architect officially.
We have several teams. 1 consulting team in a european country, one consulting team in an asian country, and one FTE team in the US. The US team is just getting started, and I'm in the US.
The first problem we have is that the previous scrum master micro-managed everything. I'm trying to unwind that, but the teams have been trained to ask for permission to do anything (consulting firms often have this mentality anyways), and the time difference makes this really problematic. I'm trying to get them to operate more autonomously.
There was a daily standup "call" at 8am in the US, which was the end of the day for the other two teams. This was painful in a lot of ways, as it was the scrum master going round asking each member what they did, etc.. With a screenshare of the work items as they were read off. To me, this was beyond pointless because it didn't help us that much, and it didn't help them at all (particularly being at the end of their day). So i've started to have them post their daily standups to a wiki... which allows them to do it in the morning...
The problem here is that we lose a lot of the "in person" communication with this, and it's really easy for people to just ignore each others work, thus not truly getting any benefit from the "standup".
There are about 16 people in the european country consisting of back-end, front-end (web, mobile) developers, and "manual" testers. The Asian team consists mostly of testers, both manual and automated test developers. About 6 people.
The US team consists of 3 people (me, and 2 front end developers). There are also BA's, a UI/UX designer, and consulting team managers in various places.
So my first task is... how do we make the various scrum meetings work for us? Being in 3 different time zones, with only a small amount of time overlap. how do we manage to do standups effectively, how do we do backlog refinement, and planning asynchronously?
I have more questions to ask, but let's start with this one.
This is interesting... some clarifying questions I have around this...
Are all 3 teams having a Daily Scrum together? It sounds like it would consist of over 20 people on a call. What was the reason for bringing them all together at once? Dependencies? Integrations?
Were you able to know from the previous scrum master as to why the daily scrum is for all 20 and not divided?
Just break it "peel the scab" right off but explain why. I am dealing with similar issues like that now. They are kicking and screaming all the way.
So my first task is... how do we make the various scrum meetings work for us?
I’d suggest the first task is to establish how well the “team” collaborates outside those meetings. Team members ought to collaborate throughout the working day. If issues are being exposed in events like the Daily Scrum, you may have evidence of a deeper dysfunction which should be addressed. Faking teamwork by shoehorning it into particular events may be tempting, but it will not prove rewarding.
Thank you for the feedback. To answer the questions:
We do seperate our Automated QA team members into a separate scrum. However, our manual testers attend the development scrum. This does result in about 22 people total on the call (including PO, SM, and occasional other stakeholders)
As for why, the usual reasons.. trying to use the scrum for status reporting, using the scrum for dissemination of information, general control issues... all things i'm changing.
The individual teams in locations collaborate well. They do not collaborate well across locations. The problem is that as we grow teams in other locations, we need to keep those team members in the informational loop a scrum creates. So, for example, a BE developer in the US should be aware of what the BE developers in Europe are doing, and a manual tester in india should know what other manual testers in Europe are doing. This is the problem i'm trying to address right now.
Front end teams need to know what back end teams are doing, testers need to know what everyone is doing, and this is what has created the large headcount on the call. How do we keep everyone informed of everyone else's work if this creates too large of a scrum call?
Certainly, we could have FE and BE and Mobile devs all have different scrums, but that loses a lot of information in my view.
Of the 22 people on the call, 3 are BA's, 1 is SM, 1 is PO, 4 are manual testers. That leaves about 13 developers, which is large I know (9 being the max suggested). But I don't know how to reduce this as the team is very tightly integrated in their duties (they all work together on various parts of the code base). They're working on 2 different projects (a v2 and a legacy), some are devoted to v2, and only a small number work on legacy, but all of those legacy developers split their time with v2 as well.
Maybe you need to consult with your manager and see his opinion on how to split the team.
Or split them between the 2 projects? And then have a representative on each team to provide each other updates? You can also look into that 2 projects and see if you can divide them into features or modules to have an even smaller team.
IMO, 22 people talking/sharing information for 2 minutes during daily scrum is already 44 minutes which is too long.
Is this just for ease of use for you or the teams. I sense more afoot here. DSU's are not for anything other than a daily feedback loop for what happened yesterday and plan today. DSU is the most widely misused ceremony I see and this is a good example.
"So, for example, a BE developer in the US should be aware of what the BE developers in Europe are doing, and a manual tester in india should know what other manual testers in Europe are doing. This is the problem i'm trying to address right now." Why is their a release train, are there dependancies what is the need for this?
"Front end teams need to know what back end teams are doing, testers need to know what everyone is doing, and this is what has created the large headcount on the call. How do we keep everyone informed of everyone else's work if this creates too large of a scrum call?" Again why?
You don't have to answer all my why's but you might consider my suggestion below.
But here is what I am suggesting. If you have that much going on it sounds like you could use Nexus scaled scrum. If you are making improvements you might as well look into it. Just read the guide. Maybe not implement the entire thing just parts of it.
@Tim I'm not sure what you mean by a release train.. Right now our releases are largely built manually, although my intention is to create automation processes here so that we are doing CI/CD (There are some questions i need to figure out around using a Pull request process where there is code review prior to merge, and how that would work in a CI/CD world, but that's a totally different issue).
If by "release train" you mean all the tasks are completed and the last day or two of the sprint is used to build a release, then I agree it's not a great situation. In particular, it creates the situation where people are "done with their work" for the sprint, and they have to start working on the next sprint early.
That DSU "feedback loop" is what i'm referring to about "people needing to know what each other is doing". I struggle with this, because on one hand, if a DSU is valuable to a few people, why isn't it valuable to others who are involved in developing those features? I mean, i've heard so many reasons why a DSU is important, but it seems to be contradicted by the idea that consumption should be limited.