September 12th, 2011
The One Where Someone Keeps Being Late
Overview
The Sonics were a team about half way through their first sprint and having their first experiences with Scrum. At the same time this was their first project together as a team and, as such, were just getting used to each other and establishing a working rhythm. The ScrumMaster, Darryl, was also new to Scrum but was chosen to be the ScrumMaster because of his “people skills”. His history showed he had the ability to bring people together to work effectively as a team. Sprint planning went relatively well and everyone was relatively comfortable that what the team had committed to was achievable and the team seemed motivated by the project.
During the sprint Darryl noted that people were focussing on the tasks that they signed up for and were making good progress on them but were still acting fairly independently of one another; there wasn’t a great deal of collaboration or teamwork that he was expecting Scrum to bring out but at least progress was being made. Unfortunately it seemed that Avis, the business analyst on the team, was struggling with a few things. He was often late to the Daily Scrum meetings and was often hard to find during the day when team members had questions about the business process to be implemented.
The team weren’t using this as an excuse though and, as was suggested in the training, had self-organised to cope without Avis. They had bypassed him on a number of occasions and had contacted some of his colleagues or the Product Owner or, in some cases, just worked things out for themselves. The Daily Scrum, however, was a different matter and Darryl could sense a strong frustration here. Not quite every day, but very often, Avis would turn up a good five to ten minutes late and the team would need to recap what had been said for Avis’ benefit.
What was interesting, from Darryl’s point of view, was that the team were not raising this frustration publicly but were keeping their annoyance inside. He could sense a growing resentment toward Avis but didn’t think that Avis was aware of it.
Darryl knew this was a team issue and one that needed to be solved by the team and so, at the end of the sprint, raised it at the retrospective.“How did you think the Daily Scrums worked for you this sprint?” he asked.
Avis, unsurprisingly, was the first to speak out and said:
“I thought they were really useful. They were a great way for me to catch up with what was going on with the rest of the team. If it wasn’t for those meetings I would not have had a clue what everyone else was doing.”
“That’s good. What about everyone else? Were they useful for everyone?” Darryl asked
The rest of the team were silent. Perhaps this was still too early for the team to feel safe with each other, or perhaps Avis’ comments made it harder for the rest of the team to contradict him but nobody said anything. Darryl then displayed a really useful skill of a ScrumMaster, that of the uncomfortable silence. He waited, and he waited, and when he thought he should say something to move the topic forward, he waited a little longer. Eventually Amie spoke up:
“Well I did think that perhaps we weren’t holding them at the right time as they seemed to be a bit awkward for Avis. He was often somewhere else at the start time.”
“Thanks Amie. I did notice that it was difficult for Avis to be there on time. Did you have other meetings at 9am Avis?” Darryl responded.“Not meetings, no, but I did often try and get through my emails first thing in the morning and I often lost track of time. I hardly missed one though”
“Do you think that had an impact on the rest of the team?” Darryl asked
“Possibly, but I think it was really useful because I got a really good summary”
“What about the rest of you?” Darryl asked the rest of the team
“Well I was a little frustrated that we had to repeat ourselves." Sam said "Also, we often had to find other people to answer our questions about the process and then you would come back a couple of days later and tell us we had got it wrong. This meant we had wasted a lot of time that could have been avoided if we had the opportunity to talk to you about it."
"What can we do to improve this then?" Darryl asked
"Would you rather we moved it to 9:15 Avis? It would be good to have you there” Amie suggested
“That would probably work for me” Avis said
“Great. We will give that a go then.” Darryl concluded
Analysis
At the retrospective, Darryl asked the team about the Daily Scrum and tried to get the team to bring to the surface how it was affecting them as Avis seemed unaware of the impact he was having on the rest of the team. If this had carried on, the team would have increased their working around of Avis, the assumptions the team were making would probably have got worse and ultimately the resentment of the team towards Avis would have grown, potentially to a damaging level.
Darryl handled the retrospective well, managing to draw the issues out of the team rather than pushing his ideas on to the team – this is far more powerful – and using a great tool of uncomfortable silence to bring people into the conversation. He also recognised the discomfort of the team members and publicly displayed gratitude for their contribution (thanking Amie) which is very helpful in encouraging further input from that team member and others.
Darryl didn’t have to wait until the retrospective to raise this with the team though. Scrum actively encourages a team to make daily inspections and adaptations to their working process where necessary. Sometimes teams will fall into the trap of waiting until the end of the sprint to make changes just because they know there is a formal opportunity for that. Setting the expectation that changes will only occur at the retrospective, although not consciously in this example, can have far reaching consequences. In this particular situation, Avis continued to turn up late and, rather than deal with it straight away, the team left it until the retrospective again. This time they decided they would put a fine system in place so anyone who was late for the daily scrum would pay a nominal (£1) fine. Again, Avis continued to turn up late, and on day one of sprint 3 turned up with a £20 note to pay his fines in advance.
This brings me on to the point of whether Darryl gave up too easily in the first retrospective. It seemed as though Darryl grasped on to the first suggestion that came up regardless of whether it was the right one. A major symptom seemed to either be ignored or missed – that of Avis being hard to find during the sprint. Where was he? What was he working on? Is he actually acting as if he were a part of this team? Does he have other distractions? In hindsight, it appears that there are deeper issues at play that would have been good to dive into. Some of this comes with experience but some techniques, such as the “5 Whys” technique can help ScrumMasters reach the real issue.In this story, in the terms of Bruce Tuckman, the Sonics were still in the “forming” stage where most team members want to be accepted and avoid confrontation and conflict wherever possible.
The forming stage is both a comfortable and frustrating phase of team development. It is comfortable because there is little conflict. It also tends to be in the early stages of the project with little immediate concern over the delivery deadline and thus stress is relatively low. However, due to the lack of conflict, there is actually very little progress or teamwork. Team members are said to be “walking on eggshells” at this stage, trying harder to not upset each other rather than on delivery.
Scrum teams find themselves facing the challenges of working through the team formation stages at a much faster pace and with greater volatility than many traditional teams due to the cross-functional and self-organising principles of Scrum. The ScrumMaster should be aware of this and be prepared to help guide a team through these phases of team development quickly as this is one of their primary responsibilities. There are lots of tips and techniques out there that ScrumMasters can use to help them with this and some that I have found particularly useful are “The Five Dysfunctions of a Team”, “Leading Self Directed Work Teams” and “Thiagi’s 100 favourite games”
Summary
You shouldn’t necessarily wait until the retrospective to raise issues to the team if you feel they are affecting the team. Equally don’t just take the first suggestion the team comes up with because you are so relieved that the team actually came up with a suggestion. Keep digging until you are satisfied that the team have covered the real fundamental issue. I know some teams that won't make a decision on how to move forward until they have at least SEVEN potential solutions! Sometimes this will only come when the team is mature enough to deal with it, but sometimes teams need to do this in order to mature so it is a delicate balancing act. Beware, however, that the team is rarely the best judge of where they are as a team and you, as ScrumMaster, will probably find yourself challenging the teams in uncomfortable ways in the early stages of team development. It is exactly this type of scenario that we spend time discussing in my Advanced ScrumMaster classes
Tags:
Daily Scrum / Retrospective / Scrummaster / Story / Team / Teamwork / The One With
0 comments | | add comment
Subscribe to RSS