Scrum Alternatives: SCREAM!
Scrum Alternatives: SCREAM!
Is SCREAM! An Excuse For Expensive Waterfall?
No, we’re not talking about the parody of Scrum called Scream, which Michael Kusters published in 2019. We’re talking about SCREAM! - an integrated approach for multidisciplinary design teams in higher education, which is even older and presented at a conference in 2015.
In the upcoming months, I’ve decided to explore novel Agile ways of working to see what we can learn from them. A few days back, I stumbled upon SCREAM!, which is an integrated approach for multidisciplinary design teams in higher education.
I thought it would be interesting to see what it’s all about. Let’s dig in!
Keep in mind the original SCREAM! conference paper focuses on higher education and design teams, so we cannot conclude that it necessarily applies to other contexts, such as software development, based on this paper.
Why SCREAM!?
“One thing that SCRUM is not very suitable for is fostering creativity, which is one of the 21st century skills and part of the T-shaped professional’s skill set. SCRUM can be quite rigid at times and the ‘getting things done’ mentality may conflict with ideation, reframing insights/research questions and creative problem solving.”
Let’s gloss over the fact it’s called Scrum and not SCRUM. I do believe this criticism is pretty spot on. In reality, Scrum is often practiced in a rigid way, and the Sprint is mainly (ab)used as a vehicle for producing a potentially releasable product increment during the Sprint.
The primary focus of Scrum becomes delivery, which sucks the soul out of discovery and validation. We are so focused on delivering working software that we forget to wonder enough about: how confident are we that we are building the right thing?
One might argue that this is not how Scrum is intended to be, but yes, the reality is that this does often happen. Even outside the higher education context. Scrum often devolves into a feature factory where the focus becomes to ship and forget.
How Does SCREAM! Improve Creativity and Openness For Figuring Out the Right Solutions?
Scrum is a purposefully incomplete framework you should supplement with complementary practices for it to work. Out of the box, it doesn’t provide a complete process for you to deliver valuable products.
SCREAM! adds and supplements the following events:
Ideation and Planning before Sprint Planning.
Design Methods Toolkit is used during Sprint Planning
Focus on Research & Create During the Sprint with Translation sessions
The SCREAM! Approach
In SCREAM! Every sprint begins with an ideation and planning session. A brainstorming and ideation session is facilitated using the Design Method Toolkit. All ideas are listed, the bad ones are weeded out, and only the most promising ones are picked up during the Sprint.
During the Sprint, research, and design are performed using the Design Method Toolkit. This triggers and inspires the team to apply a larger variety of approaches.
The design and research results are presented during translation sessions, and the team is asked to write down the user stories, methods, and results. This way, the relevance and impact on the final solution can be discussed and evaluated.
In short, SCREAM! ensures we focus on doing a lot more discovery, ideation and brainstorming, and that we trigger the team to use a larger variety of design approaches.
SCREAM! - An Excuse to Do Expensive Waterfall?
In this paper, published in 2024, after 20 weeks of Sprints using the SCREAM! approach, the only thing developed was an eHealth prototype. No working software was produced.
This is extremely ironic because the original paper starts by criticizing Scrum for focusing too much on delivery. My criticism of SCREAM! would be that it focuses too little on delivery.
You might think this criticism is unfair because the original conference paper states that SCREAM! is meant for multidisciplinary design teams. The focus of SCREAM! is on design, not building working software. It’s on purpose!
But let’s consider the following: The average Sprint (2 weeks) costs between € 27.000 and € 84.000 Euros in the Netherlands. This means that after spending between € 270K and € 840K and losing 20 weeks, you only have a prototype, which you still need to build. Would you consider that a wise investment of your money?
Let’s say my numbers are off because the team contains cheaper design professionals rather than expensive software engineers. Even if the team costs 10K per week, you’re still talking about an investment of 100K and losing 20 weeks. Why not run a Design Sprint for 5 days, which could produce the same result of having a prototype in a much shorter period of 5 days?
The result might be worse after 5 days, but if it takes 20 weeks, it’s definitely too slow and expensive for today’s fast-paced world. Dropbox created a movie to show a prototype of its product, which resulted in massive and valuable feedback. I can guarantee you it didn’t take 20 weeks and a gazillion of Scrum meetings to produce.
I do think the idea behind SCREAM! is good. We should do more discovery, ideation, and validation, but if, in practice, this leads to teams spending excessive amounts of money to produce nothing but a prototype, then it’s definitely not worth it. You don’t need the unnecessary overhead of Scrum to run all these ideation and discovery sessions.
Instead of doing SCREAM! Sprints, you could simply do light-weight sessions using a Product Trio, even by using the approaches that are provided in the Design Method Toolkit to promote applying a variety of different approaches. Much simpler and quicker, with the same kind of results.
It’s true that we shouldn’t focus on just delivery during the Sprint, but if we’re just focusing on discovery, research, and ideation and not putting anything in our customers’ hands they can really use for a period of 20 weeks, then we might be ensuring that we’re going in the right direction, but we’re doing it at a glacial pace that’s extremely expensive.
Another interesting observation after reading the original conference paper is that even scientists struggle with describing Scrum. The paper is filled with pretty obvious Scrum mistakes, such as:
SCRUM instead of Scrum
Rituals instead of Events
Daily Stand-up Meetings instead of Daily Scrum
Committing to User Stories during the Sprint - the team only commits to the Sprint Goal
Fixing tasks during the Sprint without having to add new tasks - the whole point of the Sprint is that it’s supposed to be a vehicle to support being flexible and adaptable to meet a specific Sprint Goal
There is no such thing as a SCRUM board
The PO doesn’t decide when tasks are moved from Pending to Done
The Product Backlog doesn’t have to be ordered by Business Value
Requirements don’t have to be broken down in User Stories
User Stories are not feature descriptions. Otherwise, they would be called Feature Stories
Many of these same mistakes are propagated to the 2024 publication, which still lists the three questions as part of the Daily Stand-up (which was removed in 2020 already, and I don’t even know for how long it’s called the Daily Scrum).
In short, SCREAM! contains some interesting ideas, but unfortunately, the lack of understanding of Scrum means it tries to solve problems that Scrum doesn’t have while creating novel problems and slowing things down in the process by trying to shoehorn Ideation and Design in a Scrum-like approach.
So, in short, what did we learn from all of this?
Yes, we definitely should be doing more ideation and discovery when we’re doing Scrum and not only obsessively focusing on shipping features that may not make the lives of our customers or users better.
You don’t need Scrum together with all its overhead if the only thing you want to do is Design and Ideation.
Scrum is hard to understand, even for scientists.
You don’t have to shoehorn Ideation and Design in Sprints, even when you do Scrum.
I want to stress that I’m not an expert on SCREAM! I’m happy to make adjustments if I misinterpreted anything or if there is anything I wrote that’s factually incorrect.
Did they actually name it SCREAM? 😅 I thought you were just being humorous. I'm not familiar with this relatively new approach, so thank you for your detailed research and work. I've learned something new from you, as always 🙌
I haven’t read the original paper, but the 'obvious Scrum mistakes’ you mention trigger me. Every time someone starts complaining about Scrum, I notice they have all these assumptions which are not grounded in the Scrum guide. When I point this out, the usual response is: well, that’s the theory, but I’m talking about the practice. When I ask if they have a scrum master or at least someone who coaches the team in scrum practices, the response is something like: there’s no budget for a scrum master, or scrum training. I wish my socratic conversation skills were better so I could get them to see their self defeating logic.