Dealing with focus/commitment lapses
Hello all,
Overall, our organization welcomes the idea of a "work in your own way" approach, and tries to be a fun place to work. Our development teams are co-located and have great chemistry. The problem is, delivery and pace has been an unending struggle for months. We have tried just about as many approaches/changes as I'd be comfortable throwing at a team without overwhelming them..
To their credit, they have been asked to build something from scratch and work with challenging new technologies with limited domain knowledge. However, I'm left to wonder if Scrum principles play a part. I've noticed members of teams welcoming any and all distractions to their work rather than staying focused. Many side conversations with some lasting half an hour at a time and getting the whole team involved, some involving the other team. Long lunches, late arrivals, things of this nature. And yet at the end of most Sprints they are left wondering why they've come up short.
I've talked to some members one on one, and it's been brought up in retros in not-so-subtle terms and seriously deflated morale (but the behavior returned). Management is aware and has tried to give the teams the benefit of the doubt but at this point I would not be surprised if this changed.
I really want the development teams to make the decision on their own to hold themselves to a higher standard of commitment. I prefer not to be a Scrum babysitter or the "focus" police for a myriad of reasons, but often think it may be my only option sometimes as Product Owner and stakeholder trust rapidly declines.
If you've experienced this, how have you approached it?
Thanks!
P.S. Do you have methods of "checking in" (not a status report or "checking up") with your team that are non-intrusive or are good for getting the team back on track?
Are they able to deliver a "Done" increment of release quality, however small and marginally valuable it might be?
Ian,
On the whole, yes. We've been crafting our Sprint Goals in a way that provides perspective on the value of the increment rather than being a binary measure of certain PBIs. However, stakeholders are understandably not comfortable with the pace of small wins.
Do you have methods of "checking in" (not a status report or "checking up") with your team that are non-intrusive or are good for getting the team back on track?
I frequently ask the team members if there is anything I can do to help them. I leave it open ended so that they don't think I'm checking up on them but it usually starts conversations about what is being undertaken. I'll ask 1:1 and in group settings. I've also been known to walk up to a group that are chatting and ask them a specific question on something on the board. And I usually try to use something that no one in the group is involved with. For example, "Hey, are any of you working on the Jira ticket COVID-19"? No one remembers that ticket numbers, they remember the context of the ticket. So this will usually result in someone checking the board to see what I'm asking about. I usually have some kind of reason for asking, again so they don't think I'm checking up on them.
Your situation is not unusual. I see it a lot in start-up companies. I usually address it by starting some uncomfortable conversations. When they express their amazement at coming up short, I will start some root cause analysis on it. The Five Whys is a favorite. Help them come to the realization of how their behavior is impacting their ability to actually deliver valuable increments. I don't see this as being the Scrum Police or even a Scrum babysitter. I see it as a technique that a Scrum Master will sometimes use to help the team focus and improve. Open and honest teams will understand that not everything is rainbows and unicorns. Sometimes conversations need to be difficult. It is part of becoming more self-aware.
stakeholders are understandably not comfortable with the pace of small wins.
Are the team improving their ability to deliver value Sprint by Sprint, even if each attempt to do so is marginal?
In other words, how have the team set about continuous improvement, and ensuring that this happens?
Daniel, thank you for your insight and the suggestion (also, got a laugh at the ticket number). I look forward to trying this approach.
Ian, to be honest - no. But it is not for lack of trying. We take retrospectives seriously and decide on an actionable improvement, however small. However, these commitments don't come from the team with any enthusiasm. I and some others will ask thought provoking questions but it often feels like leading a horse to water. To be fair to them, it is rarely a single glaring issue that derails a Sprint but rather a culmination of many things.