“Why does Scrum require that you only have one person ‘own’ a product?”
“Why do we have to be done with something in a month or less? That would make our testing process really inefficient.”
“Why is everyone on a development team called a ‘developer’? Why is it called a development team anyways? My teams don’t build software.”
“Why should I use Scrum? When shouldn’t I use Scrum?”
These are just a few of the common questions I hear from attendees during my Professional Scrum classes, and I often hear these questions from individuals who have been using Scrum for several years. In our new ‘Scrum Whys’ blog series, we will explore the whys behind Scrum so you are better equipped to understand when, where, how, and why to apply Scrum.
Earlier this week I wrote about how many Agile coaches are getting one very important thing wrong – they are applying cookie-cutter practices from ‘the agile methodology’ and expecting teams to be more productive, happy, and successful than ever. The problem is that those cookie-cutter practices almost never deliver even 25% of the promised benefits because those ‘cookie-cutters’ were created within a specific organization at a specific time to solve a specific problem with a certain type of individuals, and people very often use the cookie-cutters without taking into account the differences in their context.
Scrum is sometimes criticized for being a cookie-cutter and for being too prescriptive, and those criticisms often come from people who have been unfortunate enough to work in organizations that practice cookie-cutter Scrum. This is when teams are told exactly how they should use Scrum, down to very specific practices. When teams try to deviate from those practices, they get ‘slapped on the wrist’ and quickly learn to stay between the lines. Cookie-cutter Scrum discourages creativity and innovation because people aren’t allowed to ask why or try a different approach.
One of the ‘aha’ moments attendees often experience in my Professional Scrum Master classes is when they realize Scrum is not a collection of cookie-cutter practices but just a framework that can be adapted to varying contexts, circumstances, and cultures. Once they understand the ‘whys’ behind each piece of Scrum, they feel better equipped to make it work in their team or organization rather than following the recipe book from their Agile coach (or what they read on the Internet).
Our goal of this Scrum Whys blog series is to explain the whys behind Scrum so that you can get real results by making more educated and strategic decisions about applying Scrum in your context. Check back soon or subscribe to our newsletter to receive our newest blogs in your inbox.
