There are no true Scrum teams
This article is a discussion about what Scrum is - and what it isn't. When discussing with zealous Scrum evangelists, the most common rhethoric is the "No true Scotsman" fallacy - otherwise known as "shifting goalposts".
This is the classic "No true Scotsman" - as per Wikipedia:
Person A: "No Scotsman puts sugar on his porridge."
Person B: "But my uncle Angus likes sugar with his porridge."
Person A: "Ah yes, but no true Scotsman puts sugar on his porridge."
Before going any further, this isn't a gripe with Scrum itself as much as it is with people who make Scrum more than what it is - a tool for team organization. They idolize it, create a faith around it, then defend Scrum without reason and against all reason.
The following dialog is largely based on snippets of real conversations I had before:
A - "So, this team tried Scrum, but they failed miserably. The CTO was furious and disbanded the team."
B - "I guess he just didn't understand the benefit of Scrum."
A - "The CTO attended a CSM course as well."
B - "I bet they weren't following the Guide."
A - "They had a Scrum Master, a Product Owner, five developers. They had a prioritized PBL, planned and delivered biweekly. They had Dailies every day at 9 and they held Reviews and Retrospectives."
B - "Then what was their problem?"
A - "The team put bug fixes into the Product Backlog just like any other work."
B - "That is how it's supposed to be done."
A - "Production was down the day after Sprint Planning and remained down for 13 days until the Sprint was over."
B - "No True Scrum team would do that."
A - "They followed the Guide. It says that all changes are put into the PBL."
B - "They could have used a Sprint Termination."
A - "The Scrum Guide says that a Sprint Termination is extremely traumatic, so they wanted to avoid that."
B - "For a True Scrum team, Sprint Termination isn't traumatic."
A - "There were other things before that ... for example, people from business weren't invited to Retrospectives."
B - "That is correct based on the Scrum Guide."
A - "And they got irritated, because the developers decided to force changes to the way how business was allowed to interact with them."
B - "No True Scrum team would do that."
A - "Well, for example, the developers felt too disturbed by Business continuously coming to their desk and interrupting their work."
B - "Developers should not be interrupted during the Sprint."
A - "The developers decided that when Business wanted to chat, they should make an appointment."
B - "That is a smart thing to do."
A - "So the COO got shooed off with an appointment 18 days away when the conversion rates tanked."
B - "No True Scrum team would do that."
A - "And there are other things ... the way they interacted with other teams around them."
B - "Interaction is good."
A - "Not in their case. Specifically, they didn't really interact except to blame others."
B - "No True Scrum team would do that."
A - "Well, anyways. They depended on other teams to get their Stories Done."
B - "True Scrum teams are Feature teams."
A - "Well, they somehow were - just that some features shared components where Waterfall teams delivered in 3-month cycles."
B - "Why wouldn't they be able to deliver their features autonomously, then?"
A - "They did, but the Waterfall teams weren't using CI and whenever they checked in, half the tests broke."
B - "No True Scrum team would work like that."
A - "Let's forget about that for now. There's another story, of another team that failed."
B - "I bet they were also somehow not following Scrum."
A - "It was a perfect Scrum setup based on the Guide and managers wanted and supported Scrum everywhere in the organization. Autonomous feature teams, deciding their own workload. Management happy with the results. In this case, the developers felt nauseated."
B - "Why would that be?"
A - "The Scrum Master broke their trust."
B - "No True Scrum Master would do that! What happened?"
A - "A team member complained that the meetings were boring."
B - "No True Scrum meeting is boring!"
A - "Well, anyways. So this developer complained and wanted to change things."
B - "Change is good."
A - "Not in this case. The SM took personal offense, because the developer said that the SM caused the meetings to be boring."
B - "Did the SM ask the dev why they felt like that?"
A - "No. Instead, the SM ran to upper management and claimed that this developer was against Scrum."
B - "So, did the managers talk with the developer?"
A - "They did. In fact, they told him to recant."
B - "No True Scrum management would behave like that!"
A - "Well, and then I met this team that was using Liberal Scrum."
B - "The Scrum Guide says that if you don't follow ALL items in the guide, you're not using Scrum."
A - "Anyway. This team decided they didn't need a Scrum Master."
B - "A recipe for disaster! Every True Scrum team needs to have a Scrum Master! I bet they stopped Sprint Retrospectives as well."
A - "Indeed, they did, because they took an hour each day to reflect on every aspect of the team - learnings, social interaction, the product, the customers and everything else. And they stopped having a Product Owner."
B - "I guess they completely messed up their product."
A - "Not really. The person who used to be PO joined in a developer role, and the other team members were on the same level and could make decisions exactly as if they were PO - the team was of One Mind."
B - "In any case, that's not True Scrum. What else did they change?"
A - "They stopped having Dailies."
B - "No True Scrum team would do that. I bet that's where they completely lost control."
A - "They used Mob Programming and a WIP Limit of 1. Everyone on the team knew exactly what everyone was working on at any point in time. They felt that the Three Questions for the dailies were pointless."
B - "Without Dailies, that's not True Scrum."
A - "I agree. They even came to the point where they abolished Scrum because they felt it was an impediment."
B - "No True Scrum team would do that. They set themselves up for failure!"
A - "I wouldn't call it that. This was the only hyperproductive team I had ever worked with. They delivered more and better value in a week than other teams could in a year."
Confirmation bias
It's not just "Problems aren't True Scrum": at the same time, any case for "True Scrum" presented by Scrum evangelists is dubious. I have looked into some of the case studies presented by Jeff Sutherland himself as showcase examples for successful Scrum.
Case 1: "This 100k employee top-tier organization went full-Scrum."
Me: "I worked with them during that time. They plan one to five years ahead of time, their requirement definition process is 54 steps and costs over $50k for each new requirement and there's an exasperating Release process requiring roughly 100 pages of documentation that has to be manually signed by five org units. They have individual Scrum teams for Development, for Test, for Analysis, for Project Management - and even for Project Tracking. I rest my case."
Case 2: "They had a huge project with an estimated 1m LOC and only 1 month time. Using Scrum, they over-achieved and delivered 1.2m LOC"
Me: "I looked at what they produced. They used code generators and the code was never refactored. It wasn't covered with automated tests. 1.2m LOC of untested, unrefactored code. I rest my case."
Case 3: "Team Wikispeed produced a CAR! And they can make updates to the mode in JUST TWO WEEKS!"
Me: "If their product were at all marketable, they would blow off the competition in no time. 7 years later, in an industry that is in a crisis, they are selling Scrum trainings rather than cars. In a market where many billions could be made with a single model that is better than VW Diesel? I rest my case."
To sum it up
When discussing with Scrum apologists, even someone who follows the Scrum Guide 100% is only accepted into the halls of "True Scrum" if their organization has no problems. Any problem means you're not using "True Scrum":
Things that are specifically mentioned in the Scrum Guide mean that you're not using "True Scrum" if you're using them literally - and if you're interpreting them. Things that are omitted from the Scrum Guide mean that you're not using "True Scrum" if they improve what your team does - and if they create problems. This makes "True Scrum" not only extremely difficult to define.
The most successful teams I encountered were not using Scrum, and the most challenged teams I encountered were using Scrum.
I leave it to you, dear reader, to decide whether they have ever encountered what would hold as a "True Scrum" team in the discussion with a Scrum apologist. I would daresay that such a "True Scrum" team is a rarer sight than an albino armadillo. Why do organizations adopt Scrum if nobody is doing it properly, anyways?
Scrum is a tool. It's useful for getting a team organized. It's not a religion, not a creed, not a faith. Nobody will burn you at the stake for not adhering to their specific interpretation of it.
Stop focusing on Scrum. Just do what works and be happy with that.
SAFe SPC, ITIL4 Managing Professional, PeopleCert Ambassador - DevOps & ITIL4 instructor, course creator/content writer, book reviews
1 年Nihil novi. Propose a dogma, move the burden of proof elsewhere, demand that other parties prove you wrong. I'm tired of this nonsense.
Solutions Architect & Consultant | Finding a way to do more using less within the reason and the budget
7 年If any guide/practice/etc on SW development process takes upper hand over production - such practice is not correct! Any SW process is to serve Production but not vice versa. Disruptions to Productions are to be avoided at any cost. Otherwise it is like the medicine that kills patient - precisely by the book. (When in opposite it has to heal or it least alleviate pain and sufferings). If SW development process hurts Production- such process has to be modified. As many times as needed till it shows positive effect on Production.
Performance Supercharger for Leaders and their Companies
7 年Hi Michael. I like your post, and I don't disagree. Having said that, this is a common rhetorical device I see often from coaches challenging Scrum, and I in turn challenge you to change the narrative. The current narrative looks like this: "Scrum doesn't work because..." or "Scrum failed here because..." or "Scrum didn't really help because..." - you get my drift. Here's what I never hear: alternative suggestions. It is a one-sided take-down, but not a build up. If there are such great alternatives, please spell them out, explain them, and turn the dialog into something people can use. The only suggestion I got from your article is "just do what works." Well, if people already knew what worked then there would be no Scrum, no Agile, no XP, no Kanban, no nothing - we'd just all "do what works." So (in coaching mode here) instead of just tearing down frameworks and ideas, why not build one or more up? This article reads as "Scrum doesn't work for all these reasons," and then you cut short a potentially great ending by saying "just do what works." Try walking into the boardroom of a Fortune500 company or government buro and tell them to "just do what works." Try telling that to a CEO. Try telling that - heck - to a small business owner! You'll either be thrown out, or laughed out. I'm not sure which is worse. Scrum "works" because people, faced with uncertainty and complexity, can be given a pattern (heuristic approach) to use to help them navigate those challenges. If you have a better alternative(s), I'd love to see it become something useful, by which I mean useful to others. There are 45,000 (rounded) companies listed on stock exchanges around the world, somewhere near an estimated 115 million-ish companies overall (give or take a few million). There are 539,184 CSMs listed on ScrumAlliance (only as an example). That's 12 SMs/*listed* company, and some of those companies have 10,000+ employees and hundreds and hundreds of teams. "Just do what works" is why we are where we are today. We need something more than that. Again, though I don't disagree with your central point and argument, it is just another Scrum hit-piece right now, and as such offers only stinging critique - no credible alternatives or helpful options for all those individuals and businesses out there facing increasingly dynamic and nimble competition, complex markets, evolving technology, and rapidly shifting social and cultural dynamics.
Accelerate YOUR Business Growth - Win FREEDOM to Thrive! | Business Growth Delivery Accelerator
7 年Scrum will quickly expose impediments and bad practices, it does prescribe how to fix them. In the above scenario, the impediments are clear, thanks to Scrum!
Transformative Leader | Agile Enthusiast | People Developer | Operations | SDLC | Scaling Organizations | Systems Architect | LEAN Product Development
7 年You are ignoring the root causes of these problems. It is not Scrum itself. The root problem is the culture and mindset that exists in companies that may have been doing waterfall for years and now want to be more Agile. Teams in this situation will naturally be more attracted to a structure that is more familiar to them. Without proper guidance, even well intended leaders and teams can do the wrong thing. This happens because their experience is totally different than the future they are trying to adopt. Scrum is a perfectly reasonable approach to introducing teams that have no Agile experience to the new concepts they must learn. Different environments experience different levels of maturity. So, how much of the "Guide" they need will vary. But, teams will never just learn Agile concepts by reading about it or being trained. They need to experience it first hand. I am not sure what is this secret society of Scrum police that you encounter that are enforcing "true scrum". But, I would suggest asking them to leave.