Role of a Scrum Master

Ever wonder how Scrum Masters can serve your teams besides removing impediments or facilitating scrum meetings? Given that each team is different, there are several scenarios that require varying levels of coaching team members. I believe coaching can be applied in areas such as technical, engineering, framework and methodology, while other areas such as ‘passion’, ‘striving for excellence’, and ‘willingness to grow’ are mostly self-driven or driven by inspiration within the individual. Here are some primary areas that scrum masters can contribute to their teams:

Supporting your product owner

Begin with reviewing your product backlog. If your team is using an online tool for managing the product backlog, a sneak peak at the items would reveal several things. Does your product backlog align with the roadmap? Are there enough items in the backlog at least for one or more upcoming sprints? If your team needs to meet for product backlog grooming, collaborate with your product owner with a preliminary assessment of stories and their acceptance criteria. Determine if there are dependencies requiring external support.

Addressing action items from retrospective sessions

Is your team observing a recurring pattern for improvements? Begin with identifying the trend over a few consecutive sprints. Share the information with the team to determine if the open items can be addressed either internally within your team or require external support. Some teams may need a boost to jump-start the process of discussing and applying the action items.

Addressing mid-sprint requests

Your organization may have several agile teams that interact with each other. When Production-support questions or new requests arise, they may be targeted directly to the development team members. Since developers are generally considered as the subject matter experts for troubleshooting production issues, it is likely that they are constantly distracted during the course of the sprint. Coach the delivery team and external members for handling mid-sprint requests. When requests are targeted to the delivery team, inform the product owner and seek her to guidance on the priority of new requests or defects reported. Depending on the priority, your product owner may simply backlog the items for a later release or request your team to take a sneak peak no longer than say 15 minutes of your time. When defects arise during mid-sprint, determine if your team must terminate the sprint, adding to the existing sprint backlog or table it for a later sprint.

Ignoring impediments

Has your team faced impediments that were not raised during the Sprint or were raised late?It is natural for some team members to resolve or handle things on their own. Some impediments such as restoring the Rapid Application Development (RAD) environment could be perceived as too technical to be raised to your Scrum Master.  Regardless of its nature, your scrum master, can support you in resolving or seeking additional support when impediments are raised. In addition, there is value in resolving impediments as and when it occurs, than exposing them as places for improvements during the Sprint Retrospective session.

Implementing out-of-scope tasks or Gold-platting

These are scenarios where a developer or a tester may be working on tasks that are not tied to the sprint backlog or support the acceptance criteria for items in the Sprint Backlog. Sprint Planning and Daily stand-ups are some of the areas where the team and the product owner could identify add-ons. Coach the team in delivering the items with good quality, that were committed during sprint planning. A pattern in completing additional development tasks first with the intention of testing it in a later sprint would demonstrate a mini-waterfall approach.

%d bloggers like this: