What is the difference between Agile and Scrum? Is Agile a Methodology? Is Scrum a Methodology? 

Here is a quick answer:
No, Agile is NOT a Methodology. Scrum is NOT a Methodology either.
Scrum is a framework with a set of events, accountabilities, and a structure that facilitates the creation of value through adaptive solutions for complex problems, employing empiricism and lean thinking. Scrum has been in use since the early 1990s. On the other hand, 'Agile' is a set of four values and twelve principles documented in the 'Manifesto for Agile Software Development,' established in 2001. These values and principles were distilled from 'light-weight methods,' such as XP and Scrum. As a result, you will find the values and principles outlined in the 'Agile' manifesto reflected in the Scrum Framework.

Scrum: The Lightweight Framework for Product Development (not a methodology)
History of Scrum: 
The Scrum framework was originally co-presented by Ken Schwaber and Jeff Sutherland at the OOPSLA Conference in 1995. This framework was born from their accumulated knowledge and experiences, crystallizing the first formal definition of Scrum.

At its core, Scrum is a lightweight framework designed to facilitate value generation through adaptive solutions for intricate challenges. Guided by empiricism and lean thinking, Scrum acknowledges that knowledge stems from experience and decisions founded on observations. Lean thinking, a cornerstone of Scrum, revolves around minimizing waste and concentrating on essentials.
The Scrum framework uses an iterative and incremental approach for complex product development.

Agile: Values and Principles for Modern Development

The term "Agile" stands and references the set of values and principles formulated and documented on on February 11-13, 2001 as the Manifesto for Agile Software Development.

The 17 individuals who were part of larger set of people around the world who were using XP, Scrum etc, which was collectively called “light-weight methods. These innovators were “uncovering a better ways to develop software” at a time when the norm was the use of cumbersome, time-consuming heavy-weight methodologies. These inflexible approaches often hindered adaptability and made the process of changing or adjusting the product challenging.

In a rapidly evolving world, attempting to construct a complex product using rigid methodologies, which mandated exhaustive upfront planning and strict adherence to that plan, proved illogical. The dynamic nature of the environment called for flexible 'light-weight' methods that could accommodate change. Such adaptable methods embraced evolving requirements and simplified responses to changes, contrasting with the predetermined rigidity of established plans.
Furthermore, these methodologies shifted the paradigm by recognizing individuals as unique entities, as opposed to interchangeable 'resources' within a hierarchical and bureaucratic system."

The manifesto's roots extend from Scrum and various other processes recognized as "lightweight methods," including XP (eXtreme Programming), DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming.

The Manifesto for Agile Software Development distills the core ideals of agility from these ‘light-weight methods’. Martin Fowler's poignant words—"We decide to use the term agile to describe this new breed of agile methods"—underscore the novelty and significance of this movement. You may find more of Martin Fowler’s account on his article titled “Writing The Agile Manifesto”

Jim Highsmith's account of the events leading to the manifesto's creation paints a vivid picture. You may find his account on his article titled “History of AgileManifesto”
​
Further Reading:
History of AgileManifesto by Jim Highsmith

Writing The Agile Manifesto by Martin Fowler

What does the Scrum Master do all day.

One of the questions that is often asked is how a Scrum Master is going to keep themselves busy all day or what they actually do.

In line with the 2020 Scrum Guide version, the Scrum Master has three key areas of focus: the Scrum Team, Product Owner, and the organization. For the Scrum Team, they coach self-management, guide Increment creation, and ensure effective Scrum events. With the Product Owner, they refine techniques for Product Goal and Backlog management, supporting clear and concise items and collaborative planning. For the organization, the Scrum Master leads Scrum adoption, advises implementations, and facilitates an empirical approach while removing barriers between stakeholders and teams.

The Scrum Master do not do their work, but the Scrum Master guides the Scrum Team to proficiency. Through coaching and the introduction of innovative techniques, they enhance efficiency and effectiveness, assisting the team in producing high-value Increments that align with the Definition of Done. This guidance includes helping the team "reflect in the mirror" for continuous improvement. By addressing impediments and dismantling barriers, they create an environment conducive to growth and value delivery.

Additionally, observing the team in action stands as a vital aspect of the Scrum Master's coaching role. Much like a football coach intently observing players on the field to provide guidance, the Scrum Master actively engages and observes the Scrum Team's activities. This hands-on approach allows the Scrum Master to glean valuable insights into team dynamics, interactions, and workflow processes.

Please look at the Scrum Master Section of the Scrum Guide for more details of how the Scrum Master serve the Scrum Team and the larger organization.

Another excellent resource is “An Example Checklist for Scrum Masters by Michael James available at  https://scrummasterchecklist.org

Is Scrum Master a Full Time Position?

Another common question that arises is whether one person can serve as the Scrum Master for multiple teams or if multiple teams can share a Scrum Master. The answer is: it depends.

If you ask Michale James, he will tell you that “An adequate Scrum Master can handle two or three teams at a time…. And a great Scrum Master can handle one team at a time.”  He recommends “one dedicated Scrum Master per team of about six when starting out.”

The Scrum Master has three key areas of focus: the Scrum Team, Product Owner, and the organization.

In situations where a Scrum Team is new to Scrum practices  or during an organization's transition to the Scrum framework, the presence of a dedicated, full-time Scrum Master becomes crucial. This ensures the availability of consistent coaching, guidance, and support necessary for establishing effective Scrum practices and aiding the team in overcoming challenges. Additionally, observing the team in action stands as a vital aspect of the Scrum Master's coaching role. Much like a football coach intently observing players on the field to provide guidance, the Scrum Master actively engages and observes the Scrum Team's activities. This hands-on approach allows the Scrum Master to glean valuable insights into team dynamics, interactions, and workflow processes. In addition to this, we also need to consider if the team is a newly formed team. If the members are new, the Scrum Master will have more work in helping them to be a cohesive team.

Another factor to consider when allocating a Scrum Master to multiple teams is that whether these teams are working on different products, each with its own designated Product Owner. The the Scrum Master's role involves serving the Product Owner by aiding in the definition of effective Product Goals, managing the Product Backlog with clarity, enabling empirical product planning within intricate contexts, and fostering stakeholder collaboration as required. Given that these responsibilities are tightly intertwined with the unique objectives and requirements of individual products, organizations should assess the practicality of assigning a Scrum Master to multiple teams only when the teams share a product focus. Note that Scrum Master Job is not doing the Product owner’s work but to help the Product owner in becoming proficient in doing this work and possibly helping the Product Owner in doing the work.

As the Scrum team and the organization mature in Scrum adoption, a Scrum Master might potentially support multiple teams. This works well when teams are adept in Scrum, self-managing, and have cross-functional abilities. As experience grows, the Scrum Master's role can shift from hands-on guidance to facilitating shared challenges and maintaining Scrum values. The decision to share a Scrum Master among multiple teams requires considering multiple factors. Factors include team autonomy, cohesion, and self-management capability, the extent of support needed by Product Owners, the Scrum Master's capacity for meaningful guidance, and the organization's dedication to an empirical approach. Ultimately, the decision should align with organizational goals and the objective of sustaining high-performance Scrum Teams that consistently deliver value in accordance with Scrum principles.
​
​Further Reading:
 The Scrum Guide 2020
An Example Checklist for Scrum Masters, by Michael James