Reblogged with permission from Michael Küsters, the original author of this content. Originally published on LinkedIn, August 5, 2017.
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.
Source link:
https://www.linkedin.com/pulse/true-scrum-teams-michael-küsters
Many thanks to Michael.
blogagility.com 