An Interesting Web Site

The End Scrum Now site, a bit of a rant, raises important issues. Let’s explore some of them.

One of my dearest colleagues sent me a pointer to the End Scrum Now site. My first action was to deny to the Scrum Alliance that I wrote it: I didn’t. The site’s ownership is masked Private By Design, LLC, via Porkbun. I’d rather like to be in touch with the site’s owner. The site itself reminds me of the article by Mr Giles Bowkett, back around 2015, “Scrum Should Die in a Fire”. Mr Bowkett has moved to a new site now and I couldn’t find the original article. No problem, never mind.

You can search my site for “die in a fire” and find those articles if you really have nothing better to do. Today, I’ll take my current as of today cut at the topics in the newer End Scrum Now article. I propose to do something like this:

Quote ESN’s heading;
Express my own view;
Express what I believe a typical Scrum trainer or company might say about the ESN topic;
Rebut the argument that I just made up.

Let’s get started.

End Scrum Now?

The article begins with a commitment never to be abused by Scrum process again, and a claim that Scrum gets worse and worse every year.

Ron says: I think there is an element of truth to the claim, in that Scrum gets to be more and more used, and probably some standard fraction of it goes wrong, so in fact Dark Scrum and its not-very-light relatives surely does increase.
Scrum says: Yes, but Scrum gets better every year as well. More and more people are taking advanced training and learning more about how to do Scrum well. Scrum’s not easy, and our comprehensive training and learning objectives reflects the fact that there’s a lot to know. If people have not gone far enough in learning Scrum, if they’ve not come to us for training, there’s not much we can do.
Ron: There is truth there, but as I’ll talk about elsewhere, I think Scrum also has a serious responsibility toward those who have not heard the proper word as yet.

Teams produce less working code

Ron: I’d like to see some real data on this. Do existing teams actually produce less code, or is ESN observing that the new teams they see today are less productive than teams they knew in the past.
Scrum: We have no evidence that this is the case, and we doubt it seriously.
Ron: That you have no data is the bug here.

Scrum ceremonies become more inane and waste development cycles

Ron: Again, we need data. Is this team deterioration, or new teams doing poorly? Are they really more poor than new teams of the past, or just poor relative to what they might be? Are these teams as well trained and as well practiced as the teams ESN is comparing to?
Scrum: What he said.

Developers start to see Scrum meetings as a waste of everyone’s time

Ron and Scrum, in chorus: I see a pattern here of unsupported claims, relating to some past state which was “better”. We need better information to draw much of a conclusion.
Ron: Going forward, let’s assume that the headings express something like “problems commonly seen” in Scrum, and focus on the causes, effects, solutions. None of us wants any of the problems here.
Scrum, tentatively …: OK …
Ron: Meetings can be boring and disruptive. The Scrum rules are clear about time boxing the meetings, and I’d bet that this is almost never done in practice (but I have no data). Meetings can be unproductive if people aren’t prepared. The Sprint Review can be horrid if there’s not much done. (What fraction of Scrum teams have these? What fraction have an Increment to center the meeting?)
Scrum: We do teach time boxing. If they don’t use it, it’s not on us. We do say to have an Increment. If they don’t have one, it’s not on us.
Ron: $%#$%!! If we’re “teaching” X Y Z and people aren’t doing X Y Z, then our educational system is broken. It’s flat wrong to turn our back saying, “well, I told you”. Our job is to make things better, not just spout good ideas into the wind. (This web site, and my life, notwithstanding.)

Lower quality code is produced, more slowly

Ron: Scrum demands incremental software development, building features and infrastructure together. This is difficult, requires techniques that are not generally taught in school or JavaScript classes. Without these techniques, even the best team on earth will slow down and produce lower and lower quality.
Scrum: See, it’s not our fault. We tried to teach developers, but they wouldn’t show up with $5000 for a four or five day course that taught them the rudiments of those techniques.; Heck, we’ve even redesigned our Certified Scrum Developer program to make it less costly and easier to get started.
Ron: You did that by removing all the programming requirements from the CSD, and cutting it to two days. The new course is so weak that you’ve automatically upgraded all the graduates of the previous version to Advanced CSD.
Scrum: That’s not fair! We’re trying to make it more accessible so that it will be more popular, so that we can teach them that they need to know more, so that they’ll hunger for more.
Ron: I understand the idea.

Some team members produce nothing, no one seems to notice, even the Scrum master.

Ron: Not a Scrum problem? If I had a productive team (which we seem not to have in ESN’s world), I might not even care if there was a team member who seemed to be doing nothing. I’d look at it, but their effect might not be easily visible.
Scrum: Yes, not a Scrum problem

Software engineers enjoy less and less career satisfaction

