Debunking Scrum Misconceptions

Scrum is the most used agile framework in the industry. Some swear by it, some swear at it, and some love it. There are many misconceptions about Scrum. In this post, I’ll seek to respond to the most common that I’ve come across.

Kanban is better than Scrum

The problem with this statement is it assumes both methodologies are mutually exclusive, however, they’re not. Scrum compliments Kanban by using Sprints to indirectly limit work in progress (WIP) and by forcing a done state on work items. While Kanban directly enforces a WIP limit for each step in a flow, thus increasing throughput and the chance of delivering on a Sprint forecast. Scrum isn’t better than Kanban nor is Kanban better than Scrum. Both methodologies can work better than the other depending on the situation. They also work together very effectively.

You can’t regularly release if you’re doing Scrum

Scrum says, by the end of any Sprint the aim should be a potentially shippable increment of the product. This does not stop the team from creating smaller increments mid-sprint and shipping them in collaboration with the Product Owner. Scrum places an upper limit on an increment of the shippable product, it doesn’t place a lower limit.

It also doesn’t mean that you can’t release dark, have feature flags, or hand over release pipelines to stakeholders.

You can’t do lean with Scrum

Proponents of this argument claim that the Sprint forecast is just an avenue to deliver a shopping list of items that a Project Manager wants completed within a Sprint. They compare this to a waterfall project where requirements are compiled prior to implementation. I accept that this is how some teams may do Scrum. However, this isn’t Scrum implemented correctly, it’s probably not even Scrum at all.

A Sprint forecast should have a goal and this goal can be used to align to a wider One Metric That Matters (OMTM). Scrum does not stop this lean thinking, in fact the Sprint and its goal can create an environment where lean thinking is made a priority. Using a Sprint goal helps teams focus on why certain items are being delivered. The Sprint itself then becomes an avenue to inspect and adapt to find a product/market fit that can be exploited. The Sprint should not be used to deliver a shopping list of items but to verify and learn whether the current direction shifts the One Metric That Matters (OMTM).

You can’t do systems thinking with Scrum

Failing to view an organisation from the prism of systems thinking isn’t the fault of Scrum, nor is implementing Scrum as a local optimisation the fault of Scrum. Any framework or methodology can be implemented as a local optimisation or isolated away from the rest of the organisation: Scrum, Kanban, or CMMI.

Scrum implemented well enables systems thinking by expanding Scrum and agile values of transparency and learning into the wider organisation. Good Scrum Masters are able to facilitate systems thinking across an organisation by realising help isn’t limited to the direct Scrum Team but throughout an organisation. There’s no point of being agile at a development team level, when the bottleneck exists in the wider organisation.

Some of the best Scrum Masters I have worked with were able to coach their teams to the extent that they had more time available to coach the wider organisation. Scrum Masters (and team members) that do what Stephen Covey calls influencing the first circle then expanding on that are definitely doing systems thinking.

In some medium sized organisations I’ve worked with, every one up until the CEO knew which Sprint the development team was up to. Scrum enables systems thinking by helping to identify frictions within a delivery team as well as outside it. It starts with the first circle of influence then expands out.

Scaling Scrum is difficult

Refuting this statement is difficult because scaling anything is difficult! Scrum or otherwise. What Scrum or more specifically LeSS (Large Scale Scrum) accepts is that scale looks different for each organisation. Scrum and LeSS are both incomplete and should be a starting point for scale. Not the end goal.

What’s more important about scale is not end state but the continuous learning environment needed to slowely scale. Doing any method of delivery: Scrum, Nexus, LeSS, SAFe, or the Spotify Model is counterintuitive without the underlying reasoning. That is, being agile by delivering early and often to production to adjust quickly to the people who use the product.

I’ve spoken about this concept of improvement in my previous post: transformation, reorganisation, and continuous improvement

Finally, I would like to encourage you to examine claims about Scrum carefully. There are many misconceptions about Scrum and agile that are false and sensationalist. The best way to fully examine these claims is to understand Scrum itself. A good place to start, is to read the Scrum guide yourself and compare any claims made with this actual guide