How to best support Scrum with distributed team half way through a project
Hi all,
I've been a scrum master with mostly co-located teams for 10 years and am trying to figure out how to best support a team that is new to scrum. The team is distributed, 2 devs sharing an office on east coast, 1 qa in another location on east coast and the other with me on the west coast. Product owner and BA/Dev manager are remote but in same time zone. The other team member is a Project Manager that's a contractor hired by the executive team since this team was unable to deliver a product. (no fault of their own)
So, it is light years away from the co-located self organizing team that scrum espouses. We're about 2 sprints in and I’m getting push back on being too rigid on sticking with the time boxing and the ceremonies that go with scrum. They want to keep doing scrum but want do it "loosely" since they are half way through the project and believe they need to build up to doing scrum. But from what I've learned from my experience sorta scrum does not work, that the team needs to be able to commit to work and the process to get to a state of being clear on what the need is and predictive on what they can deliver. If it doesn’t work then Kanban is a good process to use to keep focus, etc.. I suggested this and it was not well received.
Am I being too inflexible? Have others been able to have “flexible” scrum and have it work? If so, how? The other advice I can use is how to best facilitate a team when you can’t see them. I was surprised at the reaction to my Kanban suggestion and think that if I was in the room with them I would of done a better job of reading reactions and handling it better than I did. I came across as angry or frustrated when I was trying to do the job of enforcing the scrum process. Video calls aren’t the norm, we do them for retros and that’s it.
Advice welcome!
-Karen
When they said, they want to do scrum but want to do it "loosely", does this mean, they do not want to commit anything?
The other team member is a Project Manager
I guess you are not referring to the Scrum team here right?
the team needs to be able to commit to work
Commit to the Sprint Goal you mean?
Reading your post, first thing that jumps in mind is to be strict in coaching and flexible in Scrum at first.
So, if a Daily runs into 16 minutes, but there is value in the things that still need to be shared, I personally do not have a problem with new teams to extend a bit beyond the 15 minutes, but educate and coach them on why te timebox is there and how to stick to the relevant parts. Inspect where to improve, so you can be more strict on the timebox later on. For me personally, I prefer less strict Scrum and more coaching with new teams. It will solve many problems very fast, and you give the team confidence they can (learn to) improve. Being strict about "the rules" when the basis is not taught yet, could put yourself in aposition where you are seen as a dicatator instead of servant leader.
Also, colocation is always better than seperation. Video calls can be a good alternative but still you are missing out on some parts. If it is something you cant change, inspect and coach on how you can make the best of it all together.
Two questions
1) What was the rationale for trying to do Scrum halfway through the project?
2) What part of the Scrum Framework is the team having a problem with?
We're about 2 sprints in and I’m getting push back on being too rigid on sticking with the time boxing and the ceremonies that go with scrum.
Who wants Scrum to be implemented in this organization, and why?
Thanks everyone. Team is doing scrum for a few reasons. First, outside consultant was hired and said to. Second, it works for other teams here that I support. The leadership here isn't convinced that scrum is the solution, especially our technical leadership. I've been acutely aware of the lack of support from above and it's impact on continuing to do scrum here. This is a big part of the problem and I continue to forge forward since I know it works.
Team, specifically the Development Manager/BA is pushing back on planning and sticking with 2 week time boxing. Part of it is being over committed to other work. e.g. sprint starts tomorrow and she doesn't want planning since she's can't take the time since she's working on a training for developers. Some of these developers are on our team and they too don't want to plan for next sprint since they don't have time. They also didn't plan for last sprint due to being unclear on requirements and having to rework the first sprint. So you can see why I'm reaching out here. :)
I can let things play out and see what happen, inspect and adapt. Or I can suggest, which is what brought me here, that we do planning anyway but more along the lines of lining up stories on the board that may not of been groomed with points. Or even create stories that are placeholder research stories, or something to indicate what the team should work on.
-Karen
Team is doing scrum for a few reasons. First, outside consultant was hired and said to.
^^^ Not a good reason to do Scrum....as I'm sure you know.
It sounds like between the Dev Team and Leadership you have quite the challenge ahead of you.
If you truly feel Scrum is a good approach for the context, rather than being to rigid with the framework you may want to step back and look for areas where it can help to solve existing problems that the team is facing for some quick wins.
For example, the team feels they can't plan because they're over committed to other work...a pattern that I'm guessing has been around for quite some time. Is that a failure of Scrum...or factors and behaviors within an organization that have yet to change?