This week I was at the ALM Summit in Redmond. There was a very interesting talk from David Starr of Scrum.org going over the recent changes in Scrum. These changes are, I think, designed to battle the things that have made Scrum unpalatable to many people.
The reality is that many people and organisation are failing at and being turned away from Scrum by the fanaticism that surrounds it. Scrum.org is taking these issues and tackling them head on.
At Northwest Cadence we worked with one team whose Scrum Coach told them that they were not doing Scrum. Why? Well, the Development Team had a disabled person who was unable to stand and they decided, as a team, not to stand up during the Daily Scrum. Shocked? Well you should be, we are in the era of intolerance and fanaticism and we all need a kick up the ass for that. Scrum.org is doing its part of that kicking and thus there are changes to the body of knowledge that is Scrum to make it more tolerant, adaptable and palatable for a wider group of people while not changing its core tenants.
The first change we saw was the publication of the new Scrum Guide by Ken and Jeff that saw the removal of all of those things that are not part of core Scrum. If you were to buy “Scrum the Board Game” you would not expect the getting started guide to include all of the strategies for playing the game, but instead it would contain the “rules” of how to play.
Figure: The rules of the game, not the strategy of how to play
The Scrum Guide is just such a distillation of the core principals upon which the Scrum Framework is based. Once you have these core principals under your belt you can move forward with instituted all of those “practices” that will help you do Scrum well. There are many books, blogs and forums to help formulate Strategy and many consultants that will help you with adopting Scrum effectively. (Hint: http://nwcadence.com )
Figure: You are here!
So if there is this line between “not Scrum” and “Scrum” I want to know definitively if I am at this line. To do that I need a simple measurable checklist that lets me know that I am there. A minimal “Definition of Doing” or “Scrum Fitness test”, if you will, that tells us that we are at the first milestone and can then start to look at more advanced concepts to improve our performance.
A simple measurable checklist:
- … an ordered Product Backlog
- … Development Teams of 6+-3
- … have a Product Owner who owns the backlog
- … a Scrum Master who is responsible for process
- … have Sprints of 1 month or less
- … Sprints are of a fixed length
- … a Sprint Backlog that shows Remaining Work
- … a Sprint Backlog created at Sprint Planning
- … Review & Retrospective at the end of each sprint
- … working software each Sprint
- … stakeholders who inspect the software increment
Figure: A simple measurable checklist of Scrum
If you can say yes to each of these things then you are doing Scrum. Are you doing good Scrum? Well, probably not… but you are doing it.
Then what else do you need?
Well, you will find it hard to continue to deliver working software each sprint (#10) without things like Automated Testing and Automated Build. You will also find it hard to start climbing that hill towards High Performing Scrum without visualising your work (Kanban), limiting work in progress, and concentrating on optimising Flow both at the micro (inside of the Sprint) and at the macro (wrapping Scrum).
There are many more things that will help and many of them will become Scrum Extensions on Scrum.org as they are submitted and approved. This results in the replacement of the phrase “I am doing Scrum but…
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
The Sprint is a container for Planning and not necessarily for Delivery
Explains how Scrum Sprints are primarily for planning, not fixed delivery, and discusses aligning delivery schedules, continuous deployment, …
Pragmatism crushes Dogma in the wild
Explores how practical use of Scrum fosters adaptability and resilience in teams, highlighting the value of flexibility over rigid rules in …
There is no "do agile" there is only "be agile"
Explores the difference between adopting agile practices superficially and truly embracing agile values, highlighting the need for deep …
My journey into Professional Scrum
Reflects on experiences with Professional Scrum, highlighting its impact on software development, team culture, training, and the challenges …
Debunking the Top 5 Myths About Scrum: Unlocking Agile Success in Your Organisation
Explores and corrects common misconceptions about Scrum, clarifying its true principles, events, planning, and governance to help teams …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
The Definition of Done is a Commitment to Quality
Defines the Definition of Done in Scrum as a clear, shared standard for quality, ensuring increments are releasable, transparent, and …
Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar
Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …
Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Stop confusing acceptance criteria with definition of done, learn the crucial difference to boost quality, speed, and trust in your agile …
How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Unlock a smarter Definition of Done, start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives …
Why Most Transformations Fail Without Honest Conversations
Most transformations fail without open, honest conversations that address real issues, making transparency and tough dialogue essential for …
Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.