The document outlines the responsibilities of a Scrum Master which include removing blocks for the team, acting as an unbreakable buffer, championing Agile practices, being the chief connector to solve issues, providing frequent feedback, and building individual ownership without acting as a team leader. It notes that the Scrum Master role can vary in visibility from almost invisible on small dedicated teams to highly visible and busy on larger teams with more challenges.

1. Dan Shupp CTO, Tech Propulsion Labs Copyright 2010 Tech Propulsion Labs , Inc. How to be a great Scrum Master

2. A Warning This is not an introduction to Scrum or Agile I assume that you are familiar with the process, and know what this chart means

3. Scrum Master responsibilities Responsible for the process the team Continuous improvement of both Not responsible for Technical decisions The business The Scrum Master is Remover of blocks Unbreakable buffer Champion of Agile Chief connector King of feedback Not a “Team Leader” Builder of individual ownership

4. Remover of blocks, impediments The Scrum Master has to create an optimal working condition for the team and is responsible for maintaining this condition Issues Dependency on people outside the team. Missing hardware or software Cannot get a key decision from the business Problems of individual Team Members Need help with debugging Cannot complete a task & needs help Devs, BAs, POs all have this problem Problems of organizational structure and expectations The team or company is missing or deficient in key roles Stakeholders not respecting the process A Scrum Master shouldn’t solve these issues himself, but he is still responsible for getting them solved. This takes a lot of time Requires great authority and courage.

5. Buffer for the team Handle management messing with the team “just for a day”, “I need an estimate”, “answer some tech questions”, “need technical help”, “maintenance on an old project” Actually, this stuff important to the business and have to get done Notice I said ‘handle’ not ‘prevent’ Build time for interruptions into the iteration plan Schedule interruptions and group them together. Delay interruptions

6. Champion Agile Practices Teams new to Agile often underapply their practices Practices are mutually-reinforcing Adopt as many as you can verify Start as close to the “book” definition as possible Make it easy and clear for Team Members to do their jobs Walk new Product Owners and BAs through their job Make sure devs know the Definition of Done Prepare people to lead standups, planning meetings, and retrospectives

7. Chief Connector You don’t solve problems yourself…you cause them to be solved by Connecting the right people together Getting the results and actions items documented Following up Retrospectives are good for this ideally you follow up earlier

8. King of Feedback Frequent feedback to all team members and stakeholders is the reason that Scrum and Agile work! People don’t learn without thoughtful, helpful feedback This takes a lot of time to do well But it pays off, hugely, quickly The Scrum Master is the lead for this, and retrospectives are the method Is the PO doing his job well? Are estimates good and improving? Are we following the “Definition of Done”?

9. Not a “Team Leader” Ensure that the team obeys the rules and realizes the method of Scrum Should not assign tasks, own requirements, or make decisions The SM is not responsible for task completion This is very hard in practice Interfere only when the process is not being followed You are the team’s coach, representative, buffer, policeman Not the team’s director, owner, or manager

10. Building individual ownership Scrum Master Team Member Team Member Team Member Team Member Team Member Team Member Don’t ask Team Members questions, have them report Prepare people ahead of time to lead their own discussions Team Member Team Member Team Member Team Member Team Member Team Member Scrum Master

11. The Scrum Master Experience “ On a small team with dedicated people who mostly know what they doing, the role of SM is almost invisible; on a larger team trying to cope with vague requirements and power struggles the SM will be highly visible and probably never have a moment to themselves, as they will become the lightning conductor for all the frustrations of the team (and stakeholders outside it).” “ There's no substitute for knowing what you want to achieve and having a small team of people who know how to achieve it. If you have that, and you "adopt SCRUM", you will probably be convinced quickly that being a Scrum Master is easy. But if instead you have a big mess of a team, and an undefined goal, and a lot of political fighting going on, and you "adopt SCRUM", you will probably come away thinking that being a Scrum Master is a full-time (perhaps impossible) job requiring a combination of very rare talents. Most real teams are probably somewhere between these extremes.” -From http://stackoverflow.com/questions/127807/what-does-a-scrum-master-do-all-day

12. End Q&A! Slightly nicer picture of a Rugby Scrum:

13. Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity, the art of maximizing the amount of work not done, is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.