If you are doing Scrum but the Scrum Master tells the team what to do then you may be missing the point.
Ultimately the Scrum Master should never tell the Development Team what to do and they should make sure that the Development Team has both the knowledge and the skills to work things out for themselves. This is critical to the teams ability to self organise going forward because we all learn by the mistakes we make.
A Scrum Master does NOT equal Project Manager. In Scrum, project management is the responsibility of the entire Scrum Team (Scrum Master, Product Owner and Development Team) and is distributed as such, with the Scrum Master keeping an eye on the mechanics of Scrum to make sure it is working. The top-down management model traditionally used for project execution is rejected in favour of self-organization and shared accountability. While this is alien to many organisations it has been proven time and time again to increase the accountability, efficiency and quality of the software delivered by the Scrum Team.
In Scrum the responsibilities between the Scrum Master and the Development Team are very explicit. The Scrum Master is there to serve the Development Team, not to manage them.
- Scrum Master
- Scrum Mechanics
- Individual & Team Training
- etc.
- Development Team
- Conflict Resolution
- Engineering Practices
- Grooming the Backlog (with Product Owner)
- etc.
All implementation, whither centred around working together, working to build software or working on the backlog, is the purview of the Development Team. This, however, does not mean that the Development Team are left to flounder. I mentioned that the Scrum Master is responsible for making sure that the Development Team has the Knowledge and Skills necessary to allow that Development Team to resolve things themselves.
In order to allow the Scrum Master to provide the knowledge necessary to resolve conflicts they could ask questions of the team to illicit knowledge and learning.
The term Socratic questioning is used to describe a kind of questioning in which an original question is responded to as though it were an answer. This in turn forces the first questioner to reformulate a new question in light of the progress of the discourse.
-Socratic method
Using this method a Scrum Master can “guide” a Development Team through the muddy waters of finding solutions to problems without enforcing their views or restricting the creativity of the Development Team.
Groups that defer to a person of higher status will miss many good ideas, and fail to tap and develop the talents of the entire group.
-Esther Derby: Why Group Dynamics and Interpersonal Skills Matter
In addition the Scrum Master should never provide the team with options, unless they are specifically asked by the team for their opinion or their assistance. This removes the responsibility of the Development Team to make decisions and may limit the options that the Development Team creates. If they are provided with options they are unlikely to try to formulate their own and if that option fails they can claim it is the responsibility of the person who provided that option and not of the Development Team.
You will have to have, learn, or improve requirements gathering and presentation techniques; quality techniques; refactoring; customer engagement; collaboration; teaming; conflict resolution techniques; and other practices, as well. But the Scrum framework will help you by providing continual feedback on your progress and success.
-Ken Schwaber: Scrum As A Framework
The Development Team must be empowered to come up with resolutions to the problems that they have without interference.
References
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
“Teams are self-managing
Explains how self-managing teams in Scrum need structure and leadership, clarifying the Scrum Master's role in maintaining clarity, …
Redefining the Scrum Master: From Boss to Empowering Facilitator
Explains how effective Scrum Masters empower teams through facilitation, support, and coaching, moving away from authority and …
Why the Scrum Master’s True Power Lies in Influence, Not Authority
Explains why a Scrum Master leads through influence, not authority, focusing on building trust, fostering team effectiveness, and supporting …
Unpacking the Scrum Master Myth: Why Servant Leadership is Key to Team Success
Explains why the Scrum Master is a servant leader, not an authority figure, and how this approach empowers teams, encourages autonomy, and …
Too many Scrum Masters believe they don’t need technical skills
Highlights the importance of technical knowledge for Scrum Masters, arguing that understanding team-specific skills is essential to …
Unlocking Team Potential: The Essential Role of a Scrum Master in Agile Success
Explains how a Scrum Master empowers Agile teams by bridging business, technical, and organisational needs to boost effectiveness, …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
The Definition of Done is a Commitment to Quality
Defines the Definition of Done in Scrum as a clear, shared standard for quality, ensuring increments are releasable, transparent, and …
Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar
Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …
Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Stop confusing acceptance criteria with definition of done, learn the crucial difference to boost quality, speed, and trust in your agile …
How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Unlock a smarter Definition of Done, start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives …
Why Most Transformations Fail Without Honest Conversations
Most transformations fail without open, honest conversations that address real issues, making transparency and tough dialogue essential for …
Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
Why Big Bang Rewrites Fail: How Sustainable Change and Engineering Excellence Transform Legacy Systems
Ditch the Big Bang rewrite. Discover why sustainable, in-place change drives true engineering excellence and lasting transformation in your …
Is Agile Really Just a Mindset?
Explores Agile as a disciplined system of delivery, emphasizing engineering excellence, CI/CD, observability, and system design over mindset …
Telling People What to Do Is Not Leadership. It’s a Failure of System Design
Explores why real leadership means designing systems that enable team autonomy, flow, and accountability, rather than relying on …
From Legacy Pain to Modern DevOps: My Proven Roadmap for Real Engineering Transformation
Transform legacy engineering with a proven, step-by-step approach, learn how to automate, adapt, and build a resilient, modern DevOps …