Perusing job descriptions, I notice that a lot of companies have requirements for certifications. I am not talking about jobs for attorneys where they expect a law degree and bar membership, or a position for a medical doctor, where they expect a medical licence. I am talking about the business world. As my field of interest is business architecture, analysis, transformation, and strategy, and I’ve got an opinion or two on custom software development, these are the descriptions I tend to read. If the data logic were a little better, it would screen out the doctor and lawyer positions sent to my inbox, but I suppose this technology still has a ways to mature. Or maybe they need to hire certified employees.
I want to discuss certifications. Particularly, I’m going to focus on Agile certification. Let me start by saying that there are a lot of competent training companies and trainers out there, though I’ve got a few bones to pick with them. I’ll get to that in a moment. I’ve attended some courses, read books and blogs, watched videos, been directly exposed, and witnessed Agile and its amalgamations and derivatives. This training is worthwhile.
For an organisation, it would be an advantage to ensure everyone is trained under a similar approach. This ensures that the people are all on the same page. If everyone has the same base of understanding, things should run more smoothly. People understand the same concepts and nomenclature the same way. They can all speak a common language. All of this is good. If a course or series of courses result in a certification, then this ensures that the attendee has met whatever minimum requirements there are.
As a shortcut, it makes sense to screen for persons with certification. But requiring certification, creates false positives and negatives. I am more interested in the false negatives, but I’ll point out the false positives too. Just because a person passes some certification process doesn’t mean they understand how to apply it. More on this later.
From my career as an educator, I know that if one passes a certification and doesn’t apply it in a year or two, the likelihood of retention is extremely low. A month later, it’s probably less than 20 per cent. Do the maths.
To put things into perspective, here are some metrics on learning and retention:
1. “After one hour, people retain less than half of the information presented.”
2. “After one day, people forget more than 70 percent of what was taught in training.”
3. “After six days, people forget 75 percent of the information in their training.”
My takeaway here is that a hiring manager still needs to screen for competency. It would be better to ask the candidate to assert that s/he is comfortable with Agile from the perspective of the role being filled.
As I’ve mentioned, my interest is with false negatives. How many people are familiar with the concepts and methodologies of Agile that aren’t certified? I’ll make it personal.
I’ve been engaged with Agile since 2003, having been first exposed in an XP project. And I’ve done some scrum, some scrum of scrum, and Kanban projects since then, as well as some blended Agile projects. I’ve been doing Agile. I’ve implemented and managed Agile teams in organisations. I don’t feel a credential adds anything—except for being able to check a box on a form. But that’s not my beef.
Here’s the crux of this segment: Except between 2003 and 2006, when I was working in a start-up dot-com, no organisation I have observed does Agile. I don’t care how many certifications you have if you don’t actually practice it. The way I see it, certified Joe or Amrita getting a position but not being allowed to employ the methodology they are certified to practice, doesn’t yield any advantages. In fact, it invites confusion.
Imagine being a licensed dentist. You’ve been trained to perform root canals. You understand the benefits of using Novocain and twilight sleep, but management has decided that this is too cumbersome, so you’ll have to dose your patients with a shot of whisky and have them bite on a stick instead. This is how far removed most organisations’ praxis seems to be from Agile orthodoxy. You may be certified, but you won’t be using any of these skills. But you do have to have the piece of paper.
And this is where I have the bone to pick with Agile instructors and coaches. They are in pop-psychology parlance, enablers. They tell the organisation that Agile is a loose framework. And it is. But as I’ve already discussed, it is not so flexible as to allow just anything.
I am saying that you can blend Pointillism and Cubism in a manner to represent both definitions, but Seurat, can’t paint La Grande and insist that it represents Cubism. That’s not how language works. Instructors and coaches need to say that organisations can feel free to take a different path that suits them. If the new approach produces better outcomes, then awesome. But it’s not an Agile approach producing those outcomes. If it produces worse outcomes, it’s not the fault of Agile. It’s the misimplementation.
My ex-wife is not great in the kitchen. But she enjoys baking and creating culinary goods. A chef or a good cook understands how and when a substitute works in a recipe. My ex—not-so-much. She’d decide to substitute honey for sugar because reasons, and she’d almost invariably ruin recipe after recipe. And then she’d blame the recipe.
This is how most organisations I’ve seen operate. I hear, ‘We’re just not getting the results we were expecting’. Or on the business side, they complain about not knowing what’s going on in IT. Given how Agile operates with Product Owners™®, the only way that statement can be true is if Agile has been misinstantiated.
In closing, I just want to part by saying that I am not opposed to credentials. I am not an anti-credentialist. But if you are going to insist on a credential, but not use the fundamentals behind the credential, why bother? And you are going to lose qualified candidates. In fact, you may lose candidates who can actually give you superior outcomes.