‘Because Scrum Guide says so’ is an explanation I’ve heard few times recently from beginning ScrumMasters. Fist 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. Which usually makes sense, as many modification of Scrum are generated by 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”).
However, from every ScrumMaster, no matter how unexperienced 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 that argument ‘Because Scrum Guide says so’ doesn’t work when talking with customers and executives. Therefore every ScrumMaster should know the answers for ‘why we can’t have five Product Owners?’ and ‘why we should pay for some who’s not creating any code and just observing the team?’. How do you keep your job otherwise?
Over last Scrum courses I started explaining Scrum as having several layers:
- Scrum Values – what is important for us?
- Scrum Principles – why we do what we do?
- Scrum Framework – what and how 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 few examples, Daily Scrum will be part of Scrum Framework. Task board and burn down charts are good practices and most electronic ‘scrum tools’ are usually bad practices. But that’s a longer story for separate article.
From Values to Principles
Scrum bases on Agile values written down in Agile Manifesto, but it also add its own five values, which found their way to Scrum Guide in 2016. These are Openness, Respect, Courage, Commitment and Focus. It also bases on Agile Principles, but it add 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 own 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 minimal list allowing for defining Scrum Framework.
My list keeps evolving over time as I validate it with participants of my Certified ScrumMaster courses. Below you can find current version.
Deliver value every short cycle of month or less (Sprint).
Your context matters, so build up your own process.
Ensuring Transparency is cheaper than enforcing control.
Inspect and Adapt frequently (every day and every Sprint) to head the right direction.
Team knows how to do it, let the team decide.
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
Limiting work in progress, setting time boxes for planned work and removing distractions let you focus
Every Sprint try something different.
You can also download Scrum Principles in PDF version.
Let me know what you think about this list. Is there something missing? Some point duplicated? Or something not clear? Did it help you to understand why Scrum work?
Discovering Scrum Principles
In 2017 I've spoken about Scrum Principles during Agile Tour Lituania.