December 20, 2017 // By Paul Grizzaffi
I first learned of Scrum during my latter years at Nortel. I attended an in-house session by (I think) a guest speaker. During her talk, the speaker emphasized that Scrum is not a software development methodology; it’s a planning framework. She said she even used Scrum for planning some of her at-home activities and chores. Looking back on my experience with Scrum, her point is consistent with what I’ve seen since; on one team we used Scrum planning and XP development (give or take) because we were already used to Scrum. It worked pretty well for us because XP filled in many of the development blanks that Scrum doesn’t address.
Another aspect of Scrum that gets forgotten or abused is the notion that the Scrum framework is intended to be evolved to meet a team’s business and working needs. Some teams begin their Scrum journey by adhering to the rules and guidance exactly as they were taught. It’s not a bad way to kick off a journey: if we don’t know where we’re going, perhaps we should follow a map, at least until we get to a familiar place. Over time, if we keep starting from the same place and traveling to the same place, we may find better routes. New roads get built, traffic accidents delay traffic, and bad weather make for adverse driving conditions. If we continue with “the one true way”, we may miss opportunities for improvement in our travels and possibly become less effective or efficient than we originally were. The same is true with Scrum: if we mindlessly follow what we learned about Scrum because “the book said” or because “Gary, our instructor, said”, we can miss out on opportunities to be more appropriate with our use of Scrum.
In other cases, teams have received training in Scrum and before really trying it “as written”, they change many aspects of the framework; to me, that’s kind of like salting our food before we taste it.
I like to use the analogy of baking a cake. If we’ve never eaten or even seen a cake, it might be a good idea for us to follow the recipe for a cake exactly as written. After we’ve successfully made a few cakes, we’ll start to understand where we can find where we can be more efficient in the process or where we can make additions, subtractions or substitutions. If we make modifications to the recipe or the process before we understand what we are doing, we run the risk of making something that’s not a cake and is potentially pretty nasty tasting. For example, I like mustard. If, however, I substitute mustard for the eggs in my cake recipe, I have no idea how it’ll turn out. Regardless, it won’t be a cake and I can’t count on it having any cake-related properties.
It’s the same with Scrum; if we prematurely modify the Scrum framework we may end up doing something that is not Scrum and may not even be Agile. It might work for us, but since it’s not Scrum (or any other established process/framework really) we can’t make any projections about any future behaviors or advantages that we want to achieve. In fact, we may inadvertently change the framework to something less appropriate for us simply because we didn’t understand how to use Scrum in a way that’s appropriate for our team or organization.
Certainly, the same can be said for processes or frameworks outside of Scrum as well. I focused on Scrum in this post because, since it’s intended to be evolved as appropriate, it’s ripe for abuse. My thought is that we generally can’t decide what’s appropriate about something until we know how that something really works.