What scrum master should do if team is not ready to pick the high priority remaining work
Hi All,
I want to get some advise on how to deal with the situation where team member is not picking up the remaining work of another team member. The work is high priority which needs to be finished. As Scrum Master, I asked the team "Who can pick this work" it was already added in Sprint backlog, since its high priority. We don's have backups of team members in the team. I also want to know how to ask the members to have their backup, in case they went on leaves (planned /unplanned/Sick).Team member who was earlier working on the story went on sick leave.Now no one is picking up his remaining work. Even though , PO is agreeing to do the trade-offs with the sprint work and we can move back the low priority work back to backlog, still no one is willing to pick the work. Team has all the skills and we are ready to provide all the necessary informations. Team is just throwing the ball from here to there and not helping each other.They are saying that Scrum master should tell the management that this work cannot be done. Person is on sick leave. But this work is high urgent which canot be delayed. It will affect the business directly.
It looks like work is allocated to individuals. Some teams are capable of making the leap to "the person who's name is on the work is the primary person responsible for it, but we all help". Other teams can't. It's important to shift the mindset towards all of the work being the team's work and none of it is an individual's work that needs to be picked up by someone else, since it's already been picked up by the team when it was selected at Sprint Planning.
If the team has all of the knowledge and skills needed, then why don't they want to do this piece of work? Why are they not helping each other? It seems like something is keeping people in the mindset of work being owned by individuals rather than by the team. Identifying and then correcting those root causes is key.
The work Developers do should not be determined by priority but by the commitments they jointly make. Are the Developers framing and meeting a Sprint Goal and developing at least one Done increment of immediately usable quality each Sprint?
I also want to know how to ask the members to have their backup, in case they went on leaves
So, how is the usual work done? There's a Sprint Backlog, and then? How do they start working on those items?
Everyone on the team is their backup. Because if someone chooses a backup, what if they both get sick or go on holiday?
It looks like work is allocated to individuals.
Yes. And maybe it's being measured?
Thanks Thomas, Ian and Mario, The problem is no one is opening up on raising these concerns in Retrospective. And if as an observe Scrum master is bringing the inputs in retro then team is raising concerns that why Scrum master is putting these inputs and complaining that its micro management. We do have sprint goals and yes, its mind set issues that they are thinking that work assigned to individual is individual's responsibility.
So I am keep on mentioning in Sprint planning and wherever needed that we as a team jointly agreed on the sprint goal, its our development team's responsibility to own the Sprint backlog jointly not individually. Why I used in the question that there is high priority item because we are working on Service now escalation tickets too. (not only dev product's requirement) we are supporting applications as well, that's where our Sprint backlog and Sprint goal is keep on shifting and compromising.
Is there any suggestion on how shift the change in mindset, because coaching and teaching is not helping much here. or may be what are the ways to tackle this situation. :(
And if as an observe Scrum master is bringing the inputs in retro then team is raising concerns that why Scrum master is putting these inputs and complaining that its micro management.
That is the first of the "mind sets" I would work on adjusting. The Scrum Guide says this about the Sprint Retrospective
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
Notice that it says the "Sprint Team inspects". The Scrum Master is part of the Scrum Team so they can contribute to the topics. I have not found anywhere in the Scrum Guide that states the Scrum Master is only an observer of the Sprint Retrospective. The only one of the Scrum Events that the Scrum Master would not take an active role in would be the Daily Scrum since it is for and by the Developers.
This is the opening sentence in the Scrum Guide's section on the Product Backlog.
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Defects are work that is needed to improve the product. Your organization may be using Service Now for the Support organization but those items need to find their way into the Product Backlog. Then the Product Owner can order them appropriately. If they feel it needs to be put into the current Sprint, then Developers should discuss how to do that with the Product Owner. The Developers own the Sprint Backlog and no one can add to it except for them. If the Developers feel that adding that item to the Sprint Backlog endangers their ability to meet the Sprint Goal, the Product Owner needs to work with them to come up with a compromise that all with agree to.
Having said all of that, there is nothing unusual about your situation. Every software development team I have worked with has faced this problem. The way I always coach them to deal with it is to make sure that the Developers need to realize that it is always a possibility that a production defect could become critical to fix immediately. Taking that into consideration, they should plan their Sprint Backlog knowing that there could be some unexpected situations arise that would require them to do work that is not directly related to the Sprint Goal. They should leave some bandwidth to act upon situations like that.
The original responders hit on the fact that your team is not working as a team but as a group of individuals. I suspect that your organization evaluates everyone as individuals. Individuals get raises, individuals get bonuses, individuals are promoted based upon the work that they do by themselves. As long as the organization continues to encourage individual behavior over team behavior, it will be difficult to change this mind set. I have had success by helping the organization understand that this is a anti-pattern for agile practices. I have coached the individuals that do all of the individual assessments to focus on how the individual helped their team and not how they did their own work. How did this individual help elevate others on their team? Do not use metrics like "how many bugs did they fix" or "how many bugs were introduced in their code base" or "number of code commits". That is not an easy mind set to change either but it can be done with enough time.
Thanks So much Daniel for the detailed information and insight. You clearly understand my situation and I am feeling confident now on how to deal in this scenario. Thanks all for you support and help. Truly appreciated. :)