My Philosophy on Scrum
Scrum is, fundamentally, a project management framework. It was born in the world of software development, but it was always and will always be a framework that supports "Agile" project management.
​
I will continue to use the word "Agile" to indicate a specific mindset and approach, not agility in general.
​
Many people believe that Scrum is an Agile software development framework, but that stems from an incorrect understanding of what Scrum really is. Scrum was simultaneously born out of two needs: to control and improve the development process (Ken Schwaber) and to report development progress in a way that's better than using Gantt charts (Jeff Sutherland). One of the best ways to understand that Scrum is fundamentally a project management framework is by reading Jeff's paper titled, How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum.
​
Because of the simple fact that Scrum is a project management framework, it's been used for all kinds of non-software projects, such as teaching classes at schools, managing churches and companies, building cars, and even planning weddings.
​
So, why is this a big deal?
​
Scrum doesn't deal with the most important aspect of software development: requirements. As my esteemed colleague, Amir Kolsky, likes to say, given two development teams, one the best in the world and the other an average team, only the team working with good requirements will produce the right product, and even the best development team in the world will produce the wrong product if they're working against bad requirements.
​
Instead, Scrum and its younger corpulent cousin, SAFe, have accepted that bad requirements are unavoidable and have instead built processes that allow bad deliverables to be discovered and addressed earlier than with traditional project management approaches. Noble as that may be, neither frameworks address the root cause of most failures in software development: bad requirements.
​
To that end, I've focused a great deal of my learning and craft on addressing bad requirements. You can learn more about this on my Software Requirements page.
​
To be clear, I'm not anti-Scrum. I am a supporter of Scrum for what it was designed for, which is work-flow management. Nonetheless, it's a tool and only a tool, and it should be used with discretion, not as dogma. At the risk of being overly detailed, I'll explain a bit more.
​
Trouble in Paradise
One of the biggest problems with Scrum is not Scrum itself but the misunderstanding and dogma that has sprung up around it. I believe this stems from the fact that, as a project management framework, it appeals primarily to program/project management offices (PMOs) and to executives and managers with project management backgrounds or who are mainly focused or even responsible for project delivery and completion. Adding to this, it's been my experience that the vast majority of people who fall in this project-mindset category do not understand software, and have never directly coded any commercial software and managed that code for long periods.
​
This project mindset and lacking an understanding of the nature of software and what makes development teams succeed, lead to a paint-by-numbers approach when it comes to adopting frameworks such as Scrum and SAFe. Follow the "recipe" step by step and if it doesn't work, something must be wrong with how you did it. It's a dogmatic approach that results from not understanding the underlying theory of software development, and from not understanding the objectives of the practices (i.e. the problems intended to be solved by them) that have become canon for these frameworks.
​
If you think theory is not important, I'll refer you to W. Edwards Deming who famously had this to say about theory:
"Experience teaches nothing. In fact there is no experience to record without theory… Without theory there is no learning… And that is their downfall. People copy examples and then they wonder what is the trouble. They look at examples and without theory they learn nothing." https://deming.org/quotes/10177/
All of this has resulted in Scrum becoming the thing around which everything else in the organization must be organized, religiously, regardless of whether it's appropriate for the organization or leads to business agility. It has become the tail wagging the dog. SAFe is even worse in that regard, but I'll leave that for another time and page.
​
If your company has adopted Scrum and you do not have an absolute master of Scrum guiding the adoption or continued use of Scrum, you're inviting trouble and potentially wasting obscene amounts of resources, and may never achieve your ultimate goal: business agility. To be clear, by "master of Scrum" I don't mean someone with a "Scrum Master" certification, because that requires just two days of training to obtain. What I mean is someone who understands it at its core and who can extend and modify it to serve your needs; someone who understands it as a tool in their toolbox and who has absolutely mastered the use of this tool to solve the right problems in your organization.
​
Even more importantly, you require a master of whatever craft you're practicing and trying to use Scrum for. So, for software development, you need someone who deeply understands software development and what is required to succeed with that, and only then are you ready to adopt and adapt Scrum purely in service of this primary need: developing and evolving software. Never the other way around.