The 3 basic principles of Scrum in an Agile Mindset

Geert Bossuyt

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

Selfmanageing 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

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.

Comments (3)

  1. soudmaijer - Reply

    May 26, 2010 at 7:38 am

    Hi Geert, nice write up. I think most people do understand the basics but have a hard time applying them. Your comment on creating an atmosphere triggered me:

    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.

    Also creating an atmosphere where people are willing to adopt an Agile mindset can be really difficult IMHO. I think this requires a special skillset which is not directly IT related. Personally I think that this can also be one of the pitfalls of Scrum. When people are willing to adopt Scrum or an Agile mindset but just can not make it happen because their environment is not ready for it yet!

  2. Geert Bossuyt - Reply

    May 26, 2010 at 10:21 am

    Hi Soudmaijer,
    I totally agree that creating willingness for Agile adoption can be really difficult.

    The readiness of the environment is definitely one of the key succes factors.
    Another important factor is the individual ability of each person to go along with the change.
    Does a person see the advantages ? Does he see what's in it for him ? Isn't he already tired from changing 4 times in the last six months ? ....

    Don't forget: 'The environment' is often just 1 or 2 managers with their own reponsibilities and duties. And managers are also persons.

  3. Pankaj Ahuja - Reply

    March 15, 2016 at 12:06 am

    Its a good write up and brings a critical point around "High performing Teams"- Scrum is a tool-set and an approach wherein teams can be more productive (comparatively) and enjoy high level of trust among each other. A high performing team has always been seen as the key in order to have a something valuable delivered. This is applicable to any methodology - that if the past (waterfall), present (Agile, XP, Pair Programming, TDD, BDD, ATDD, Lean) or methodologies of future.

Add a Comment