Windmills: Can Scrum be fixed?

I’ve chosen a large windmill at which one might tilt. Could we, of good heart and great skill and courage, fix Scrum? If so, should we?

I’ve been writing lately about seeing Scrum’s ubiquity as an ecosystem, at Scrum’s damaging aspects, such as near-compete lack of effective attention to developers. I’ve been trying, so far without success, to get useful attention from the Scrum Alliance¹. I’ve been chatting on some Slack channels about what needs to be done, I’ll be in a Zoom convo about it later today, and–worst of all–I’m wondering whether “we”, as a community, could “fix” Scrum, by changing the world’s understanding and execution of Scrum.

The good news on this is that there are a lot of opportunities to “fix” Scrum. And quite possibly, some of the isues are actually capable of being improved by increasing understanding, knowledge, and valuable practice.

There are many reasons not to tilt at this windmill. There are many fun and valuable things we could do, and this windmill is difficult and perhaps it cannot be defeated. I myself have other things to entertain me, so I might just ride out from time to time, take a few jabs at the thing, and then go back to programming in Lua or something.

But Scrum is almost ubiquitous and in addition it is found almost everywhere. If we could make it a few percent better, the world impact could be large, because of the large number of people working Under the Thumb of Scrum.

One large question, for me, and for anyone I might be able to recruit to this effort, is whether Scrum is worth fixing. If it is, then its ubiquity and tendency to be found all over may make fixing it valuable. If it isn’t worth fixing, we should bend our efforts to burning it down, replacing it, and otherwise Scrummo Delenda Est.

My own current view is that, subject to terms and conditions to be worked out, Scrum isn’t a bad way to work. Scrum, if you fuzz your eyes just right, is like XP except it forgets to mention how to actually do the work, and I’ve worked in XP a lot and it was really quite nice. So I think Scrum, if we dealt with some issues like its oversight on how to do the work, could be nice as well.

Of course, I’m talking about Scrum By The Book, not Scrum On The Ground. Scrum On The Ground is often just horrid, and that version should in fact be burned to the ground.

There is a potential major objection to Scrum, or rather to the Scrum Industrial Complex, and that is certification, or its thinly disguised cousin, “professional”. The SIC sell certifications, or certifications under another name, and while the courses offered are often actually valuable², the certifications are often not worth the PDF certificate you get when you complete the work.³

I know that many of my very respected colleagues, and probably every developer on the planet, thinks that the “Certified” bit is a marketing scam of no value. I was, for a while, able to hold my nose and get over that. But perhaps that issue is enough to scuttle the idea.

