Giant team with no chances to get splitted
Hello everyone, hope you're doing great.
This is my first post in the community I just got here looking for help/advice, so I hope this is the right place :)
I'm working as a Project Manager for an importar client, and we're facing some issues. Right now, we have a giant team (33 team mates). The chances to split the team are really low (the client doesn't want us to).
We have around 8 Frontend devs, 5 backend, 9 QAs, and the rest of the team are leads, dba, mobile apps.
So far, I could got to split the team into :
- Mobile - They operate really apart of website so I have them in a separate team (separate dailies and ceremonies)
- Automation - They are 4 of the QAs, but they automate past our sprint so it was easy to split them also with separate ceremonies.
- Rest of the team - And here is the problem where the client doesn't want us to split.
Given this rest of the team, we have two things: Transformation of the site, and legacy code. 3/4 parts of the work is usually for the transformation (A clear Scrum project), and the rest is legacy work (production issues, bugfixing and ocassionally some features).
The client doesn't want to split the team because if for example one day there's no support work, they can help on Transformation. This ends up in several issues:
- We're never able to estimate properly and complete what we plan for a sprint. Because while transformation is a scrum project, the legacy one should be a kanban, so mixing this gives us several problems.
- Dailies with more than 20 people sometimes. We have two dailies, one for legacy and the other for transformation, let's say people join them given what they're working on. Sometimes we have dailies up to 20-30 minutes. I'm pretty sure at the end of the meeting the first that spoke is not listening.
- The client introduces no planned tickets in the middle of the sprint (making us put apart what we've planned and then complaining because of us not achieving what prommised).
Besides all this problems and I'm pretty sure I'm forgetting many, we're having a lot of problems with the retrospective meetings. No one on the team likes to try games on retros, or new kind of retros, everybody starts complaining. So we're always doing the tipycal retro, what went well, what went bad, what could have been better.. But among 33 people, only the same 7 or 8 guys are always speaking. People is not participating, sometimes they are shy, sometimes they don't pay atention I guess. We need to find a way for retrospectives to be more useful and with results. So far we're always relying on the same issues and complaints never getting fixed.. I've read some topics about post mortem meetings but I'm not sure how to face them, I'd appreciate youre advice.. I have just 1 year and a half of experience and this enormous team is being a great challenge to me.
Thanks in advance to everybody participating on this topic :)
Regards,
I'm working as a Project Manager
Given that Scrum doesn't have a Project Manager role, is Scrum fully implemented and respected? If so, what is your relationship to the Scrum Teams? More specifically, have they reached out to you for help, or are you seeing a problem and reaching out to help them?
When it comes to team size, I always think of this image, where as team size grows, the number of lines of communication grow exponentially.
How can 33 people be acting together as a single team? They will almost certainly form implicit sub teams or find other coping mechanisms to survive in such an environment.
It sounds like there's a lack of self-organization, and potentially as though there is insufficient trust to allow people to do this.
I also wonder if there is an emphasis on utilizing everyone, rather than focusing on the collective result that 33 people would be able to achieve. The goal shouldn't be to have 33 tired and busy people, but to maximize the value that's generated, with as little unnecessary waste as possible.
Would the Development Team be willing to split into multiple teams, and have each team accept accountability for a certain area or outcomes, in exchange for greater autonomy? Would management be willing to sponsor such an initiative?
How would the Development Teams arrange themselves if they were given total freedom, or at least freedom within a set of guiding principles? Here's an example of how one company did something similar: https://www.youtube.com/watch?v=bzTS-5c-UfQ
3/4 parts of the work is usually for the transformation (A clear Scrum project)
I'd suggest that, in truth, clarity about Scrum is lacking. Is there a Scrum Master who can manage people's understanding of the framework, and its purpose, and help them to implement its roles, events, artifacts, and rules?
Hello Facundo,
I would suggest to split your Transformation Team up in smaller Scrum Teams working on 1 Product Backlog.
Look at the Nexus Scrum Scaling framework for this: https://www.scrum.org/resources/scaling-scrum
This would reduce your communication lines between Scrum Team members drastically.
Secondly you have to get your Lecagy Team interconnecting with your Nexus Teams. You stated that your Lecagy Team is working/should work in Kanban and at the moments your Lecagy Team works on Transformation items it gets messy combining those two frameworks.
May I suggest a compromise of letting your Lecagy Team work in a Scrum environment that supports Kanban.
https://www.scrum.org/resources/kanban-guide-scrum-teams
https://www.scrum.org/resources/suggested-reading-professional-scrum-ka…
Third, since Lecagy and bug fixing can and will bring always an undefined amount of work per Sprint, you can't really plan fill that team's Sprint Backlog in an accurate way, so Scrum with Kanban would be a good solution. The Team can pull work items in from the Product Backlog (in accordance with the PO and the Sprint Goal) or from the Sprint Backlog of the other Nexus Teams when those Teams need additional support in getting their work items done (again in accordance with the PO, but only for work items that have not been started on, else you get again communication cluttering)
Hope that this helps you.
Hello guys,
First of all, thanks for dedicating your time on reading my question as long as it is.
-Simon, I LOVED the image. I can't even imagine the lines for 33 , the image explains cristal clear our problem. Regarding the not support for the project manager, I have to say I'm playing the role of scrum master as well. They call it project manager here as we also follow many other stuff for the project. Anyway, no, Scrum is not fully implemented or respected, that's impossible here as long as legacy and transform are mixed and they nature are so different, or that's my understanding, correct me if I'm wrong. Given the splitting for the teams, many issues on that. For example, the backend team leader doesn't want his team to be splitted because some tasks are more boring than others and he wants everybody together being able to catch any task. Also, every task is very connected with the others that makes us difficult to split. I've been thinking on this so many times, splitting by disciplines fe-be-qa, splitting by features, splitting by methodology. Really liked your point of view so I'm very open to hear more from you :)
-Ian, so far that's on me but it looks like I'm not hitting the point. We're going to implement a delivery manager position who will be in charge of processes definition as you mention.
- René, your point is very interesting, too. That's my biggest deal, to split the team. But I have so many blockers, initially from my manager. I will really look into scrum with kanban it looks like a very good oportunity. My concern is if you pull from any of the backlogs, how you plan for next sprint when everything is priority from both backlogs?
THANKS EVERYONE :)
Hello Facundo,
Nexus Guide: https://www.scrum.org/node/4709
With the Nexus you are scaling Scrum by splitting a lot of developers up in workable Scrum Teams (max 9 persons/team) which all work on 1 Producr Backlog. The Nexus is a framework that weaves together the work of 3 to 9 Scrum Teams that work from 1 Product Backlog into 1 Integrated Increment.
On your question to me:
1) Work Items are pulled from 1 backlog for all the teams that work in the Nexus
2) An additional Nexus Sprint Backlog is created from all the Work Items of the individual Scrum Teams to highlight the dependencies and the flow of work
3) All the individual Increments are integrated into 1 global increment. The Integrated Increment represents the current sum of all integrated work completed by a Nexus.