The 3 basic principles of Scrum in an Agile Mindset

Scrum claims to be ‘Very Simple, but Very Hard’ with its 3 principles and 3 roles. Indeed, the rules of the game are easy to understand and the Scrum process that links everything together is one of the leanest ever seen. The hard part of Scrum is understanding why it works and how to make it work. If you implement Scum on the right side of the Agile Manifesto you’ll be having a very hard time making it work. More important than the rules and roles of Scrum is the spirit of the Agile Manifesto. Scrum is meant to be a practical guide for ‘doing Agile’.
It’s not easy to implement a process with roles, rules, principles, meetings and timeboxes in a way that brings ‘Humans and Interactions over Processes and Tools’ alive. How to create an atmosphere where commitment and the product backlog are not seen as a strict contract with the Product Owner and project management, but where ‘Customer Collaboration over Contract Negotiation’ is a normal thing. ‘Respond to Change over Follow a Plan’ seems a perfect match, however many Scum implementations seem to have a large focus on delivering releases on fixed dates, no matter what… And many Teams love ‘Working Software over Comprehensive Documentation’, where QA and management still demand All Documentation.
The point is… It’s hard to implement Scrum in a real Agile mindset.

This is not about why Agile works.
This is about why Scrum is Agile : Why are the 3 basic principles of Scrum making Scrum an Agile implementation ?
The 3 principles :
> Timeboxing                             — Everything is Timeboxed
> Selfmanaging Teams         — Teams operate in a selfmanageing mode
> Shippeable Code                     — Every Sprint delivers Shippeable Code

Why is this Agile ?   What makes that following these principles helps you work Agile ? Let’s take it one by one :
> Timeboxing

Everything is a Timebox. This is because you want to plan when you’ll get feedback from what you did. For a Sprint but also for a task. This feedback makes you understand better, and with better understanding the Focus can be stronger. Commitment makes that the maximal amount of feedback is generated so the learning curve can be steep.
> Selfmanaging Teams

Selfmanaging Teams generate a lot of energy because working closely together and being responsible for organizing yourselves is just simply a lot of fun ! All the fun and positive energy makes a Team very productive. This productivity results in the delivery of a lot of business added value, which again creates the opportunity to learn from this, to discuss it, to celebrate it, …… to interact !
Discipline is very important, because without discipline the Team will suffer from a lack of thrust and thus be no longer really selfmanaging, and therefor the fun will be lower, and the productivity will decrease with a lower (quality of) interaction at the end.
> Shippeable Code

Working pieces of the application are the only possible measurements for the true status of the project. The transparency of really knowing where we are and where we’re going creates a solid ground for good learning. Learning and improving things are like brothers. Quality of the shipped code is a critical success factor here, because when the quality is bad people will still assume it’s good. Hence, learning and improving will be done based upon this incorrect supposition.