The Widespread Misconception of Scrum Application

While browsing the internet, I came across a captivating thread on Twitter, which prompted me to draft this article. The thread was titled, “Scrum is a cancer.”

This article is about the very popular misconceptions in people’s understanding of a tool called “Scrum”. Before delving in, it’s essential to clarify:

• This article isn’t meant to defend Scrum.
• It seeks to address how people’s misunderstandings of the tool can lead to adverse outcomes, with subsequent blame placed on the tool itself.
• Every tool, whether Scrum, Kanban, or others, is tailored to solve specific problems. To apply a tool effectively, one must first understand the problem. Otherwise, you might implement the tool, but the problem persists.

Throughout, I’ll reference quotes, notes, and answers from the aforementioned thread to underscore certain misconceptions. All written here is with FULL RESPECT to the author of the thread.

Misconception of the Problem that we are going to fix

Many who criticize processes, such as Scrum, often struggle to articulate the exact problem they aimed to address with this process. From my observation, this confusion typically arises because individuals hastily adopt widely recognized frameworks, believing or being informed that they’ll yield superior outcomes. Scrum often falters under scenarios like:

1. If you have a team without a single goal. As soon as your teammates have their own tasks, there is no need to collaborate between them — Scrum is not for you. Scrum requires a single goal, the single focus for whole team members, otherwise ALL your events in Scrum become useless. What’s the reason to have a Daily Scrum when everyone has their own work, that is not interesting to anyone else?
2. If you optimize the workload of people, try to keep everyone busy with work. In this case, the single goal purpose will fail. Scrum is the tool to collaboratively, iteratively, and incrementally deliver software for the purpose of continuously inspecting and adapting. As soon as everyone is busy you fall to point 1, have task execution instead of collaborative work. So you need to understand if the problem that you are fixing in the org really requires collaboration or not. This point is also related to the outsourcing model when customers pay for time (do not use Scrum in pure outsourcing with workload optimization goal)
3. If you are trying to apply Scrum for a clear/complicated problem domain. This is a tool for complex development, where your team makes very small steps in order to achieve results, using the feedback loops in Scrum to understand the path. If you are trying to push Scrum to fix simple problems you will face an overcomplication of your process with no results and tons of waste. If you are a team of designers you don't need Scrum, you may need just something that helps you visualize the whole work, which can be just a simple board with tasks.
4. If you are applying Scrum in components teams (like Integration bus team, Core team, iOS Team, Web Team, Front-end Team, etc.). If your team cannot deliver end-to-end features from backlog without another team(s) then Scrum is not for you. Your organisational structure in this case does not support this method of work. Having componenetial teams on one customer value stream ALWAYS leads to Waterfall.
5. If you are not fighting the problem of high adaptability, which means “be able to change the priority quickly in order to respond to change (on the market, with technology, with unknown, etc.), change organizational direction towards customer’s needs. Good article about this is here https://medium.com/serious-scrum/optimizing-goals-of-scrum-3efe16dbd7b2

This statement is wrong from my point of view. Scrum doesn’t work if you are applying it without an understanding of the problem you are trying to solve and given context. Do not use Scrum in any given circumstances mentioned above. Also remember:

If all you have is a hammer, everything looks like a nail.

Misconception of Scrum (and it’s understanding)

Based on the Twitter thread, I’ve identified several misunderstandings:

Estimations and forecasting

Accurate estimation is challenging in a Complex Problem Domain. Standish Group Chaos Report illustrates this. Scrum emphasizes step-by-step progress, particularly valuable in unpredictable areas. The problem is that wherever actions we take a high level of unknown will lead to a low level of predictability. Scrum allows you to move step-by-step and eliminate the unknown by incremental and continuous delivery (and not only Scrum btw). At some point in time, the effort you are investing into lowering down on the unknown at the beginning of development will not result in any success. There is a good visualization called Cone of Uncertainty:

To fight with uncertainty there are at least 2 ways:

1. Try to eliminate it at the beginning, invest in research, documentation, specifications, etc. But in the Complex domain, everything changes faster than you investigate it
2. Try to start and learn from what’s done. This works in a Complex domain and is supported by ALL Agile frameworks and methods of work as a primary way of development.

All tools in Agile support forecasting on some level with some level of prediction, but mostly all of them are based on your previous development experience in this area with a stable team and process.

Let’s start with the following: Planning Poker (PP) is not a part of Scrum. You never find this word combination in the Scrum Guide. PP is what we call GASP — Generally Accepted Scrum Pratices. Meaning this is a practice you may or may not apply. Other practices might be estimations in hours, or a no-estimates approach. You need to understand why you make estimations, and it might be not an obvious reason like:

• understand the hidden complexity in the backlog item, that looks easy
• Develop the pipeline of development
• decompose items if they are too large in hide some complexity

Any kind of long-term prediction in a Complex Domain will fail, and the earlier you make them the bigger the deviation will be.

Same with Story Points — they are not a part of Scrum, this is a tool you may use or may not use considering your goals and needs.

This is simple as is: if you don’t see value in something then do not try to apply it without a need. There is no word of “had” or “must”. In complex domain there are no ready-to-go solutions or approaches — you have to build the things that works for you. That’s why Scrum does not have Story Points, T-shorts, or User Stories (yes yes) as all of this stuff is very contextual.

So how to build the confidence of delivery pipeline? Try the following (but not limited to):

1. Regular demo (every Sprint if you use Scrum) with a wide audience of stakeholders. If you are in outsourcing your customers must be there (as well as on Refinements, Sprint Planning, they have to control backlog and priorities).
2. Show and update backlog during the demo — expect and adapt what you made with the next plans
3. Build the roadmaps based on Sprint Goals — Fill goals for 2–3 upcoming Sprints with your team to understand what you think you can achieve and when
4. Collaborate with stakeholders and ensure 100% transparency and control over the priorities

If you are using Story Points (SP) the most stupid thing you can do is to measure team effectiveness in it and/or compare SP between teams. SP will also have variations between projects your team is working on (even inside one team).

But this is a very common situation in outsourcing when management solves Scrum for clients as a cool new way of working. And sell Story Points. Don't do this, this is a dead-end that kills the whole idea of Agility.

It’s also impossible “to fix” variations of SP size between teams :) due to the nature of SP estimations. I saw many attempts to make it, creating the big boards with all tasks, and moving them between sizes and teams — all failed.

Events and time spent

The most common problems seen during events are the following:

1. Low level of facilitation skills of meeting leader + low engagement of participants
2. Low level of understanding of the purpose of the event, its artifacts, and outcomes
3. Absence of a collaborative goal and as a result collaboration of people during events around the goal.

Every event seeks to enhance transparency and team alignment. Therefore, event success rests on team dynamics, effective facilitation, and a mutual objective.

Conclusions

Neither Scrum, Kanban, nor even the Waterfall model is inherently problematic or is cancer. The challenge lies in selecting the right tool for the job and grasping the problem.

Think about the problem first, think more, then a bit more, and only after thinking about possible solutions, including but not limited to frameworks.

I truly support this statement of the author — everything they did is not Agile, it's things they made for managers without understanding “why”.