The Scrum Alliance mission? Let’s talk about that. Fail better.”

The motto of the Scrum Alliance used to be “Transforming the World of Work”. In the fine print of their web site, it appears that the current motto may be “On a mission to create agile workplaces that are joyful, prosperous, and sustainable”.

If we look at the top of the page, we get another view of what they might be about:

you want certification. you want community. we give you both.

But let’s take them at their current fine-print word, and at their previous word, and suppose, against strong evidence, that something like this is the mission of the Scrum Alliance:

Create agile workplaces that are joyful, prosperous, and sustainable.

Let’s think about what you’d do if that really was your mission.

Who’s in this workplace?

A Scrum “workplace” has one Product Owner, one ScrumMaster, possibly one Coach, and as many team members as it takes to deliver a product increment every Sprint. (Emphasis mine.)

There will generally be around a half-dozen team members. On a software Scrum team, those will mostly be developers with programming or testing focus. Yes. There are probably six developers for every Product Owner or ScrumMaster.

It seems to me that for a team like that to be “joyful, prosperous, and sustainable”, the work lives of those developers would be critical. We can’t have a joyful team if those six people are miserable. We can’t be prosperous if those six people aren’t productive and thriving. We can’t be sustainable if those six people are burning out, or burning to get out.

The focus

At the level of Scrum, all ScrumMasters and Product Owners are “alike”, in that the Scrum-focused attention they need is pretty much the same for every ScrumMaster, pretty much the same for every Product Owner. Now of course there is much more to the job than just the Scrum elements, but the core behaviors are pretty much the same across all ScrumMasters, across all Product Owners.

The Scrum Alliance offers advanced materials, guidance, and training for those roles, moving far beyond Scrum, to help them blend the domain-specific aspects of their work with the Scrum model. This is as it should be.

Now, even if all the developers on a team are “the same”, in the same way that all ScrumMasters are the same, all Product Owners are the same, if the team is to be joyous, prosperous, and sustainable, you’d expect the Scrum Alliance to be applying the same diligence and creativity to the developers that they apply to the ScrumMasters and Product Owners.

Given that there are five or more times the number of developers to serve, you might expect that the number of people trained, the number certified, would be larger for developers than for ScrumMasters or Product Owners. That turns out not to be the case.

The last time I knew the numbers, there was approximately one certified developer for every one hundred certified ScrumMasters. If someone gives me the current numbers, I’ll be happy to update that sentence. I’m confident that it will tell the same story:

The level of true service and support which the Scrum Alliance provides to developers is a small fraction of the service and support provided to ScumMasters.

But they do offer training!

Yes, they do offer training, and there is low uptake of that training. The reasons are obvious and have been obvious for years. The training is expensive on a per-developer basis, and takes far more time than a ScrumMaster or Product Owner course.

What has the response been? They’re trying to figure out ways of “certifying” developers with less training required. I can see no way that this cunning plan can fail.

Well, except that the experts who created the original developer training cut it as short as was practical, long enough to allow the participants to experience a full cycle of failure and success. Less training surely leads to less-qualified trainees.

And, well, except that even at a low low two-day price, it will still cost five to ten times as much to certify my developers as it does to certify my ScrumMasters: there are just more of them. I can’t afford five times what I’m already spending!

We’ll come back to what to do about this: I think there are things that could be done. But first, let’s look at what the Scrum Alliance could be doing via its focus on ScrumMasters and Product Owners.

The Increment!!

I’ve observed quite a few Scrum teams, and my colleagues tell me about many more, and one of the biggest measurable failures they encounter is the Increment.

Scrum asks that the team select the amount of work they can do in a short Sprint period, and that they self-organize to do that work, and that at the end of the period, they deliver a working tested shippable Increment of product containing that work.

Every week or two, a Scrum team is supposed to

  • deliver a
  • working
  • tested
  • shippable
  • product increment.

This is hard to do. Every ScrumMaster, every Product Owner, learns that the team is supposed to do this, but it’s just one of the many things they learn. By the nature of their work, they focus on the things that are more about their own job, helping the team with planning and retrospectives, figuring out what the product should be, and so on.

