Bastardizing Scrum is just another example of the trend away from the essence, roots, and intent of Agile. The latest Scrum Guide update does not contain many revisions, but the latest makeover serves as a reminder that there is a widely accessible “Guide” that clearly outlines Scrum and its intent. Throughout this post, there will be a series of references to content in the Scrum Guide.
The purpose of the Scrum Guide is clearly defined on page 3. To quote Ken and Jeff:
“Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.”
Think of the Scrum Guide like a recipe for a popular dinner dish. At first, you follow it precisely because that set of ingredients has repeatedly led to a good product. Going forward, each time you prepare the dish, you may slightly deviate from the original recipe given feedback and other unique needs. Does that mean you can replace a key ingredient and expect the same results? Of course not!
However, this is exactly what is occurring with Scrum in a number of organizations across the globe. They are replacing ingredients and rules that made Scrum the most widely adopted Agile methodology with the expectation that it will yield the same results.
Why would organizations deviate so drastically from the ingredients and rules of a resilient proven methodology? In my opinion, it is a combination of the desire to claim the adoption of Agile, reluctance to introducing sweeping change, and just pure convenience. Executives think they are beating the system by implementing a half-ass solution. The truth is it most likely leads to more dysfunction.
Perhaps the most irritating thing about this approach is when it inevitably fails, who is blamed? That’s right, Scrum!
Essentially, this is the equivalent of calling a recipe bad if you changed everything that makes it great! I spent the last four years of my life coaching Scrum. It essentially works every time it is done right and fails every time it is done wrong. But yet, organizations continue to do it wrong, even with a fair warning. I guess I get to say a condescending “I told you so,” but that’s not what I am looking to achieve.
They even go to the extreme of scaling half-ass Scrum which is a whole other problem in itself. A friendly reminder to executives is that Scrum is simple to learn, but difficult to master (page 3) so fair warning………. don’t scale to it is mastered.
For me it is simple, if an organization wants to realize the benefits of Scrum the following prerequisites must be met:
1. The team is cross functional.
Cross Functional goes beyond sitting QA and Developers at the same table. Instead the Scrum Guide defines them as “teams that have all competencies needed to accomplish the work without depending on others not part of the team (page 4)”
2. It is acknowledged that the Product Owner is a full time role and must be filled with a person that can make decisions.
The Scrum guide states “The Product Owner is the sole person who manages the backlog (page 5).” Therefore, it is not possible to fulfill this role with someone who is not empowered to make decisions.
3. Teams are assembled around Products and not Projects. The word “product” exists 144 times in the Scrum Guide. The word “project” exists 7 times. Enough said.
4. The rule that teams must be able to create a “potentially shippable product (page 7)”, must be adhered to. This organically leads to:
a. A focus on quality
b. Small thinly sliced stories
c. Swarming on stories to emphasize throughput
d. Servant leadership
I was fortunate to be part of a high performing scrum team earlier in my career. The experience has shaped my career, leadership approach, and view of software development.
Therefore, the Scrum Guide will continue to serve as the basis of my scrum coaching with the hope that a few teams get to experience the same excitement and satisfaction as I did many moons ago. Although at this point I am not sure if that is the best thing for my career:)
But I will stand by my belief that in the end, the companies that cater their organizational structure to achieve agility will be the ones that survive. Only time will tell.
I'm busy working on my blog posts. Watch this space!