On the other hand, suppose we had in mind a way of doing Scrum that we felt was “good enough”. Could we then, all tilting at the same windmill at the same time, bring the world around to something like “Yes, the ‘certificate` is a marketing gimmick, but This Scrum Right Here actually has value …”?

I don’t want to get all utilitarian, but can we find a useful way to do only good things and make the Scrum ecology a better place to be?

I honestly don’t know. Let’s talk about some issues.

Scrum Issues

The Developer

My own hobby horse, of course, is the plight of the software developer in Scrum. I’ve recently written about the issues that the developer faces and what I would like to see the Scrum Industrial Complex do about it. Briefly:

1. Recognize responsibility for the entire Scrum Ecology.
2. Do a deep and broad assessment of the Scrum Ecology.
3. Focus much more strongly on communicating the value of the Increment in successful Scrum.
4. Continue to offer developer courses, recognizing that this is just skimming the lucrative cream, from a small fraction of the market.
5. Allow developer certificates to be earned entirely via external sources (Scrum Education Units).
6. Support independent providers of developer-focused training, web sites, books, etc.

The first two of these would surely discover other opportunities for improving the Scrum situation.

Management

Agile methods like Scrum really need a different approach to management than is common. The SIC offers “Leadership” training, in aid of this. As with most everything outside the ScrumMaster training, there is limited uptake. However, since Leadership is where the money is, this area might well be able to be addressed via conventional training means.

I think we can be sure that they won’t read long books. Maybe some shorter ones?

Imposition

Scrum is often imposed by management. Some of my colleagues would argue that this is invariably inappropriate. I’ve written elsewhere on how I would “impose” Agile, which is to simply state that I propose to manage the development by inspecting its work on a regular basis, and offering support for making that possible.

One sub-windmill to tilt at is surely this one. How should “management” manage its would-be transition to gaining the benefits of Scrum/Agile/etc?

Scrum Coaching

The Scrum Alliance could be seen as trying to build a monopoly around Scrum coaching. I know many of the individuals involved in its program, and I think they are sincerely trying to create a series of learning objectives and hurdles to produce good coaches. The monopoly aspect is still troubling.

The market is also flooded with Scrum or Agile “coaches” who have transitioned from Project Manager or Management Consultant, or laid-off project leader or lawn care technician and hung up a coaching shingle.

If this situation were found to be dire enough, it might make us lean toward the burn-it-down strategy. I’m hopeful, if not optimistic, that we can create a way to make things better.

Broken ScrumMaster Strategy

This is a serious concern that is rather hidden. In Scrum, it is the job of the ScrumMaster to explain Scrum to the team, to the Product Owner, and to everyone else in the company who needs to understand it. Yet, the average ScrumMaster is a retreaded tester, project manager, or business analyst who has neither the experience nor the clout to deal with those people in the organization, and who has two more days of Scrum training than the people they’re supposed to be helping.

This issue may lie at the base of a lot of Dark Scrum.

“But We Have Courses For That!”

I’m not sure if this is a big thing, but I believe that it is. The standard Scrum Alliance position on Scrum dysfunction seems to be “We have a course for that. We told them what to do. If they don’t listen, it’s on them, not us.”

Now, in a sense, this whole windmill idea is about picking up the slack that that view leaves, but if the SIC is going to stamp out unqualified people as fast as it seems to be able to, we’ll never catch up. I think we need to find a way to make them recognize that they’ve created this entire Scrum Ecology and that they are responsible for misuse as much as for use.

And More …

Tell me what other major issues we must consider …

What Might Be Done?

I’m sure that a lot of us who are essentially outside Scrum but inside what I’ll call “Agile” here have similar experiences, similar objections, and similar responses to the issues above and the many other issues a Scrum team may encounter.

Some of us help developers. Some help product owners. Some help management and leadership. Some help testers. And so on.

All of those areas need help. And in Scrum, there is, I believe, a collection of issues that are commonly encountered, with a collection of “fixes” that are commonly tried, which fit into patterns of help.

Let me take what I think is a fair example, what GeePaw Hill might do, compared to what I might do, in helping a team who are having difficulty delivering any software.

We’d both be looking at what’s really going on, and we might encounter some force on the team asking them to take on more than they can do, and we’d work in our unique fashion to fix that. But let’s imagine that the team isn’t under any visible pressure but that they seem always to take on more work than they can accomplish. Some kind of self-imposed pressure perhaps.

So Hill maybe comes at it from his more and more smaller and smaller things angle, and maybe I come at it by explicitly helping with small slices, and maybe I get them to pick something they can accomplish today, even it it’s just a typo that they fix.

Point is, there are a number of common reasons why they don’t get anything done, and they mostly come down to trying to do too many things that are too large. So, maybe, possibly, we could “all” be sure to be describing the problem in our own way, but a consistent way, and the solutions in our own way, but a consistent way, so that over time, everywhere you looked you’d see a problem you have and lots of help with it.

And I think most of that help needs to be free, or nearly so. Not that we all don’t need to make a living: we do. And if we can help a company improve, we may deserve a good living. But there’s a lot of need in the world, and our solutions are in the form of knowledge, understanding, and guided practice, and those things can be delivered to individuals and teams at low, near zero cost.

So. Is it possible, sensible, rational for us’ns who know some things to come together in a loose kind of way and try to focus enough light and heat on Scrum as to soften it up, shape it better, and make the world better for everyone using it?

I honestly don’t know. I haven’t given up, but I may not be sensible and rational.

What do you think?