They can’t build the increment, and they know it. They don’t even know how to help the team do it. So they file the topic under “not for me”.

The Scrum Alliance could change this pattern. They should change this pattern.

Imagine that the focus of the Scrum training and support was actually on getting the product done. You wouldn’t talk just about how to hold a retrospective, or how to slice a story. You would focus every possible element of your training and support on one single thing:

Your ScrumMaster job, your Product Owner job, is to ensure that at the end of every Sprint, your team delivers a working, tested, shippable increment. Here’s how X helps you do that.

The Scrum Alliance should focus on ensuring that every Scrum team can deliver what’s needed to satisfy the company, an Increment of product. In so doing, they’d create job satisfaction for developers, and they’d create a vast market for the training and support needed to help developers deliver the Increment.

But people won’t pay for developer training and support

The first objection to this is that “they” won’t pay anyway. And, honestly, I think it is established that “they” won’t pay the current prices, in time or money, for developer training. I think that’s established. We can’t create a demand that will bring five million developers in for a week or two of Scrum developer training.

We should try. We should offer it. It’s a great training, in the hands of those who do it well. It’s well worth the cost. But most organizations won’t pay it.

Now, longer term, possibly the Scrum Alliance could make the case that this expensive training is worth it, by producing crème-de-la-crème developers. Perhaps the market could grow, if they worked at it. But I don’t think that’s the answer.

Three orders of magnitude less

The answer is incredibly low cost training, in terms of time and money. Developer training today costs $500, $1000, or more, for every day of training. I’m suggesting that it needs to be more like $1 per day. Or less.

My streaming services cost me about $10 per month each, and I can watch as many hours as my eyes can stand. Even I, who wouldn’t turn the tube on if I were alone, see a few hours of Netflix, Amazon, Disney, every month.

Developer training needs to be three orders of magnitude less expensive than it is now. It needs to be on demand, able to be consumed in periods of thirty minutes to an hour at a time.

There’s no money at that level

Tell that to Netflix. Tell it to the YouTube folks who make a good living with how-to videos. Tell it to JS and JR, who have a pretty decent income from developer videos today.

Multiply a dollar a day times five million developers, I’ll wait. For the impatient: $1,825,000,000. Per year.

The money is there, it’s just widely distributed.

The Scrum Alliance could get a decent share of a number like that, if they had the will, the guts, the honesty to do it.

What Should Be Done?

The Scrum Alliance, if they actually cared about joyful, prosperous, sustainable workplaces, would do two things:

The Increment
First, they would focus every possible training, every possible support element, every possible communication on the central notion of successful product development with Scrum, producing the Increment. This would produce demand for the ability to do so.
Nearly Free Training and Support
Second, they would get behind the creation of incredibly low-cost, high volume training and support for software developers working in Scrum. This would fill the demand.

I think it’s probably pretty simple to do the first item, but I’d be willing to help them figure out how it is that every Scrum element drives toward the Increment if they need assistance.

The second item is a bit less obvious, but still straightforward if someone really wanted to create joyful, prosperous, sustainable workplaces.

  • They’d create a small team to identify the learning objectives for developers. Much of this is already in place, much is already in pretty good shape.
  • They’d create a new organization, perhaps a subsidiary, perhaps independent, focused on developers. This would be small, mostly an organizing shell for community activities.
  • Through that organization, they’d reach out to and organize existing on-line developer training, and subsidize the creation of more such training, taking a small percentage of revenue when it begins to flow. This subsidization isn’t large: this training isn’t developed by large organizations, but by one or two individuals.
  • The new organization would serve as a central “source”, a sort of search engine for the training you need. It wouldn’t be branding, trademarking, making everything use the same slide backgrounds. It would share ideas and techniques among the individual providers, helping each of them grown their own little business.

This wouldn’t cost much. It would be difficult. It might fail.

But the Scrum Alliance is already failing in this key market. This might be a way to fail better.

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”
– Samuel Beckett