In order to see how Scrum fits the Agile model, let’s take a look at the Agile Manifesto and Scrum’s view on those values:
Individuals and interactions over processes and tools: Scrum does not believe in over-engineering the process. Although it has some prescriptions when it comes to roles (Scrum Master, Product Owner, team), meetings (daily scrum, retrospectives, demos, etc.) and artifacts (e.g. burndown charts), there is no detailed documentation, no project plans, no incredibly detailed processes to follow, no extensive description of project roles. Scrum does not need detailed descriptions like RUP or Prince2, it is kept extremely simple. Scrum is a rather minimalistic approach, the absolute basics are given, anything still needed can be added later.
Working software over comprehensive documentation: Scrum targets this principle with the combination of sprints and demonstrations. Sprints are small size iterations, which are still long enough to deliver features, customer value. These features are then later demonstrated during a meeting at the end of the sprint. The audience of this session always contains the product owner, and possibly end users too. The reason behind these sessions is that the product owner to accept the delivery, or suggest changes to be incorporated. Every two weeks (the usual length of a sprint) some working software is delivered, so customers can start using the product right away. Documentation is usually ad-hoc in real life Scrum implementations, and entails a number of wiki pages most of the time.
Customer collaboration over contract negotiation: As mentioned earlier, in an ideal Scrum setup, the customer attends the demos so they can see for themselves what the next release of the software contains. Also, the product backlog represents a list of customer requirements. Such a way, Scrum delivers value based on customer requirements with the approval of the client at the end of the sprint.
Responding to change over following a plan: Scrum leaves room for team improvement with the retrospectives. Retrospectives are meant for teams to come together, revise their process and experiment with new things. Scrum is flexible: sprint lengths are not set in stone, project roles can be added if the situation requires it, meetings can be organized for better performance. With the retrospective, the team is able to adapt to the current situation and respond to changes in customer requirements, competitors’ movements, product success, etc.
Based on the four values of the Agile Manifesto, Scrum is fully qualified as an Agile process. All the principles in the manifesto are addressed, the primary goal is to deliver customer value and not to stick to a plan created upfront.