Ron: In Dark Scrum situations, which seems to me to be what ESN is talking about, software developers are placed under pressure while they are not provided what they need. This definitely doesn’t lead to career satisfaction.
Scrum: I fail to see how this is our problem. We specifically said that the team self-organizes, and that only the team decides how much work to take on. Pressure shouldn’t be applied, and if it is, it should be ignored.
Ron: You can’t ignore pressure from management. If these developers are not happy, then their Scrum process is not working. As the purveyors of Scrum process, we have a serious responsibility when it doesn’t work.
Scrum: Scrum is a perfect system. It can’t fail to work if you do it right.
Ron: Scrum is a lightweight framework, by design. As the work of humans, it is surely flawed. By design, it does not have extra checks and balances. It is a loose net, full of holes. Taking a systems viewpoint, we can see many ways it can go wrong.
Scrum: Can not!

Ron :Can too!

Product knowledge is lost over time

Ron: I don’t see a way that Scrum could be to blame for this.
Scrum: What he said

Process knowledge is lost over time

Ron: I am aware of a not-uncommon instance of this: A growing number of teams are doing what they call “kanban”, which really means that they have given up even trying to build an increment. This could be seen as a loss of process knowledge.
Scrum: It says clearly in the Scripture that if you’re not doing Scrum, it’s not our problem.
Ron: If they’re not doing Scrum, there is something wrong with your sales cycle, your installation cycle, or your support cycle. The “Scrum System” isn’t working.

Managers become ghosts and do not work with developers or really do much of anything

Ron: I’m not sure if this is a sign of bad Scrum or good Scrum. I need more information.
Scrum: Yeah, more info

No one in any company bothers writing user stories, development is just a ticket system with few poorly defined requirements, or optionally nothing in the ticket.

Ron: Yes! The “success” of Jira in the Scrum market has replaced human communication with putting stuff into a ticket system. This militates against the essential aspects of Scrum and Agile as a way for humans to work together. In my opinion, Jira is directly harmful to proper Scrum.
Scrum: We don’t say anything about Jira. And if we teach stories, it’s not our fault, they are part of XP. We call them backlog items. It’s not our fault.
Ron: It’s your ecosystem, you are responsible for what grows in it.

Developer’s wages are being suppressed by forcing them to report to low paid laymen with Scrum certification.

Ron: Interesting, if true. I had not heard this concern before. I can imagine some truth here. And another consideration not often mentioned is whether having an effective team lessens the need for “stars”, and thus places downward pressure on developer wages.
Scrum: Interesting, but not really our problem.
Ron: Ecosystem.

Career advancement for developers is nearly non-existent

Ron: This was common before Scrum and probably still is. The career ladder may be worse, however, because notions like “team lead” are deprecated, at least implicitly, by the team focus of Scrum and Agile.
Scrum: Interesting, but not really our problem.
Ron: Um, ecosystem.

Scrum masters who are mostly unqualified laymen, treat developers defensively and increasingly with hostility, trying to manage conversations they simply do not understand because they the Scrum masters know they are not adding value without looking like they are “in charge”.

Ron: Could be. Could also be, and I am looking right at ESN here, that the devs treat non-developers with hostility. Many of us are nerds and hold little respect for those who cannot work the wizardry that we can. The males (I won’t say “men”) among us are famous for misogyny as well.; I’m not convinced that Scrum is at fault here, but it does place developers and people with other skills together. If a ScrumMaster had truly low skill, I can imagine it would be hard to gain respect.
Scrum: We invented the ScrumMaster role so that we’d have something to certify. If it doesn’t work, it’s not our problem.
Ron: Whose is it then?

Team autonomy is talked about but essentially non-existent

Ron: I have seen this often, and suspect it’s nearly endemic. (Data!) I believe that a team delivering regular Increments can work its way to more autonomy. But I’d really want to know what autonomy ESN is seeking: there are things the team can own, and things they can’t.
Scrum: We told them self-organizing. If they don’t do it, it’s not our fault.
Ron: Did you train the people who are making these teams lose autonomy?
Scrum: Almost certainly not. If they took our Leadership training, they would know better.
Ron: How many have taken that training?
Scrum: A lot …
Ron: Again, it’s the Scrum Ecosystem that is to blame. Maybe Scrum has planted a lot of really great seeds with the going on two million trained ScrumMasters who are out there. But the soil upon which those seeds fall is rarely truly fertile for ideas like self-organization.
Scrum: If they won’t take the training, what can we do? It’s not our fault.
Ron: We’ll talk about that shortly.

Scrum planning and grooming never produce anything close to predictable velocities or deliverable dates even after years of scrum on the same team.

Ron: I believe this to be common. Between half and three-quarters of teams surveyed do not regularly produce an Increment. Almost thirty percent never do. You can’t have predictable velocity if you can’t produce an Increment every damn time.
Scrum: We told them …
Ron: How’s that working for you?

