Don’t Be the Same. Be Better.
A Scrum Master achieves results through coaching, collaboration, communication, and conflict resolution. Expertise in these skills is a must for Scrum Masters.
This course is an opportunity to strengthen these skills. We will be focusing on 6 areas where a Scrum Master can improve to become better:
I hope this course will be show helpful for you in your Agile journey.
Requirements for this course
Foreword: What is a Scrum Master?
Scrum involves several distinct procedures and artifacts, which refer to the components essential to the Scrum process, such as the backlog of work to be completed. A team must employ these procedures and artifacts in a specific manner for scrum to work. That’s where the Scrum Master comes in.
The Scrum Master facilitates a project team’s Scrum process and ensures the team applies Agile principles. The title comes from the idea that the Scrum Master is an expert at Scrum and can thus coach others. The Scrum Master acts as the glue connecting Scrum participants to the Scrum process.
Imagine the Scrum Master as akin to a personal trainer at a gym. The trainer guides your workout and helps you achieve your fitness goals, but you must put in the work to make it happen. The same goes for a Scrum team. The team executes the work, and the Scrum Master guides them toward their goals.
That being said, I've heard from time to time that a Scrum Master is just a facilitator, or just a coach. I disagree; rather, I feel that the Scrum Master must have business sense, communication skills, tact, and political savvy in order to have the slightest chance at a successful transition.
According to Dr. Rafael Landaeta, Old Dominion University: "The perfect Scrum Master would probably have advanced degrees in engineering, business, sociology, education, and in psychology, and have worked as change agent and manager of projects with different degrees of uncertainty in different industries and sectors, and would have the energy of a teenager, the spirit of a sport champion and the wisdom of a crowd of experts".
This might be overwhelming, so first realize that not all changes are revolutions. You can implement change in baby steps simply by implementing the Scrum framework, escalating obstacles, and reflecting on your personal growth.
It can also help to understand what else you can do to be a better Scrum Master for your team. By doing so, you will become a better change agent, and thus, a better Scrum Master.
Self-assess how good you are as a Scrum Master
Scrum Masters improve Product Owner effectiveness by helping them ﬁnd ways to maintain the Product Backlog and release plan. (Note that the Product Owner is the one responsible for the prioritized backlog.)
☐Is the Product Backlog prioritized according to his/her latest thinking?
☐Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the backlog is emergent.
☐Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
☐Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories ?
☐Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be to write automated test and refactoring into the deﬁnition of "done" for each backlog item. ☐Is the backlog an information radiator, immediately visible to all stakeholders?
☐If you're using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
☐Can you help radiate information by showing everyone printouts?
☐Can you help radiate information by creating big visible charts?
☐Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?
☐Does everyone know whether the release plan still matches reality? You might try showing everyone Product/ Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery of scope/schedule drift.
☐Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time re-plan the release every Sprint. This probably requires deferring some work for future releases as more important work is discovered.
While you are encouraged to lead by the example of collaborating with team members on their work, there is a risk you will get lost in technical tasks. Consider your primary responsibilities to the team:
☐Is your team in the state of ﬂow? Some characteristics of this state :
• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with one's skill set and abilities).
• Concentration and focus, a high degree of concentration on a limited ﬁeld of attention.
• A loss of the feeling of self-consciousness, the merging of action and awareness.
• Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
• Balance between ability level and challenge (the activity is neither too easy nor too difﬁcult).
• A sense of personal control over the situation or activity.
• The activity is intrinsically rewarding, so there is an effortlessness of action.
☐Do team members seem to like each other, goof off 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?
☐Have you tried a variety of formats and locations for Sprint Retrospective Meetings?
☐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 taskboard reﬂect what the team is actually doing? Beware the “dark matter” of undisclosed tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to those commitments.
☐Does your team have 3-9 people with a sufﬁcient mix of skills to build a potentially shippable product increment?
☐Is your team's taskboard up to date?
☐Are the team self-management artifacts 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 deﬁnition of done, gradually making the code a more pleasant place to work?
☐Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?
☐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? ("Daily builds are for wimps." -- Kent Beck)
☐Do all tests roll up into the continuous integration server result?
☐Have team members discovered the joy of continuous design and constant refactoring , as an alternative to Big Up Front Design? Refactoring has a strict deﬁnition: changing internal structure without changing external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identiﬁers, excessive coupling between objects, etc. Refactoring with conﬁdence is only possible with automated test coverage. Neglecting refactoring makes it hard to change the product in the future, especially since it’s hard to ﬁnd good developers willing to work on bad code.
☐Does your deﬁnition of "done" for each Product Backlog Item include full automated test coverage and refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.
☐Are team members pair programming most of the time? Pair programming may dramatically increase code maintainability and reduce bug rates. It challenges people's boundaries and sometimes seems to take longer (if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.
☐Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and rarely the best.
☐Are teams independently able to produce working features, even spanning architectural boundaries?
☐Are your ScrumMasters meeting with each other, working the organizational impediments list?
☐When appropriate, are the organizational impediments pasted to the wall of the development director's ofﬁce? Can the cost be quantiﬁed in dollars, lost time to market, lost quality, or lost customer opportunities? (But learn from Ken Schwaber's mistakes: "A dead ScrumMaster is a useless ScrumMaster." )
☐Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer "no" if there's a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation.
☐Has your organization been recognized by the trade press or other independent sources as one of the best places to work, or a leader in your industry?
☐Are you creating a learning organization?
If you can check off most of these items and still have time left during the day, I’d like to hear from you. There’s no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in your situation. Once you start to realize what you could do to make a difference, you may ﬁnd yourself afraid to do it. This is a sign you're on the right track.