Scrum Illusions: Are You Really Using It Right?

For someone who’s been in the software development space for over two decades, Agile and Scrum are common terms, often used interchangeably, even though Agile is a broader philosophy under which Scrum falls as a specific framework, initially aimed at software development.

At some point, everyone has unknowingly used agile principles in their development process and work conduct, whether it was a specific agile approach or elements borrowed from agile frameworks. Regardless, it seems we tend to use the word “Scrum” to describe what we are doing whenever we are enabling some kind of agility within our teams.?

This article is a reflection of my past experience working with Scrum Teams, in particular as a Scrum Master, and the realization that we, most of the time, were enabling agility, but not by applying the Scrum framework as it is designed.

Scrum? Did you mean Agile instead?

Agile broadly means that the organization, process and teams are organized and perform in a certain way that they are able to quickly pivot in response to change, whether these are changes in the market, corporate strategy, etc. When a company states they are agile, it usually means that they use elements from one or more of the existing agile approaches (or devised their own) in order to implement an iterative, incremental process that is able to deliver value at a cadence. Scrum is probably one of the most known agile frameworks, founded on empiricism and lean thinking - I dare to say the most popular, at least in software development (where it is rooted), so popular that companies usually refer to roles such as “Scrum Master” even though they don't really use the Scrum framework as designed. As the Scrum guide states:

"Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."

In a nutshell, if you are not using Scrum’s elements and rules as per the Scrum framework, then you are not using Scrum. You are probably still enabling agility, but it is not Scrum, it is something else. Which may be fine and work wonders for you and your customers, and if that’s the case, go for it and don’t regret it.

Identifying common deviations

Throughout my career, I believed that we were utilizing Scrum properly and effectively in many of the projects. However, after earning my PSM I and PSPO I certifications from Scrum.org, I came to a startling realization: this wasn't the case. What's more, I discovered that many companies I had worked with were also under the misconception that they were correctly implementing the Scrum framework. Merely appointing a Scrum Master, conducting daily stand-ups (Daily Scrums), and setting time boxed Sprints are insufficient practices to genuinely claim adherence to Scrum.

Preparing for the certification exams involved a thorough study of the Scrum Guide. This deep dive enabled me to recognize the contrast between Scrum's ideal, theoretical use and its actual implementation in many organizations. The signs listed below may indicate that you are implementing a framework other than Scrum, a realization I missed during my past experiences as a “Scrum Master”. Please note, these are presented in no particular order:

1. The Scrum Master is leading Daily Scrums

The Daily Scrum isn’t for managers, doesn’t require a moderator and it certainly isn’t to provide status. Oftentimes we would see ourselves dragged into the weeds, with Scrum Masters leading conversations on a Daily Scrum that quickly derailed into specifics or a mere status reporting call. The Daily Scrum is an opportunity to inspect and adapt, where Developers reflect on what was done and adjust the upcoming planned work towards the Sprint Goal, while bringing up any potential issues. The Daily Scrum is for Developers, the Scrum Master? isn’t needed, they just need to make sure that the Developers have the meeting. Scrum Masters and Product Owners participate in the Daily Scrum as Developers if they are working on specific items of the Sprint Backlog. Otherwise, they may still attend, to listen, and should not interfere. And don’t get me started on Scrum Masters calling out the next team member to speak up… What are we, kids at school?

2. The Scrum Team is unable to complete tasks due to lack of skills

Scrum Teams are cross-functional, meaning that they should have all the necessary skills to deliver a done product increment in a Sprint from start to end. This involves everything from research, design, development, testing and whatever other activities needed to deliver a usable, done increment. Well guess what? I’ve never been part of a Scrum Team with all the necessary capabilities from start to end: Designers? Never had one in a Scrum Team; The Scrum Team often lacked skills around DevOps oftentimes needed to handle deployments. These are only two examples where we needed to grab an external member to the Scrum Team to fulfill those tasks. Most times we were isolating the application of Scrum to development only, with other tasks being fulfilled outside of this process.

3. The Developers constantly need direction

I personally take blame for this one - being a Project Manager with a strong technical background from years of development, it’s easy to lose focus and start “directing” people on what to do. And this has a snowball effect, as Developers will start expecting you to tell them what to do next, over and over.? A Scrum Master is not a Project Manager - while they may have project management experience, their role in Scrum is distinctly different, focusing on facilitating and coaching rather than directing tasks. Scrum Teams are self-managed, and it is up to them, as a whole, to decide the course of action through collaboration, and specifically it is up to the Developers to decide what to incorporate in the Sprint and to manage the work in the Sprint Backlog.

4. Hijacking Sprints

“Sprints are the heartbeat of Scrum, where ideas are turned into value.”

Just as a heart’s continuous beating is vital for life, uninterrupted Sprints are crucial for maintaining the momentum in Scrum, and that’s why the framework mandates that the next Sprint starts immediately after the previous one finishes. There are no “rest” days in between, or “Sprint 0” for planning, as I’ve seen almost “standardized” across organizations. Also, every Sprint needs to deliver a done, usable product increment - this means that dedicated “hardening” sprints to remove technical debt are also a red flag. Yet, they are a common occurrence, and it’s not hard to find “Scrum Masters” across the spectrum willing to uphold these.

5. There are multiple product owners (or no Product Owner at all!)

For one product there should only be a single product backlog, owned by a single Product Owner (one person, not a committee!). Even when we are implementing Scrum at scale (with multiple Scrum Teams), Scrum states there should only be one Product Owner, who manages one product backlog, working on one product. The main reason for this is that there’s a single person accountable for maximizing the value of the product, and everyone across the existing Scrum Teams knows who that is. Oddly enough, one of the issues I came across very recently was not that there existed multiple product owners, but the fact that there wasn’t an appointed Product Owner! The Scrum Team is the fundamental unit of Scrum, and so all accountabilities need to be properly identified to start with! The fact that there’s no Product Owner explicitly identified means that there’s no one accountable to maximize the value of the product or to manage the product backlog, and the team faces the issue of sailing with no direction at the whims of anyone!

I could bring up other issues, like lack of a Definition of Done, lack of adherence to Scrum values (ask your Scrum Team what does are) or a failure to properly and frequently inspect results (without inspection there’s no adaptation!), but I feel the ones mentioned above are perhaps the most obvious and should be easy to spot early on.?

Ok, so now what?

“Scrum” has been hip for years. So hip that the term nowadays is used irrespective of whether the Scrum framework is actually being implemented or not.?

I am not a Scrum purist or maximalist - I recognize the value of other agile frameworks and of adapting processes and mixing elements from different ones if the results are good (I have used hybrid approaches as a project manager multiple times myself). At the end of the day what matters is that you are helping your team and organization to become more agile in how value is delivered to customers.

But, I believe in the importance of accuracy. If you recognize any of the signs above, it's likely that what you're practicing isn't Scrum. At that point you need to be honest: with yourself, with your teams, and with your organization. You, as a Scrum Master, are responsible and accountable for establishing Scrum in the organization by leading, training and coaching - but that’s only possible if you have a good grasp of the framework and are able to detect these red flags and act on them.

Otherwise, why call someone a “Scrum Master” if one’s not using Scrum? Using the term “Scrum” to describe an agile process creates the expectation that specific events, rules, accountabilities and artifacts are used and followed, which may not be the case.

What has been your experience in implementing the Scrum framework? Were you able to implement it flawlessly as per the Scrum guide? What were the hurdles you found or the mistakes you made? Hit me in the comments.?

P.S.: you can access the Scrum guide here.