Developer mentorship is mostly non-existent

Ron: I believe that. Nearly three-quarters of teams report that none of their developers have Scrum-related developer training of any kind. (And two days of slideware isn’t going to change that.); Another thing that’s worth thinking about is the systems effects of team focus, not having identified developer growth paths, and low manager contact. Could that lead to a tendency for experienced developers to have no incentive to help the learners? Could there be a focus on individual story completion, making working together actually harmful to one’s image?
Scrum: We’ve been offering the Certified Scrum Developer program for years. No one has bought any. The market just isn’t there.
Ron: This guy right here tells us that the market is there. He’s crying for developer help. Scrum has failed to tap the market. The problem is the product, not the market.

ESN’s Summary

Ron: Too ranty to really comment. I think we can readily see that in ESN’s experience, teams doing something that they called Scrum were not thriving, and were suffering from problems that we can all agree they should not be suffering.; And I would say that for most of the concerns ESN has, and most of the concerns I’m aware of, I could point to the words in the Scrum Guide that tell the suffering team exactly what they should be doing to alleviate their suffering, and not always just “well, that’s an impediment, remove it”. More specific advice, like time boxing, delivering working software, and so on; Do they not do those things because they don’t know, or do they not do them because something in their corporate systems stops them? When something goes wrong, we may well find some human at the center of it, but our learning tells us that the system has failed, not the person.
Scrum: Right! Scrum doesn’t fail. They aren’t doing it, or aren’t doing it right. We told them. It’s not our fault.

Let’s Talk About That

I want to put it clearly right here: I think Scrum is a pretty good process. If I were put in charge of a software product development and told that I had to use Scrum, as close to by the book as possible, I’m confident that I could build a thriving, happy, productive team that had as good a chance of building the product as you could want.

It’s not the best process, but it’s a perfectly good place within which to succeed. I would not make the same claim for, say, waterfall.

The problems ESN raises, and the many more problems of which they are examples, are real. I have enough evidence to be convinced that they are common. I am aware of no survey or study that would even begin to tell us that they are not common.

And yet “Scrum is OK”. What’s up with that?

At the risk of an odious comparison, I am reminded of the parable of the sower, in which the seed that fell upon stone, or among thorns, or is taken away. Nothing good came of those seeds, but the ones that fell on good soil took root and grew well.

There is a serious parallel between this story and the story of Scrum. A good idea spreads all over, but often comes down in a situation where it is quickly taken away, can’t take root, or is strangled out of existence.

Given that view, it’s easy to say that there’s nothing wrong with the seed, it grows just fine when given good soil.

I want to ask some questions, however.

Why are you sowing the seed on rocks or thorns if it won’t grow there?
What are you doing to eliminate rocks and thorns, before or after the fact of Scrum training?
What are you doing to change the seeds to that they can thrive even among rocks and thorns?

From a more modern viewpoint, I want the Scrum Industrial Complex to take a more systems viewpoint of what they’re doing. Scrum Alliance claims to be trying to create:

agile workplaces that are joyful, prosperous, and sustainable.

To do that, difficult as it is, the Scrum Industrial Complex needs to focus on the entire ecosystem within which Scrum exists. They need to work to change rocky soil into fruitful soil. They need to find ways to eliminate thorns, or turn them to our benefit. And they need to change the seeds – their training and education – to be better able to create joyful, prosperous, and sustainable workplaces.

To do this, first of all, they need information. They need to determine, in a scientific fashion, the extent to which concerns like those discussed here are endemic in Scrum situations. And they need to do that, not just in those situations where the Scrum ideas have been installed by official SIC trainers and coaches. They need to consider Scrum as it exists, because Scrum as it exists is a function of the SIC training as it has been passed on by the individuals trained–which is an explicit job of a ScrumMaster, by the way–and a function of the articles and books that they have published, and that other Scrum advocates have published, and a function of the talks given, the interviews, the random chats on airplanes: all of it.

Get the information, correlate it with training. (Yes I surely hope that it’ll show that more training leads to more success.) Don’t stop there: figure out why it fades as it gets one, two, or more steps away from the source. Find ways to get the pure quill into the ears and minds of more listeners.

Find ways to provide direct support to classes of individuals who are under-served, such as developers. It should be clear from years of experience that broad and deep sale of Scrum developer training isn’t going to serve millions of Scrum developers any time soon.

Find another way. (I may have suggested one or more.)

Scrum, and the Scrum Industrial Complex, is a Big Goddamn Deal. It is disrupting software development, and not always in a good way. It’s not enough to just say “well, if they listened …”.

Scrum owns all of its effects, and owes it to those affected to give them what they need to survive, and thrive, under Scrum.

Scrum: But we told them!
Ron: Yes. Now tell them better.