The Scrum framework is defined in The Scrum Guide; maintained and published by Scrum.org.

To get an answer to this question you must first ask the question ’What is Agile?’.

The definition of Agile is owned by the Agile Alliance that was formed in February 2001, at Snowbird, Utah.  The first Agile Alliance publication was the Manifesto for Agile Software Development closely followed by the 12 Principles Behind the Agile Manifesto.

So, to answer the question, the Agile Manifesto and Principles are listed below with the explanation of how the Scrum Framework implements them.

• The Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more”© 2001, the Agile Manifesto authors.

These are the 4 Agile Values and any product development framework that purports to be ‘Agile’ must embody these Values in the specifics of the framework.

It is worth noting here that although the Agile Manifesto specifically talks about ‘software development’, the Agile Values and Principles can be used to develop non-software products.

Agile Manifesto explanation and how Scrum embodies the Agile Values

 1. Individuals and Interactions:  There must be advice about how the people involved interact and communicate:

Scrum defines the roles for product development and specifies the necessary individual and group interactions.  Although Scrum does define a product development ‘process’, it is tool agnostic.

 2. Working software:  The product development team’s focus must be on producing working increments of the proposed product and not in documenting what has or needs to be done:

The Scrum framework proposes a minimalist list of required ‘documentation’.

 3. Customer Collaboration:  The best results for product development come when all those involved work together as one ‘team’ to solve problems whether they be business or technical people and whether they are internal or external to the product development organisation:

Scrum defines a Scrum Team that includes business and technical people.

 4. Responding to change:  The major drawback to ‘waterfall’ processes is that they recommend obtaining all detailed requirements before development starts and create the development plan; ‘contracts’ are set in place and organisations think that they have a high degree of functional, time and cost predictability.  However, as we all know, the development team discover hitherto unforeseen problems and the business change their minds. To cope with this situation, ‘waterfall’ processes introduced ‘Change Procedures’ which became bureaucratic and time wasting.

Scrum uses a high-level ‘requirements list, the Product Backlog, ordered by business value the content and ordering of which is the responsibility of the Product Owner.  FURTHERMORE, the Scrum framework has frequent, short events that include consideration of recommended and requested changes to the Product Backlog.

• The Agile Principles

1. Our highest priority is to satisfy the customer through early and CONTINUOUS delivery of valuable software.
   The Scrum framework recommends that product development takes place with short, 2 to 3-week development periods, Sprints, that result in a working increment of the required product.
   If appropriate, the increment may be released to the live environment at the end of a Sprint or the increments from several Sprints may be released together at 2 to 3-month intervals.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
   The Scrum framework recommends that the product development requirements defined before development begins are of the lowest level of detail of the NAMES of the business processes necessary for the product; they are ordered by business value.
   At regular intervals, at least once in every Sprint, consideration is given to requested changes to the requirements and ordering.  The result is that the highest business value is achieved in any given timeframe.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
   See PRINCIPLE 1 above.
4. Business people and developers must work together daily throughout the project.
   Scrum defines a short, 15-minute, daily event called the Scrum, when all Development Team members, both business and technical and whether full or part-time, come together to state what was done during the previous day and what is planned to do for the next day.  Also stated are any problems that individual members are facing.
   Any discussion of ‘matters arising’ from the daily Scrum event are conducted after the Scrum has ended.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
   The Scrum framework does not recognise the term ‘project’ preferring to focus on product development which may be more open-ended than the concept of a project.
   However, Scrum does implement the spirit of this Principle in that it recommends appropriate empowerment to the Scrum Team and encourages cross-functional, self-organising Development Teams; the day-to day work of the Development Team is the sole responsibility of the Team and not a ‘project manager.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
   The Scrum framework defines all the  events when the Scrum Team and stakeholders must come together to plan, REFINE and review the work and to reflect on the detail of the day-to-day activities being followed; it suggests that these are done in face-to-face environments.
   However, much of today’s product development involves people in geographically dispersed locations and it is financially and culturally prohibitive to gather all required people at 1 location.
   Although not part of the Scrum Guide, most Scrum practitioners take advantage of the abundant video-conferencing and desktop sharing facilities available from secure internet environments.
7. Working software is the primary measure of progress.
   The Scrum framework requires that the product increment requirements that are developed in a Sprint must pass the quality criteria defined in a ‘Definition of Done’ to be considered complete and fit for demonstration to stakeholders.
   Organisational product development progress is measured by the number of requirements that have been completed; task and activity progress, if used, is the sole responsibility of the Development Team and is not published to persons outside of the Development Team.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   The Scrum Guide does not mention sustainable development specifically.
   However, it is part of the Scrum Master’s responsibilities to remove impediments to the Development Team’s progress; one such impediment may be that the Development Team as a whole, individual team members and/or stakeholders may be working too hard.
   It is a proven fact that productivity reduces when people are stressed and tired.  The Scrum Master must look-out for signs of ‘overwork’ in those involved in the product development and help overcome the problem.
   In this way, the Scrum Master can promote sustainable development.
9. Continuous attention to technical excellence and good design enhances agility.
   The Scrum Guide does not mention technical excellence or good design specifically.
   However, the Guide does require that only “Done” requirements can be demonstrated to stakeholders.  The ‘Definition of Done’, the checklist of criteria that defines when a requirement is “Done”, will vary from product to product and organisation to organisation but will most probably include technical excellence and good design criteria.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
    This is a widely misunderstood Principle but essentially means ‘only do today what is essential to do today’.  For example, is it essential to gather all of the detailed requirements before development work begins? The answer is no; we gather the most important requirements at a high-level of detail; these may change over time and the time taken getting the details ‘up-front’ will be wasted.
    All of the aspects of the Scrum Guide embody a minimalist approach to the amount of work to be done.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
    Scrum requires the use of cross-functional, empowered and self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
    The Scrum Guide defines the Sprint Retrospective event where the Scrum Team inspects itself and creates a plan for improvements to be enacted during the next Sprint.