I’ve think I’ve figured out the disconnect between my view of the Scrum Developer priorities, and those of the Refactoring Team who created the new CSD track.

Scrum’s view:
Scrum works.

The Scrum Alliance knows that Scrum works well if you do it well, and therefore the first thing to do in serving the developers, or any role, is to ensure that they understand what Scrum is, how it works, and that they own the responsibility to use their human and domain knowledge to improve to the best possible performance they can attain.

Therefore, if you’re Scrum Alliance, you begin all training with Scrum’s definition and principles. You might close initial training by referencing specific Scrum- and domain-related techniques that have been found to be of value. You’d have a handy list of techniques that ScrumMasters, or Product Owners, or even Developers might need.

My view:
Devs need developer skills.

Whereas I have a different priority, which is to provide developers with the specific development skills which are unique to iterative and incremental software development, because I believe it is the lack of those skills that is holding back Scrum teams who aren’t completing the increment.

That’s it, I think. The Scrum priority is to ensure first that people understand Scrum and how it works, and only then to delve more deeply into specifics. The Jeffries priority is to provide dev-specific material ASAP.

Who’s right?
Scrum is.

Who’s right? Scrum is right, because it’s their process and they get to decide how to present it, and they get to live or die on the results of doing so.

And I don’t really disagree with the notion of starting from principles and moving to practice, though when I would teach a CSD class we got down to real programming pretty darn quickly. But I’m an XP guy before I’m a Scrum guy, and that’s how we roll.

So if–and it’s an important if–if you’re going to split a development track into Thing 1 and Thing 2, it may make sense to split the learning objectives as they have for new CSD and new A-CSD. No, I’ll go further. It does make sense. It may or may not work.

How might it work?

Making the best argument I can on their behalf, I might say this:

The old CSD was expensive in time and money, and while it is valuable, the value was clearly not obvious to the many people who decided not to take it. The new CSD is far less costly, and with any luck at all, it will demonstrate the value of the ideas and arouse a hunger for more.

Therefore, if it works, it will bring in far more individuals into the initial class, and even though only a fraction may go on with the program, we’ll have a larger number initially trained, and we might even wind up drawing more into the second phase.

There are two ways to win with new CSD. First, at a lower cost, it can deliver substantial value to more people. Second, it might even draw more people into the flow of more learning, resulting in a greater uptake of the whole thing.

This is a credible argument, at least to me, and I have neither data nor logic to refute it. It could fail to work, but it’s not a bad approach, and with care taken in pushing lots of understanding and value into those first two days, it might well work. If not, well, inspect and adapt, or withdraw from the market. That’s how this stuff works.

So am I on board now?

Well, yes, and no.

Yes:

I do understand better why the plan may have turned out as it has, and I can see that it has a decent chance of being better than what went before. I think Andreas may actually have mentioned “incremental improvement”, and this is arguably an incremental improvement over the old CSD.

I suspect that it was possible, is possible, for the Scrum Alliance to better express this strategy to its potential critics. And I’m not the only one who has felt that the changes are not for the better. I’m probably the noisiest, but I’m not even the most passionate that I’ve talked with.

And I even understand how they’d be mad at me for not seeing that this new CSD plan is a good-faith effort to improve, and for not patting them on the back for it.

Fine. Back patted. It’s a decent plan as far as it goes and it might work. As the small project “Refactor CSD”, I do think it’s an acceptable try, now that I’ve figured out what they were doing. Would have helped had they told us, but maybe they did and I just didn’t get it.

And, no:

But here’s my list, the current version of the list I’ve been pushing since way back when Chet and David and I originally defined CSD:

  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 new CSD program is #4 on this list. As far as I know, there is no commitment or progress on numbers 1, 2, 3, 5, and 6.

Scrum Alliance might argue that they do care about developers, because they are working to improve the CSD program. Well, OK.

Perhaps I can be forgiven for thinking that we can measure how much they care about the developer under Scrum by assessing how much they talk about and work on all six of these items.

I accept that CSD is–quite possibly–a step in a good direction. Incremental improvement, I get it. Not the one I’d have chosen but I have no skin in the game.

Now I want to know what the next developer story is at Scrum Alliance. I await their reply.