Remove Impediments - Superhero Time

When I was working as a Scrum Master, I faced the question multiple times "What are you doing as a Scrum Master, can you tell us how your time is being used in an office day?". During my initial days as a Scum Master I used to lecture about the role of a Scrum Master to them. But still it is all theory and the clear answer is not provided. Later I found out a beautiful way to answer this question.

Those who are new to Agile assumes that the earlier role of Project Manager is being replaced by Scrum Master. They misunderstands that the new role of Scrum Master is a Project Manager without delivery responsibility as the delivery responsibility is now with the team. "Compared to Project Manager of the traditional world,  what does the Scrum Master do" is the real intention behind asking this question. The real problem is not the question but rather understanding the role of a Scrum Master.

As we all know, the very first principle in the 12 principles of Agile is "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software".

We have many accelerators to bring this into action. One among them is "Removing Impediments". Less the impediments in delivery, early the delivery will happen. Fortunately, we have a dedicated role defined to address the impediments, none other than our beloved "Scrum Master".

It will be a super hero time for the Scrum Masters if they can measure the impediments reported and resolved. The more the number of impediments removed, early the delivery is. So I learned to record and report the list of impediments daily to show as one of the attribute on how effective I am in working as a Scrum master.

So next time when somebody asks you the question I mentioned in the beginning, be ready to show the list of impediments reported and resolved. This will definitely explain how valuable to have a role of Scrum Master in a squad, tribe, domain and even for the entire organization.

Happy Spriniting...

#Being_Agile_Not_Just_Doing_Agile

Time-box in Scrum

We all know that everything in scrum is time-boxed. The iterations, meetings, discussions, daily scrum etc. etc... Many of us are struggling to keep these time-boxes. My little advices:

• Start the meeting with a narration of the goal of the meeting.
• Emphasise on the agreed etiquettes of the meeting like be a good listener, no mobile phones, etc...
• Have a common agreement on what is the time-box allocated for the meeting.
• The scrum master or any team member can act as a moderator-cum-participant.

It is very common that the participants may slip away from the real topic and might get into discuss something(related/non-related) which may not help to achieve the goal of the meeting. The moderator can note down the key points and request to have a different forum to discuss them reminding the participants about the goal of the meeting.


An issue which especially happens at the planning meeting or estimation meeting is that people will try to find the solution for the problem. These meetings purpose is to understand the problem rather than finding a solution. People should try to gather information from the product owner to address the story.
This bad habit affects the interest of a product owner for attending such meetings. Keep your focus on asking relevant questions and clarifications to the product owner instead of discussing within the team in these meetings. PO is the prime person for these meetings. So we should not give an opportunity to drive away PO's focus to something else because the team is discussing the story and PO feels it is irrelevant to him/her.


Strictly follow the guidelines for the daily scrum. There should not be questions raised during daily scrum arising situations like person B should speak in the middle of person A's time. I mean, if we scribe the daily scrum word by word, no sentence in the script should end with a question mark. If there are questions please ask them once the daily scrum is over.


Review meetings are meant for explaining what the team has produced during the sprint. Stick to that. If any questions/discussions happens on topics not in the scope of the story, park them as an opportunity to create new stories and continue. All the feedbacks should be scribed and don't go for a discussion on those during the meeting. Discuss them with the relevant people at a different meeting. Never explain each story in its minute level. Instead, the team can ask the interested party to try it and provide the feedback later as the team is delivering a working product. Avoid the technical explanation to the story (what code has been written, whether it is while loop or for loop etc.) unless otherwise it is the scope of the story.


It is recommended that retrospectives focus on process rather than product, but not mandatory. Know the bandwidth of the scrum team on applying the action items that arises during the retrospective. Discuss only the items that comes within that bandwidth. Don't try to dig deep on any of the action point if it takes a long time on discussion. Realize the priority of the action item and schedule another discussion forum on the topic if required.