Herewith, some remarks pro-Scrum, and a reminder that Scrum is not as good for developers as it might be. Even some advice to developers.

I had intended to make these remarks as part of this morning’s first “article”, my letter to the CPO of the Scrum Alliance. But it’s long enough, and probably boring enough, that I thought I should publish these remarks separately.

Praise, Not Too Faint

I think that Scrum, done well, is a good way to produce software. (The catch is in “done well”, as we’ll see below.) Scrum, done well, brings together all the skills needed to build the product, and asks for a Product Increment every week or two.

The Increment is to be a working, integrated, tested, fully shippable chunk of the product, containing all the features and capabilities built so far. You might not ship it because it’s incomplete, but what you have must be solid in every other way, solid enough to ship if someone could get value from just the features you have so far.

The various Scrum meetings are pretty much on point to bringing the team members together around the creation of the product, and include a regular session where the Increment is displayed to stakeholders, and their feedback is solicited and recorded.

If I were developing a software product, I could do every good thing that I know to do, all within the Scrum framework. It really is good enough.

Perfect? No, there’s more that one could do. We could produce Increments daily or hourly, each one ready to go, not just every couple of weeks. We could move to continuous deployment. We could adopt DevOps ideas, Lean ideas, and so on.

None of these is particularly incompatible with Scrum.

Scrum, done well, is a fine way to do software development.

Scrum is not enough

Scrum doesn’t even claim to be enough, if you read the fine print. If you just read the cover, it screams things like Twice the Work in Half the Time, and if you’re a busy exec, you call in your serfs and slap the book down on your desk, still smelling of airport, and demand that your serfs start doing this Scrum thing.

And they’re not doing it anyway …

One third of my survey respondents have no Scrum-trained people on their product effort. And you can bet that my Twitter followers are more trained than the many more who have never heard of me.

One third of Scrum users are trying to do Scrum with no training.

One third! No training!

How could that possibly work?

What more is needed?

Well, within Scrum itself, you really ought to have experienced it or had some good training, or something, just to get the drift of how it works.

Outside Scrum, your Product Owner or someone else on the team, needs to understand your market, and the kind of product you’re trying to set out to build, at least well enough to set priorities. It’s entirely possible for the PO to defer to the team on this, but “the team must have all the skills”, and knowing what to build is, let’s face it, kind of important.

Developers, the folks close to my heart, need to know how to produce a working tested Increment every couple of weeks. If you know how to do that, you probably also know that the way you do it is to keep the code working and tested every day rather than taking the last few days to try to bring the mess together and make it work.

Developers need to know how to start with a near-trivial design, and zero code, and to build continually, week after week, creating more code and more design and more tests, all in parallel, making a product that’s a bit better every day.

And that’s not easy. If you’ve been following my articles on the Dungeon and other programs, you know that with the best of will and the best skills I have available, every now and again I insert a defect, it slips through my testing, and I publish a version of the program that will crash, or maybe not work at all.

What’s needed, in overview, is the ability to evolve a design from zero to wherever it needs to go. The skills to do this, continuous testing, continuous integration, and refactoring, are not innate in programmers, they are not taught in most schools, and they’re not easy to learn on your own.

The necessary development skills are lacking in a very large percentage of Scrum teams. How big a percentage? No one knows. The Scrum Industrial Complex could probably find out, if they wanted to.

What About the Certified Scrum Developer Program?

Yes, what about it?

In the not so distant past, the CSD course was originally designed, by experts in iterative, incremental development, and by me, hanging around, to require five days of training, including actual programming. In the best courses, there was real programming in at least three and as many as five days.

That training was very hard to sell, and was not broadly taken up. Few development managers could spend that much time, and that much money, training developers. We often heard that “they’re developers, they should know that already”. Yes, well, they don’t.

The requirements were reduced, to allow a shorter course, with a scrum introduction, but still at least a couple of days of programming. The new reduced course was surely less effective: there was simply less of it.

There still wasn’t enough uptake.

So the requirements were changed again. Now there are at least two, arguably three developer certifications from Scum Alliance,

The first one, Certified Scrum Developer, now requires “at least two days of formal training taught by a Scrum Alliance-approved CSD Educator”. Here are the official Learning Objectives.

