Considerations for the Scrum Master!!

Check the boxes to allow Scrum Masters to work quickly.

Scrum Master : A Full Time Facilitator ?

The Scrum Master role may be a full-time role focused solely on facilitating and coaching the Scrum team. In other organizations, the Scrum Master may also have other responsibilities or not be a full-time role.

The Scrum Master’s primary focus is to facilitate and coach the scrum team, and they should have enough time and focus to effectively perform this role.

• An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role.
• The team will probably still exceed the baseline, pre-Scrum expectation in our projects, and probably nothing catastrophic will happen.
• A great Scrum Master can handle one team at a time

Whether Scrum Master are a full-time facilitator or not will depend on the size and complexity of the team and product, as well as the needs and resources of the organization.

• Ideally, we should have one dedicated Scrum Master per team of about seven or less, especially when starting out.

How is my Product Owner Doing ?

As we know, only the Product Owner may priorities a Product Backlog, so it becomes important that backlog health is always in good condition.

Scrum Masters improve Product Owners effectiveness by helping them find ways to maintain the product backlog and release plan

• Is the Product Backlog prioritized according to his/her latest thinking
• Are all requirements from relevant stakeholders captured in the Product Backlog
• Is a Product Backlog a manageable size ?
• Could any requirements, be better expressed as independent, negotiable, valuable, estimable, small and testable user stories ?
• Have we educated our PO about technical debt and how to avoid it ?
• Is the backlog an information radiator, immediately visible to stakeholders ?
• Have you helped our PO organize backlog items into appropriate releases or priority groups?
• Does everyone know whether the release plan still relevant or matches requirements and reality ?
• Did our PO adjust the release plan after the last Sprint Review Meeting ?

How is my Team Doing ?

Scrum Masters should lead by example of collaborating with team members on their work, else we may get lost in technical tasks. Consider our primary responsibilities to the team :

• Is your team in the state of flow ?
• Should have clarity in goals
• Concentration and focus
• A loss of the feeling of self consciousness, the merging of action and awareness
• Direct and immediate feedback
• Sense of control over the situation or activity

Do team members seem to goof of together, and celebrate each other’s success ?

Do team members hold each other accountable to high standards, and challenge each other to grow ?

Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable

Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the Product Backlog Items committed for this Sprint.

Does the Sprint task board reflect what the team is actually doing ? Beware of undisclosed tasks and tasks bigger than 8 hours of work. Tasks unrelated to the sprint commitments are impediments to those commitments.

Are the team self-management artifacts (task board, Sprint Burndown Chart, impediments list, etc.) visible to the team, convenient for the team to use?

Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside the team may impede team internal transparency and self management

Do team members volunteer for tasks?

Has the need for technical debt repayment been made explicit in the backlog items, gradually making the code a more pleasant place to work?

Please ensure that team members are collectively responsible for the aspect of agreed work like

• Testing
• User documentation etc.

How Are Our Engineering Practices Doing?

Does your system in development have a “push to test” button allowing anyone (same team or different team) to conveniently detect when they’ve caused a regression failure (broken previously-working functionality)?

• Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).

Do you have an appropriate balance of automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?

Is the team writing both system tests and unit tests in the same language as the system they’re developing?

• Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset of the team knows how to maintain.

Has your team discovered the useful gray area between system tests and unit tests?

Does a continuous integration server automatically sound an alarm when someone causes a regression failure?

• Can this feedback loop be reduced to hours or minutes?

Do all tests roll up into the continuous integration server result?

How is the Program/Project Doing ?

Is the appropriate amount of inter-team communication happening?

• “Scrum of Scrums” is only one way to achieve this, and not necessarily the best.

Are teams independently able to produce working features, even spanning architectural boundaries?

Are our Scrum Masters meeting with each other, working the project/program impediments list?

When appropriate, are the project/program impediments pasted to the wall of the development director’s office?

• Can the cost be quantified in amount, lost time to market, lost quality, or lost customer opportunities?

Are we creating a learning team ?

Conclusion

There’s no pre-developed formula for creating human ingenuity or high performance. We’ve got to learn and master the art of identifying a team’s capabilities and their limits to push. Putting unnecessary mental pressure on your team to create a high-performing team may hugely impact the emotional quotient of your team. So, be a great servant leader to extract the best out of your team. And once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you’re on the right track.