Challenges with Daily Stand-ups...

As a Scrum Master did you ever face these situations where

• The daily stand-ups ran for more than 15 minutes? 
• The Chickens interrupted the stand-ups or took it over? 
• The issues concerning only 2 parties were resolved at stand-ups rather than being discussed offline or after stand-ups?
• The team members gave scrum updates to the Scrum Master rather than the team 
• A team member gave one line updates or just mentioned “No updates today”?

As a scrum master, I have faced all the above mentioned situations and have resolved them successfully.

At times, I had to cut conversations and remind them that this is daily scrum stand-up of 15 minutes and NOT a status or a design meeting.

Sometimes chickens attend the scrum meeting and they might have something of real value to add to the conversations and I had stopped them from speaking up and asked them to take it after the scrum - this might seem unnecessary, but it’s needed to enforce scrum best practices.

During stand-ups, as team members go over their updates and bring up issues, I note them down. However, instead of trying to resolve the issues right there, after the stand-up I pair up team members to resolve these issues offline. For issues that concern the entire team, I ask them to resolve right after the stand-up.

Often I had noticed that some team members have a tendency to provide their updates to the Scrum Master. I had to educate them that stand-ups are for improving the communication and increasing the visibility and that the updates are for the entire team.

Sometimes it just happens that someone would give a one line update which just doesn’t make sense. In such a situation, I would randomly pick another person from the team and ask if he understood it. If that person can't explain, then the update was not good enough (Or maybe he just wasn't paying attention :-)). The team needs to be trained to provide balanced updates i.e. don’t give too many unnecessary details or give too little detail that others can’t make sense out of.

In short, running daily scrum takes a lot of discipline on part of the Scrum Master. However, once scrum best practices are adopted and followed by the team for a few iterations, the daily stand up becomes second nature for the team and everything runs like a well oiled machine.

Let's talk iteration planning meeting.

The iteration planning meetings are the most important meetings for the iteration to be successful. These are the meetings where the team plans for the work to be done in the upcoming weeks. But somehow I have not heard or read much about how these meetings should be conducted. Most of the books and websites just mention to have two 4 hour sessions for planning meetings. What really happens in these planning meeting seems to be a mystery. I have been a ScrumMaster for a while and have helped teams with planning meetings using various approaches of which some are very effective and some are not.

I wore a traditional project management hat before I was assigned the role of ScrumMaster to one of the projects. The only formal training I had then was that I had read Ken's black book "Agile Software Development with Scrum". As a traditional Project Manager, transitioning into the ScrumMaster role, I sat in the middle of the room projecting and taking notes during the planning meeting. I honestly felt I was helping the team by adding stories, breaking down tasks, assigning hours, etc. The team felt good that they didn't have to worry about entering stories, tasks and hours. However, soon I realized this approach is totally ineffective. This method of planning was very time consuming. The planning meeting took more than 2 sessions of 4hours. And worse of all, not everyone in the team were talking the same language. I could see team members tuning on and off of the conversation. They were only interested in the part that they planned to execute. So I looked back and thought about what was wrong. The problem was me. I was hand holding the team so much so that I became the bottleneck. If I am unavailable the meetings did not happen, the team mates provided scrum updates to me rather than the team. The team looked towards me for guidance and direction. I was still wearing my project management hat and not being an Agile Coach.

Luckily, I was able to get into Ken Schwaber’s “Certified ScrumMaster training” course and I was able to get some advice from him on planning meetings. With the new information I gathered from Ken, I worked on being a coach. I let the team do most of the talking and only got involved when team started getting off track. So what did I do different? My laptop was used for projecting, but only to display the prioritized list of stories from the product backlog. I asked the team to huddle in front of a whiteboard and draw the design on what was implemented so far. Soon it was realized that there were some discrepancies in the way they understood how the system worked. But after some more discussion and clarification everyone in the team was on same page. As a next step, I asked the team to update the old design on the whiteboard to accommodate the new set of stories the team planned to work on. The entire team got engrossed and focused on the design discussion. The development engineers as well as QE engineers were on the same page. The design came out much better. There was a sense of achievement by everyone and most of all, the meeting was productive. Once the design was finalized, I asked team members to select their preferred stories. I helped the team by jotting down stories and assigning stories to team members. I asked the team to work offline on decomposing their assigned stories into granular tasks along with hours needed to accomplish the needed work. The next day we got together for an hour and as a team reviewed every story and task. We made adjustments by adding/deleting and updating the tasks along with hours and we were good to start our sprint. This approach was so effective compared to the earlier approach. The team was self organizing, they were empowered to make decisions and more over it was fun!

I would like to hear other experiences on planning meetings.

How many scrums should a ScrumMaster manage?

Capturing a snippet of conversation I had with one of the managers...

Manager:  What does a ScrumMaster really do and what is his role? 

I:  A ScrumMaster helps with planning meetings at the beginning of the iteration, conducts daily scrums, conducts retrospectives, organizes demo/reviews, and helps the team eliminate any impediments. 

Manager:  As far as I understand planning meetings take 2 days, retrospective and review might take additional 2 days - correct?

I:  Yes

Manager: I heard the daily scrums are for 15 minutes. Correct?

I: Yes

Manager: If the daily scrums are for 15 minutes, then what does the ScrumMaster do for other 7 hours?

I: [huh?] ScrumMaster works with the Product Owner to groom the product backlog, he ensures teams follow Agile and Scrum best practices [Unit test cases, Integration tests, Code Coverage, TDD], he also helps remove any obstacles the team has, ensures that team is self-organized and gels together, etc…

Manager: This shouldn’t keep the ScrumMaster 100% busy – do you think one ScrumMaster can manage more than one Scrum?

….

Honestly, I don’t think there’s a simple answer to this question. As a ScrumMaster, I have managed multiple scrums and I have noticed that it’s difficult to provide enough justice to all Scrums due to various reasons like conflicting priorities between teams, schedule conflicts, divided attention, etc.

I also did some research on what the experts have to say about the dedicated ScrumMaster Vs shared ScrumMaster responsibilities. I was equally amazed to see that even they have a dilemma in creating a convincing case for dedicated ScrumMaster. This thread at Scrumdevelopment forum captures different perspectives on this topic.

However, here’s my take on this question – For a new Scrum team, have a dedicated Scrum Master for the first 8 to 10 iterations. This is to ensure that this Scrum team gets full attention of the ScrumMaster while they are going through “Forming – Storming - Norming” stages and until they reach the “Performing” stage. The performing stage is when the team achieves consistent Velocity, becomes intensely collaborative, is Self-organizing and empowered to make decisions. Once the team is in “Performing” stage, the ScrumMaster can then assume additional responsibilities.

Thoughts?