In a recent post about Developer Certification, the author mentions hiring as the best way to find candidates, making developer certification about finding developers you can hire. And in many ways that makes sense – if you want the best, adjust your hiring process to find the best.
But that’s not why the Certified Scrum Developer (CSD) is around.
Last post I mentioned that the CSD was created because Ken Schwaber and the Scrum Alliance were being asked to help with teams that had adopted Scrum, but weren’t seeing the results they wanted because they didn’t have the skills necessary to ship software – working software – that frequently. In other words, they didn’t have a problem finding people, they had a problem training people.
The connection hit home for me when I saw Jeff Sutherland’s tweet over the weekend about an opening for a ScrumMaster:
ScrumMaster job in MA. Great opportunity. Managers finished CSM class today.
They were looking for a ScrumMaster, but they weren’t planing on rehiring their developers. I can see the conversation going like this:
Bob 1: Boy, that CSM class sure was insightful. How are we going to convert our team?
Bob 2: Well, we’ll need a ScrumMaster. Ain’t nobody I’d trust to do that here! Haha
Bob 1: [Laughs heartily]
Bob 2: And I suppose we’ll put our team through CSM training.
Bob 1: Sounds great to me!
It sounds silly, but in reality it isn’t. I know, because I’ve seen it in several training classes. In fact, when I took my CSM with Jeff Sutherland and Mitch Lacey, 90% of the class was from the same company. I asked the people at my table why they were there and the answer was classic: “Because our manager told us to come”.
Now, let’s say we have the CSD in place. Bob 1 and Bob 2 will now just send the development team to the CSD training, the Business Analysts and Project Managers to CSM training, and the managers to CSPO training. And then we’ll be agile!
Lessons from GM
In 1983, Toyota took over one of the worst plants General Motors had – the Fremont, California plant. They turned it completely around in 2 years. But when GM tried to take the practices that Toyota was doing at the plant and apply them to other plants, it failed miserably. Why?
Because practices without principles are worthless.
Toyota’s practices around Lean Manufacturing were important, but more important and much more vital were concepts around Empowering Workers, Stop the Line, and other fundamental concepts which counter traditional command and control management styles.
But it seems so easy, doesn’t it? Sprinkle a little product backlog here, a stand-up there, some TDD over there, and you have a recipe for product success? Or, rephrasing in Slashdot lingo:
- CSM
- CSD
- CSPO
- ???
- Profit!!!!
So changing our hiring practices is great, and worthy. But that’s not why the CSD is around. And it’s what makes it so dangerous – it’s an implicit assumption that if you just take the trifecta of certifications, you can become a Certified Scrum Organization, and won’t that be keen! And swell!
Let me know how that works out for you.
Cory, you are correct that developer certification is not about hiring. Developer certification is also _not_ about certification. It’s not about certification, because there’s nothing meaningful to certify.
I’ve been wrong before about certification. I thought the CSM idea was going to fall flat. Whoops! And, frankly, I’m happy that it didn’t. CSM has been a huge force towards agile adoption.
But I don’t think I’m wrong about CSD. I think it’s a terrible idea than can only do harm if it succeeds. The harm will come from the implication that the certification carries some kind of deep meaningful significance. Of course it doesn’t.
I remember when the MCSE was all the rage. People were studying brain dumps and passing tests left and right, resulting in paper MCSE’s that couldn’t build or manage a network to save their lives. The same can potentially happen with any certification.
The way I look at certifications is the same way I look at a degree – it says that you have a base set of knowledge. That doesn’t mean you can apply it.
Using certifications as a short-cut to better hiring or as an attempt to say, “hey, we’re agile – our people are certified,” is the wrong way to look at it.
I’m much more behind the software craftsmanship movement. As a community, tech has come a long way in a short amount of time. There is a lot of maturing still going on. But taking it back further, how much did you learn about in school (if you went for a CS degree) about TDD, continuous integration, or any of the engineering practices that many companies today are completely lacking? I’m happy to see version control in some places.
But I digress.
Ultimately, we cannot use a certification as the yes/no gate for hiring.
And I’m not sure how a CSD that teaches me tools for say Java or .NET are going to help me in the open source world with Rails or PHP.
Hi Robert D, on this: “And I’m not sure how a CSD that teaches me tools for say Java or .NET are going to help me in the open source world with Rails or PHP.”
It is not. You should learn things like how to refactor, the importance of TDD and CI and the benefits of pairing. I don’t see the CSD program as a “learn this technology” (the how), I see it as a “get introduced to these practices, and why”.
@Mitch that’s good to know. Having run a development shop for 5 years I’m already sold on all that you mentioned, and we have a CI server up and going. We’re 100% remote so pairing doesn’t apply, however I know many that get a huge benefit from it.
Sounds like an easy cert for those of us who have been practicing software engineering :) Though that doesn’t apply at scale, so I hope that it would on that level raise the status quo.