Read those carefully. Note the verbs from Bloom Taxonomy used. None of the objectives require that the “Certified” Scrum Developer has ever even seen real testing, refactoring, or any developer skill. They have to be able to “define” them, to “explain” them.

The Certified Scrum Developer of 2021 will indeed have been exposed to words, and probably slides, introducing the key concepts of development under Scrum. I’ve not made a checklist, but I think everything I’d expect is probably in there.

In words. No practice. Words.

Here are the LOs for “Advanced” Certified Scrum Developer

Look there at the things you must demonstrate as a developer, according to these Learning Objectives. Here, at least, you must be able to demonstrate a “refactoring approach”, to demonstrate building something with TDD, practice automated build, apply a continuous integration approach.

You can become an “Advanced” Certified Scrum Developer, after a year of being a “Certified” Scrum Developer, with a course and an instructor’s assessment.

Too Little, Too Late

Howard, I think, feels sincerely that the new CSD, A-CSD, CSP-Developer is a better and more realistic path to allow the Scrum Alliance to better serve the developers who work under Scrum.

What is better, in my book, is that the Learning Objectives do make clear that there’s more to Scrum than Scrum. And certainly a two-day CSD course, which could be entirely slideware, should be able to be offered at a lower cost and therefore might draw more developers into the learning cycle.

It might even work: it remains to be seen.

But at what cost? All the programming is removed! You can’t learn programming just by reading a book, much less reviewing slides. You have to program to learn programming. You have to refactor to learn refactoring. You have to to TDD to learn TDD.

You have to experience those things to even begin to understand what they are, and you have to experience them for a while to begin to understand how to make them really useful.

Now a supporter of the new CSD may protest that there’s nothing to say that a CSD course can’t include programming. That’s true, in the same way that it’s true that there’s nothing to say that your two-day introduction to furniture carpentry can’t include building an armoire.

What To Do?

Besides my article showing how I do it, I’ll try to keep the pressure on, so that perhaps the Scrum Industry will step up to the very reasonable inexpensive things that they, and really only they, can do to help developers.

For developers, this:

My letter, from the previous article, and the related articles referenced:

If the Scrum Alliance Cared, Double Down: Scrum v Devs, Increment? What’s that? and Survey says ….

I’d also call your attention to this one: Developers Should Abandon Agile.

Bottom line, if you’re a developer, sure, take a CSD course if you can get the boss to spring for one, and yes, definitely check out the learning objectives for CSD and more importantly A-CSD, and use them to steer your own learning program. Work together with other interested developers if you possibly can.

If you follow my articles at all, one lesson to learn is that it’s possible to do a little TDD or a little refactoring in a couple of hours, and to learn something. Sit down with a pair, with your mob, and test something with an automated test, or build some little thing with TDD, or refactor a bit of code to make it better.

Maybe even revert, if you’re not confident. But practice.

And look outside the Scrum Alliance and Scrum.org for your learning. The following list is incomplete, but it’s a start. N.B. Many of these folks are personally known to me, but not all. √ means their work is known to me in some detail. If I don’t know their work, it’s my fault, probably. Give them all a look. I’ll update with links, when I get them all. I think most can be found on Twitter pretty easily.

  • Bryan Beecham
  • David Bernstein √
  • Mike Bowler
  • Alex Bunardzic
  • Fran Climent
  • Darrey Downey
  • Dave Farley
  • Jason Gorman
  • James Grenning √
  • Chet Hendrickson √
  • GeePaw Hill √
  • Fran Iglesias
  • Chris James
  • Joe Justice
  • Liz Keogh
  • Sean Killeen
  • Lancer Kind
  • Dave Koontz
  • Per Lundholm (Swedish)
  • Paul Moore
  • Dave Nicolette
  • Pedro Pardal
  • J.B. Rainsberger √
  • Jon Reid
  • James Shore √
  • Amitai Schleier √
  • Sam Taggart
  • David Tanzer
  • Jan VanRyswyck
  • Bill Wake √
  • Ted M. Young

I just typed that list offhand. If I forgot you, remind me and I’ll update.

The main thing, I think, is not to wait. Don’t wait for Scrum to care about you. Care about yourself and your team members. Find ways to learn, not because you’ll get a certificate on pure PDF vellum, but because you’ll enjoy your work more, as you bring it more into line with what’s needed.