Ye leave the commandment of God, and hold fast the tradition of men. Mark 7:8 (ASV)
I never in my wildest dreams would have thought I would ever write a post “defending” Scrum especially considering that I’m not a Scrum advocate (ask the folks I work with, I think they’ll confirm that 🙂 ). Then again, Scrum definitely doesn’t need me to come to its defense and yet I’m compelled to share a few thoughts down – at least for posterity’s sake.
Every week I come across a post indicating why Scrum did not work for a team and how they switched (or evolved as some describe it) to something else. (I come across similar posts on diets and soccer formations as well). First of all, I’m happy that the teams found something that worked for them. I hope that if they wanted to work in Agile-based manner, their new approach allows for that. After all, “we are uncovering better ways…” aren’t we?
However, I find it irresponsible for these people (and other Agile thought leaders) to blame Scrum for certain things that occur especially when these things are really not Scrum things. It’s important to remember that Scrum is a framework that needs to be filled out if software is actually going to be developed and delivered. Scrum, via the Scrum Guide, doesn’t provide much (explicit) guidance on how to actually develop and deliver software. It provides a framework for managing the software development process.
Before you begin to debate this with me, let’s simply agree that the Scrum Guide is the official definition for Scrum. In my opinion, any other text on Scrum is the author(s) description of how the framework was implemented and what additional techniques or practices were found beneficial as the framework was leveraged. Unfortunately, some of these techniques (promoted by Agile and Scrum thought leaders) have over time become characterized and adopted as Scrum rules when they are really techniques used with Scrum. They are traditions. Let me provide a few examples.
Scrum currently says nothing about how estimation should be done and yet it would seem that Story Points estimation is considered THE Scrum estimation approach.
Scrum requires that a “potentially releasable product increment” be created by the end of the defined time-box. I don’t see anything in this requirement that prevents a team from releasing sooner if both they and their customer can handle it. I also find this supposed limitation to be a bit hilarious. I mean, it wasn’t it but a few years ago that many organizations were struggling with delivering software more than one time a year!
Is this in the Scrum Guide?
These days it’s become quite chic to state that instead of focusing on the individuals doing the work, we should focus on the work itself. In other words, focus on the baton, not the runner. The criticism of the Daily Scrum then is that every day, it’s the same (paraphrased) three questions that are asked:
- What did I do yesterday?
- What do I intend to do today?
- What impediments do I possibly have?
Unfortunately, these three questions (while represented in the Scrum Guide) are removed from the larger context for which they are a part of. Here are the first two lines of this section in the Scrum Guide:
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.
In fact, if you are interested, take the time to read that section (and the entire Guide) on your own. Tell me where it requires you to “stand up”!
These are a few examples of things I often read people say “Scrum made them do…” So is this a post to convince you to use Scrum? Nope. First of all, I don’t believe it’s always a fit for the type of work a development team might be doing. Secondly, context matters and depending on your context (of which I have no idea of), something else might be better. However, I will challenge you to read for yourself what the rules of Scrum are so you can separate those rules from the traditions of men and make informed decisions. Study to show thyself approved.
When I have these conversations in social settings, its suggested that the Scrum Guide has changed over the years. When did change become a bad thing? What happened to inspect and adapt? Show me a method or framework that doesn’t evolve and I’ll show you a dead method or a dead framework. The real problem is that many (maybe even most) Scrum Masters that I interact with don’t evolve beyond what they may have learned in their 2-day CSM course 7 years ago. Ask them the last time they actually looked at the Scrum Guide or how many Scrum books they have read. The answer is often quite disturbing and disappointing. (By the way this point extends beyond Scrum and into Agile (as an approach to software delivery). The cargo-cult behavior of people who promote “inspect and adapt” can be quite disappointing). Don’t even get me started on managers who try to impose Scrum (or any other Agile approach for that matter) in their organizations without having a clue.
Scrum is a framework that your team can leverage (if it’s a fit) to develop and deliver products in an Agile manner. It’s not perfect because nothing really is. There is no silver bullet and that includes your new approach as well.