Scrum Advise
I am involved with an organization that is going through some growing pains with scrum any suggestions would be appreciated.
1. There are numerous small products where it would not make sense to have a unique scrum team for each. The Dev managers are using this as a reason why not to follow scrum. I believe that a single scrum team can be assigned multiple products and still easily follow scrum.
2. The QA manager believes he has the authority to directly place defects directly into sprint ready , place priority and assign directly to the development team. I am strongly against this since it undermines the product owner's ability to manage the backlog.
3. Retros include the entire department (including top management) and goes over all products at once. No action items to improve are made. The health of the team scores are always a perfect 5 out 5.
4. Sprint planning is done by Dev's without product owners attendance. Backlog refinement is considered meeting overload.
5. Scrum master is good with all of the above.
Thanks - (product owner)
No action items to improve are made. The health of the team scores are always a perfect 5 out 5.
What are the consequences of this inertia? Is there evidence that it has negatively impacted organizational outcomes? Who wants a different way of working and why?
There are numerous small products where it would not make sense to have a unique scrum team for each. The Dev managers are using this as a reason why not to follow scrum. I believe that a single scrum team can be assigned multiple products and still easily follow scrum.
This is a common reality for some organization - they have more distinct products than teams. I believe that some of the Scrum structures may still provide value, but I'm not sure that I'd say that the team can "easily follow Scrum". It may get easier if you can organize these smaller products into groupings that have a shared Scrum Team. You may still run into some hiccups around Sprint Planning, developing a cohesive Sprint Goal, focusing on the work, especially if you get unexpected interrupts related to other products.
The QA manager believes he has the authority to directly place defects directly into sprint ready , place priority and assign directly to the development team. I am strongly against this since it undermines the product owner's ability to manage the backlog.
I'm not sure what you mean by "Sprint ready". The Product Owner is accountable for ordering the Product Backlog, but may delegate the work of maintaining the Product Backlog to others. The Scrum Team pulls work from the Product Backlog at Sprint Planning. I can say that assigning work directly to the development team is the same as pushing work, which isn't consistent with how Scrum is designed to work. However, being able to assess priority and place defects on the Product Backlog could be work that is delegated by the Product Owner to someone else.
Retros include the entire department (including top management) and goes over all products at once. No action items to improve are made. The health of the team scores are always a perfect 5 out 5.
Retrospectives need to be a safe place for open and honest discussion. If the team is always giving themselves a perfect store, my impression would be that they don't feel comfortable being critical of their own status in the current environment. That could be because people from outside the team are present, but it could also be problems within the team. I'd recommend making retrospectives very team-focused. If you have multiple teams working on the same product or a portfolio of products, there may be opportunities for retrospectives across teams as well in order to improve on how teams work together.
Sprint planning is done by Dev's without product owners attendance. Backlog refinement is considered meeting overload.
I'm not sure how there can be an effective goal-based Sprint Planning without the Product Owner. The Product Owner is in the best position to express the Sprint Goal and how to increase the value of the product over the Sprint being planned. I'd want to understand exactly how the Developers are planning a Sprint without a Sprint Goal being presented by and negotiated with the Product Owner. However, in my experience, the bulk of the Sprint Planning session is about how to get the work done, which is primarily the Developers.
There's nothing that says refinement has to be in meetings, but it is often effective if the team does synchronize among themselves on the state of the Product Backlog and how to get work properly refined. Good refinement not only makes Sprint Planning much easier and also improves the transparency and visibility of the artifacts.
Scrum master is good with all of the above.
I'm not sure what you mean by "good with", but there are definitely areas to ask more questions about and understand. Some things may not be problems, others may be. If the Scrum Master isn't learning and shining a light on ways that things could be better, that could be a problem as well.
1. There are numerous small products where it would not make sense to have a unique scrum team for each. The Dev managers are using this as a reason why not to follow scrum. I believe that a single scrum team can be assigned multiple products and still easily follow scrum.
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. According to the latest scrum guide there is no limit on how small the team can be.
Scrum Suggests one Product Owner per product. But the PO can serve multiple products provided he/she can dedicate the required time for each product. So if the Scrum team size is less than 10 (There is no development team any more, SM and PO are included in the Scrum team !) , Multiple products per Scrum team can be also a solution !
So if the Scrum Team has one Product owner (serving multiple small products) and one SM we are not deviating from Scrum principles that much !
2. The QA manager believes he has the authority to directly place defects directly into sprint ready , place priority and assign directly to the development team. I am strongly against this since it undermines the product owner's ability to manage the backlog.
True,
3. Retros include the entire department (including top management) and goes over all products at once. No action items to improve are made. The health of the team scores are always a perfect 5 out 5.
4. Sprint planning is done by Dev's without product owners attendance. Backlog refinement is considered meeting overload.
This is an anti-agile pattern.
P.S: Is it fair to discredit Scrum when we are not even using it the right way ?