I recently took on a new scrum team. For the first couple of weeks I observed all of their scrum events sitting quietly in the back of the room. I wanted to see where the team was with their agility journey and what places may need some firming up. What immediately jumped out to me was how they were practicing their daily scrum. The scrum master I was replacing called on each person to talk. The team proceeded to tell what they did yesterday, what story they were going to work on today and ended with “No blockers”. They all talked to the scrum master instead of each other. The scrum master wrote down notes and asked questions about their statuses and delays.
After the daily scrum, all I could tell was that 4 or 5 stories would be worked on and that yesterday 4 or 5 stories were worked on. I had no clue if someone could help anyone else or if there were going to be any conflicts with the work they were doing. The team felt because everyone was working on their own separate thing, there was no need to share more details about what they completed or would work on. The team failed to see the value in discussing more because no one else would be able to help with their work due to lack of product knowledge.
I contemplated this situation and wondered how I could get them to see the value in providing more information about what they are working on to each other. I decided to create a couple of videos about construction workers working on a house to demonstrate how even when people are doing separate, discrete work it’s important to share a bit of the details so they can plan with each other. In my videos, there is a carpenter, an electrician and plumber working together to build a house. Each is only capable of doing work within their trade and there isn’t much overlap between each profession. In the first video the construction workers conduct a daily scrum like a status meeting. The second video shows how it might go if they used the daily scrum to actually plan the day’s work.
After showing the videos to the team, we had a lively discussion about the differences between the two. They started to see how they could actually learn from one another and get help when help wasn’t obvious. Of course there were still some skeptics, even so the possibilities of more collaboration was in motion. My first change was to stop calling on people to speak. This violated self-organization and empowerment. They decided who would speak next instead of being called upon by me. The next change I implemented was for them to “pretend” I was on vacation so they would have to conduct the daily scrum without me. I stood in the back of the room and let them take the lead. It took a bit for them to decide who was going to show the scrum board for the remote people and who would get the conference line going. Once that was decided, this simple change immediately showed results. There was more conversation than ever in the room. Ideas of how to help others with their work flowed and developers participated more by asking some poignant questions that gave some good insight.
I learned that it doesn’t take big changes to shift thinking. Small little things can make an enormous shift for a team. In this case, I met the team where they were, determined what a step ahead would look like and then jumped into action with small, minor adjustments. Sometimes it’s better to think small in order to make large changes. While some are still giving a status update rather than focusing on planning, others are shifting how they talk in the daily scrum. It’s a process and we’ve made progress towards improving our agility journey.
Agility Coaching 