‘Because Scrum Guide says so’ is an explanation I’ve heard a few times recently from beginning ScrumMasters. At first, I was scared, but then I realized that is the way many of them learn Scrum. They read the Scrum Guide or are being told Scrum rules by wannabe Agile Coach and then they hear to follow Scrum by the book. This usually makes sense, as many modifications of Scrum are generated by the approach to hide problems made visible by Scrum. For example when every team member has own goals then usually coordination is not required and teams skip Daily Scrums. We even call it “ScrumBut” because of the way it’s usually described (“We do Scrum, but we skip Daily”).
Knowing Why
However, from every ScrumMaster, no matter how inexperienced he or she is, I’d expect to be able to answer not only ‘what’ or ‘how’ questions but most of all the ‘why’ questions. For example, besides knowing what meeting we have every day or how do we run Daily Scrum it’s more important to know why to have Daily Scrum. Especially the argument ‘Because Scrum Guide says so’ doesn’t work when talking with customers and executives. Therefore every ScrumMaster should know the answers to ‘why can’t have five Product Owners?’ and ‘Why we should pay for someone who’s not creating any code and just observing the team?’. How do you keep your job otherwise?
Scrum Onion
Over the last Scrum courses, I started explaining Scrum as having several layers:
- Scrum Values – what is important for us?
- Scrum Principles – why do we do what we do?
- Scrum Framework – what and how do we do it?
- Good Practices – what are ideas we should try?
- Bad Practices – what are ideas we should avoid?
Core Scrum consists of layers 1-3. The remaining two layers are practices different teams and organizations tried with different results, so these are either things you could try, or avoid yourself. Just to give you a few examples, Daily Scrum will be part of the Scrum Framework. Task boards and burn-down charts are good practices and most electronic ‘scrum tools’ are usually bad practices. But that’s a longer story for a separate article.
From Values to Principles
Scrum is based on Agile values written down in the Agile Manifesto, but it also adds its own five values, which found their way to the Scrum Guide in 2016. These are Openness, Respect, Courage, Commitment and Focus. It is also based on Agile Principles, but it adds its own principles as well. For some reason, I’ve never seen them formally written down by Ken Schwaber or Jeff Sutherland, co-authors of Scrum Guide. Personally, I find it very important for every Scrum Master and Agile Coach to know these. Therefore I’ve created my list based on my experiences, different resources and discussions with other trainers and coaches. The assumptions behind my list are:
- The Scrum Principles build upon Agile Principles, so there’s no reason to duplicate them
- The Scrum Principles should be a minimal list allowing for defining Scrum Framework.
My list keeps evolving as I validate it with participants of my Certified ScrumMaster courses. Below you can find the current version.
Scrum Principles
- Increment
Deliver value every short cycle of a month or less (Sprint). - Context
Your context matters, so build up your process. - Transparency
Ensuring Transparency is cheaper than enforcing control. - Empiricism
Inspect and Adapt frequently (every day and every Sprint) to head in the right direction. - Self-organization
The team knows how to do it, let the team decide. - Collaboration
A team is more than a sum of individuals. - Product Owner
One person deciding on direction helps in Optimizing Value. - Scrum Master
One person supporting the system makes everything go smoother - Focus
Limiting work in progress, setting time boxes for planned work and removing distractions let you focus - Experiments
Every Sprint tries something different.
You can also download Scrum Principles in PDF version.