cooperation in scrum
Hi everyone,
This is a hypothetical, but what would you suggest to do when a member of a Scrum Team isn't cooperating with the rest of the team? Here are a few examples of what I mean:
1. What should the Dev. Team do when the Scrum Master isn't fulfilling his/her role to the Dev. Team?
2. What should the Product Owner do when the Scrum Master keeps pushing the Dev. Team to work on other projects?
3. What should the Dev. Team and Scrum Master do when the Product Owner doesn't attend meetings, accept the current velocity of the Dev. Team, or manage the product backlog?
4. What should the Product Owner and Scrum Master do when the Dev. Team won't communicate on what they need and their capacity?
I've tried answering these myself but I'm very curious what everyone here has seen from their experience and Scrum training. Has anyone faced the complicated matter of the Product Owner also being the people manager of the Dev. Team or Scrum Master?
Best,
TD
Tyson, that is quite a wide array of questions/concerns.
1) Do you have any specific examples of how the SM is not fulfilling their role, and how it is affecting the Dev Team? The SM does have responsibilities to the Dev Team as listed in the Scrum Guide, so it would be good to know how the SM is being perceived as falling short. My first thought would be for the Dev Team to raise these observations in the Sprint Retrospective for discussion.
2) Why would the SM have any interest in identifying work for the Dev Team to do? That is neither their role, nor their responsibility. That is simply not Scrum, and anyone (including the PO) should feel free to point that out as a major impediment.
3) Again, the Sprint Retrospective serves as a suitable venue for raising such observations. The SM should be coaching the PO on proper Scrum. Without engagement between the Dev Team and the PO, and without consistent Product Backlog maintenance by the PO, Scrum simply cannot succeed. Look to the Agile Principle #4: "Business people and developers must work together daily throughout the project."
Regarding "accepting" the current team velocity, that is a bit of a confusing statement. Velocity should serve as a planning guide to the PO and the Dev Team for how many items can be completed within a sprint. It is actually within the PO's right to ignore this planning metric and "offer" any amount of work to the Dev Team for the upcoming sprint, even if it is significantly greater than the Dev Team's known velocity. It is also perfectly within the Dev Team's right to accept/forecast only the amount of work that they feel they can comfortably complete within the sprint.
If the above situation is occurring, then there needs to be a discussion between the Dev Team and the PO regarding the excessive "offers" of work each sprint, facilitated by the SM.
4) If an item meets the Scrum Team's Definition of Ready, then it should be able to be completed by the Dev Team within the sprint. If there are additional items identified during the sprint that the Dev Team required, then those items should become part of their Definition of Ready for future work.
Can you give an example of a Dev Team not communicating about their capacity, and how that impacted the sprint?
Hi Timothy,
Wow! Thank you for the extended answers. Unfortunately, I can't give you real-life examples of where this happened. I'm pretty lucky right now to have a great Dev. Team and SM, with me as the PO.
My concerns primarily stem from what to do if someone in the scrum team started acting in self-interest. For instance, if a member of the development team is concerned that not meeting the sprint goal would reflect poorly on him/her. Maybe I asked in a poor way, but it sounds like you've answered the question: the retrospective seems to be a good place for all of these conversations to happen and it may take some time for everyone to identify this meeting as a place to discuss issues openly.
Thank you again!