Are this variations of SCRUM ok?
Hello, I´m software developer in a scrum team. The problem is, that only one developer got a scrum training and I think we work wrong. So I have a few questions if our variations of scrum are ok.
1. Every sprint, we vote for assigning all tasks to the developers. So that all developers have enough work for the next weeks in sprint. The result is just enough for not assigning. But would be the assigning for all tasks of next sprint a valid variation? I´m an enemy of assigning.
2. Our Scrum team are (without Scrum Master and PO) 12 people with a sprint of 4 or 5 weeks. What would you say is the best size for 12 people and the best weeks in sprint?
3. Our Scrum Master change the project. So we need a new SM. We consider to change the scrum master all sprint, or all 2 sprints in the scrum team. Is this variation ok or is a fix Scrum Master the better solution? (Of course every team member need scrum training)
Thank you very much. Sorry for my bad english. I try to get an inhouse training for the whole team in future.
> But would be the assigning for all tasks of next sprint a valid variation?
You seem to be saying that the team collaborate (vote) in order to decide which team member will progress which tasks. If that is the case then yes, it is a valid implementation of Scrum. A Development Team, during Sprint Planning, are allowed (but not required) to do exactly that.
However, it is generally a better practice to plan "who does what" at a daily level (i.e. in the daily stand-up). This is because such fine-grained planning decisions have a tendency to be volatile...a given team member could be sick, or helping someone else for example. The best practice is for team members to be thoroughly cross-trained, and capable of taking on the next available task regardless of what it is. This is the most efficient way of optimizing throughput as it reduces wait times and potential bottlenecks.
> Our Scrum team are (without Scrum Master and PO) 12 people with a
> sprint of 4 or 5 weeks. What would you say is the best size for 12
> people and the best weeks in sprint?
What you need to avoid is batching up large quantities of work prior to release. In Scrum, a Development Team should consist of no more than 9 people and a Sprint should be no longer than 1 month. The maximum batch size of a Sprint Backlog is, therefore, limited to the work of 9 developers for 1 month. If your team has 12 people and a 5 week Sprint then you have exceeded this limit and you are not doing Scrum.
In my experience, most teams will have Sprints that are 2 weeks in length and a team size will average 5 developers. The batch size of a Sprint Backlog tends to be only about a third of the maximum allowed.
> We consider to change the scrum master all sprint, or all 2 sprints in the
> scrum team. Is this variation ok or is a fix Scrum Master the better solution?
You can rotate the role of Scrum Master every Sprint if you wish, but I don't recommend this unless the team is mature and its role is well understood across the organization. A team that is new to Scrum needs to establish consistency in its practices as soon as possible, so that inspection and adaptation can be effective. Having a "fixed" Scrum Master helps provide this consistency, and is a single point of reference for the rest of the organization during the agile transition. If others aren't sure who the Scrum Master is, they are likely to approach the wrong person with any queries or concerns, and team efficiency will be reduced.
What I have seen is that Usually developers report to a engineering manager or a development manager in the Org Chart. These managers have the responsibility for ensuring the professional development of the Engineers so the work assignment reflects some of this. Scrum teams negotiating to assign the work is fine, but the question is what happens when someone finishes early or doesn't finish. does the team self-organize to still deliver or the sprint backlog ? With a 12 member team do you see sub-teams formed within them. If so it is better to separate them out as separate scrum teams. They may still attend the same daily scrum, retrospectives etc but should have separate sprint backlogs. I would vote for a dedicated Scrum Master role and not rotation.