Video segments
0:00 Use Scrum only when…
0:19 Al Shalloway who asked "Where do you think is a good place to use Scrum?"
0:44 Use Scrum only when transformative disruption is required or use parts of Scrum if those parts prove to be better than the previous ways of working
1:26 Scrum is just a set of working agreements
2:39 True Scrum is a hardcore game, there's no easy mode
3:18 If a company is in crisis…
4:35 Scrum requires…
4:57 Why would a company embrace that level of disruption
5:37 Analogy: Hell's Kitchen with Gordon Ramsay
6:04 Notice the intensity and the rapid learning that occurs
6:55 Let's alter the question: When would I recommend that you STUDY Scrum?
7:27 Empiricism asserts that we can make decisions based on what is known
8:25 I encourage everyone to study Scrum
9:02 Two examples
11:15 It's not inappropriate that an executive express support for a pattern library across the organization
Full text of video
I posted at LinkedIn a while ago and said: “Do you have questions about #Scrum? Ask away. I'll try to respond to each Question in a new thread.”
One of the responses came from Al Shalloway, who asked, "Where do you think is a good place to use it?"
In Summary
Use Scrum for complex work such as product development, professional services, org development, and knowledge work — and only by agreement. I don’t recommend forcing Scrum upon a team or teams.
Use Scrum only when transformative disruption is required. Or use ‘parts’ of Scrum if those parts prove to be better than previous ways-of-working.
I’ll Explain
Knowing that I’m a Professional Scrum Trainer with Scrum.org, you might expect me to advocate for Scrum in all situations. I don’t. I teach Scrum because I appreciate its efficacy, and I respect the curiosity people have about it. People come to me to learn about the Scrum framework – what is it and (most importantly) why is it designed the way it is.
First: Let’s imagine Scrum is just a set of working agreements that a group of people may adopt. These working agreements describe a cycle of planning, delivery, inspection and adaptation; they describe 3 common roles that must be fulfilled in the workplace: someone to sequence the work according to business needs; others to design and deliver the solution; and someone to dissolve obstacles and clear the path for the team; they describe ways to make visible the work of the future, the present, and that past — so the team and those who have a stake in their results can know what’s going on and what’s been done.
But here’s the really hard part: Scrum requires the teams be self-managing, cross-functional, and allowed to deliver small batches of high-quality product frequently into the marketplace.
And in practice, those three aspects of Scrum are too disruptive for most companies.
True Scrum is a hardcore game—there’s no easy mode.
To get the most from the framework, a team must approach it with rigour and discipline.
So… back to the question: When would I recommend Scrum?
My first answer is:
If in the DNA of your company, you have self-managing cross-functional teams that deliver frequently — then you may already have achieved Scrum. If the way you work resembles what is written in the Scrum Guide, then – congrats! – you might call it Scrum.
My second answer is:
If a company is in crisis and massive disruption is needed to avoid existential collapse, Scrum may help.
Let’s think on this: for conventional enterprises, Scrum introduces friction against their existing structures:
- Cross-functional teams – Most enterprises operate with shared service departments and organize their staff into same-skill groups.
- Frictionless feedback loops – The bureaucracy of most enterprises slows down communication between teams and stakeholders.
- Self-managing teams – Most enterprises value the division of labour and strict assignments of roles and responsibilities. But Scrum requires the integration of complementary skills, developers volunteer for the work — nobody assigns tasks.
- Frequent delivery – Most enterprises are not configured to interact with end users in short cycles and are not technically capable of frequent delivery. But Scrum requires that the team is capable of taking new functionality into the hands of end users on a frequent cadence — in cycles not longer than one month, often much shorter. And I don’t mean that they just release frequently but they can convert ideas into new functionality, from concept to marketplace, in under a month.
Scrum fundamentally challenges enterprise norms. Why would a company embrace that level of disruption?
The only valid reason is something like imminent bankruptcy. If an enterprise is facing existential crisis, adopting Scrum in its purest form could serve as a radical transformation tool. However, this means shedding everything that led to the company’s decline and replacing it with only the most essential Scrum practices. I’m talking about a full reset—a drastic move for dire circumstances.
An Analogy: Hell’s Kitchen
To help you imagine what I’m talking about, think about Gordon Ramsay’s *Hell’s Kitchen*. I’m going to assume you’ve watched a few episodes. Think about it: the pressure is relentless. Feedback is immediate. Failure demands rapid adaptation. The contestants on the show learn to coordinate and deliver under extreme conditions. And while Gordon Ramsey swears and yells a lot – which is entertaining for a TV audience – I would hope the members of a Scrum Team are more respectful. But let’s notice the intensity and the rapid learning that occurs. Each meal served is like a Product Backlog Item; each dinner service and each episode is like a Sprint. The fast feedback leads to rapid team building and skill development, every failure requires a change in behaviour — but it’s not for everyone. Most enterprises aren’t prepared for that level of disruption—nor do they NEED it.
So… back to the question: When would I recommend you try pure Scrum?
Only when a company’s DNA is already wired for cross-functional teams, frequent delivery, et cetera – or when a conventional bureaucratic company is on the verge of existential crisis and deep disruption is required. Like: “Hey everyone, we’re 8 months from filing for bankruptcy – we have a hail-Mary idea … who’s in?”
But let’s alter the question: When would I recommend that you study Scrum?
My answer is: Always and for everyone.
The design of Scrum is based on Empirical Process Control Theory. In brief, Scrum helps people understand how empiricism can be practiced in the workplace. And the ‘parts’ of Scrum can be implemented incrementally and may produce incremental improvement.
A brief word about empiricism. Empiricism asserts that we can make decisions based on what is known. So, rather than conjecture, wishful thinking, hope, faith, opinion — we can navigate complex problems by making information as transparent as possible so people can inspect their circumstance accurately so they can adapt accordingly.
I mean — what’s the alternative?! We can guess what the future holds, imagine the future state of a product, make a plan to there from here, then never change the plan!? That’s absurd – we know that we’ll to course correct along the way as new information and crucial variables are discovered.
Scrum is a model designed for that context. I encourage everyone to study Scrum so you can steal the best parts of the model that will have positive impact in your workplace.
Maybe the Daily Scrum is a great way for your team to plan for collaboration each day. Maybe the Definition of Done is a concept that helps your teams make quality more transparent. Maybe Sprint Reviews are a great way to ensure your key stakeholders are aware of what’s going to market.
Now – if you implement only parts of Scrum – the result is not Scrum. But so what - the results might be positive.
Here are two examples:
Consider a growing startup facing chaos
Imagine a startup that has grown from a handful of employees to a team of 40. Transparency is breaking down, and processes are becoming inconsistent. When the company was 12 people, everyone knew what was going on – but communication and transparency require more effort now. Some team members want more structure, but the founders want to prevent EOB (Early Onset Bureaucracy). Scrum’s lightweight structure—regular planning, delivery cycles, and review—can help maintain agility without overcomplicating processes. In this case, parts of Scrum can serve as a stabilizing force, offering just enough structure to manage growth while enabling a high level of autonomy for each team and individual.
Or consider the challenge of managing a multi-national enterprise
Imagine the company has teams across different time zones. Employees transferring between offices need to quickly integrate into new teams. If different regions work under completely different models, collaboration becomes difficult. Imagine a person working in the Calgary office must travel and spend a few months in the Tokyo office; or a team in Dallas should collaborate with a team in Panama — wouldn’t it be nice if they can be immediately productive together knowing they share some working agreements such as a cadence for planning, delivery, and frequent demos; or they have similar team structures that include a product manager, developers, and a Scrum Master. Here, a company might *support* Scrum as a default working model — not mandate it, but encourage teams to adopt shared practices. Teams remain free to adapt as needed, but a common baseline exists.
Now, I'm not one to want sweeping regulations and blanket policy. I abhor those things. But it's not inappropriate — and it’s still quite Libertarian — that a Chief Executive Officer may express support for (not enforce) but express support for a pattern library across the organization.
The Bottom Line
Would I recommend Scrum? Sometimes, yes. But more importantly, I recommend studying it, understanding its principles, and deciding whether full Scrum or parts of if would be helpful.
- Parts of Scrum can help mitigate chaos.
- Full Scrum can drive radical transformation in crisis.
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.