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 | view comments | add comment

 

June 29th, 2011

The One Where The Release Plan Was Unacceptable

Overview Xander, the ScrumMaster for the Blockheads team, had just finished leading them through release planning of the highest priority section of Product Backlog for the OPAL project. The team was fairly new and had little concept of their velocity plus the project was fairly complex and, after 4 hours, the Blockheads came up with a plan of 6 sprints to complete this release. Heleena, Xander’s manager, who had been observing this new practice of agile planning pulled Xander to one side. “Six months? That’s ridiculous. We can’t afford to take six months to get this release out.” She said “Well we do have the option of deploying any time after sprint three so we could call this two releases really”... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Planning / Product Owner / Release Planning / Scrummaster / The One With

0 comments | view comments | add comment

 

May 24th, 2011

The One With Five Teams

Overview Karina, a RE-TRAINED project manager, had recently come back from her Certified ScrumMaster training which had been organised just before the STING project was due to commence. She was aware that Serena, her boss, was keen for this project to be agile but was very nervous about it as this was a big project for one of their major customers. Before she went on the training she had looked at the original budget for 3,500 man days of effort over the next 12 months and thought this would be a big risk for her first Scrum implementation. Karina had a de-brief with Serena on her return to the office with the idea of setting up the necessary structure for Scrum on the STING project. She mentioned that Scrum teams are generally optimal when... read more

 

Category:

Scrum / ScrumMaster Stories

Tags:

Multiple Teams / Planning / Project Manager / Re-trained / Scaling / Scrummaster / The One With

0 comments | view comments | add comment

 

April 27th, 2011

The One Where The Team Was Working On Everything At Once

Overview Half way through the Sprint the team are having their Daily Scrum. The team take it in turns to share with their colleagues what progress they have made and what they plan to work on today. There are a couple of impediments that get added to the Sprint Backlog and Ashley, the ScrumMaster promises to pick up – one with an external vendor who is not supplying the input file in the correct format, and another with Operations who still haven’t provided a correctly configured staging environment. The team glance at the Sprint Burndown which shows they are roughly on track and the team are about to leave the Scrum room when Ashley asks a vital question: “Are we actually OK here? I feel worried but you guys seem fine wit... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Backlog / Burndown / Impediments / Scrummaster / Team / The One With

0 comments | view comments | add comment

 

November 30th, 2010

The One With Two Daily Scrums

Overview On my first day coaching a new team they invited me along to their Daily Scrum first thing in the morning. They had been using Scrum for a couple of months and had a great “Scrum room” with glass walls on all sides and a lovely view of the lake. On one wall they had their Sprint Backlog, on another they had the Sprint Burndown and on another they had the outcomes from the last retrospective. Everybody was there on time and even Annika, the Product Owner, was demonstrating her commitment to the team by being present. There were a few quick greetings before the team members stood in a circle and took turns to update their colleagues on their progress, confirming the view that the Sprint Burndown was indicating their good... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Burndown / Daily Scrum / Product Owner / Scrum / Scrummaster / The One With

0 comments | view comments | add comment

 

October 18th, 2010

The One Where Everything Was Signed Up For In Sprint Planning

Overview Eve, the newly minted ScrumMaster was facilitating her first sprint planning for the Jalapenos team on Project Lhasa. She had worked hard with Lilia, the Product Owner, beforehand to make sure the product backlog was well organised, prioritised and understandable and the team had reacted well. The first part of the sprint planning meeting included some planning poker to estimate the top 20% and some good conversation emerged between the team and Lilia. The team committed to 28 points of product backlog (8 items) and were now in the second part of the meeting, where the team work out how they are going to turn those 8 items into potentially deployable functionality. Clinton, Tania & Kurt were around the whiteboard with a stack ... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Commitment / Planning / Sprint Planning / Task Board / Tasks / The One With

0 comments | view comments | add comment

 

August 24th, 2010

The One With The Fifty Percent Resources

Overview   The Wizard Sleeves were a team of 7 people – Alistair, Dave, Gordon, Margaret, Nicola, Olivier, and Peter; pulled together from various project teams within the department to tackle a project that had been hanging around for about a year. At Sprint Planning Tony, the ScrumMaster (and also one of the management team in the department), brought along a “resource planner” to show how much time each of the team members had available to spend on this project. Alistair Dave Gordon Margaret Nicola Olivier Peter 40% 33% 50% 50% 25% 66% 33% Every member of the team had other projects that they were working on at the same time as working on the Wizard Sleeves team. Indeed thi... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Dedicated Teams / Multi-task / Resource / Sprint Planning / Team / The One With

0 comments | view comments | add comment

 

July 12th, 2010

The One Where The Product Backlog Was Too Big

Overview Andy, the ScrumMaster, was guiding the team through a session of planning poker to estimate the initial Product Backlog so the team could come up with a release plan for the new project. Murray, the Product Owner, had provided the team with the Product Backlog in time for the planning session although it did have to be rescheduled a couple of times as he couldn’t get hold of a couple of the account reps to get their requirements. The team had timeboxed three hours for the estimation but they had only really just scratched the surface of the Product Backlog and time was nearly up. A quick look at the spreadsheet showed they were probably only about 10% of the way through the product Backlog and that was quite depressing; it ... read more

 

Category:

Scrum / scrum master / ScrumMaster Stories

Tags:

Backlog / Product Owner / Requirements / The One With

0 comments | view comments | add comment

 

May 20th, 2010

Getting RE-TRAINED as a ScrumMaster

There are only three roles in Scrum. This is often the first thing that people have difficulty with. There is no project manager in Scrum, there is no distinction between different members of a development team – they are just called team members. The Product Owner is responsible for representing the needs of the stakeholders of the project to ensure that what gets delivered is valuable. She owns the budget for the project, determines the requirements and their importance and is judged on the return on investments (ROI) of the project. The development team are responsible for turning the Product Backlog into potentially deployable increments of product on a sprint by sprint basis. They are a self-organising, cross... read more

 

Category:

Scrum / scrum master

Tags:

Product Owner / Project Manager / Re-trained / Scrum / Scrummaster / The One With

0 comments | view comments | add comment