Certification

On the Agile testing mailing list there is currently a discussion on-going about the value of certifications and certificates. I have a strong opinion on it, and I would like to provide them on my blog. The basis has been the upcoming Certifiaction program for Agile testers. I have provided my critics to their courses as far as I could. I admire the efforts people put in such courses. That said, I don’t intend to offend anyone involved in certification programs, and will try to raise my objections as constructive as possible. But I also know that I will fail from time to time.

An anecdote

In September 2010 I took the Scrum Master certification from my colleague Stefan Roock. It was a two day course, I learned some new stuff, but most of the content I was already aware of. Afterwards I took the online questionnaire only to pass with zero errors in the questionnaire. Flawless.

My first gig as a Scrum Master was a failure in many circumstances. After the five months of being engaged at the client, the contract was ended. I held a retrospective with my colleagues, I discussed this topic as part of my peer group discussion, and learned some lessons from it. Heck, I also reflected on it together in a personal coaching session at PSL in May with Esther Derby and Jerry Weinberg. The Hardest Law had fully hit me:

Helping myself is even harder than helping others.

(The Secrets of Consulting, page 18)

Remarkably there was no question in the CSM questionnaire on what to do if you fail. No one taught me this lessons directly during the two day course. Yet I knew it was the right thing to learn from it, taking into account several opinions from colleagues. While you could say that “Inspect and Adapt” taught me this lesson, I still doubt the questionnaire that made me pass without any errors certified anything or could keep me from failing.

Shallow agreements

This is a common theme for certification programs I am aware of. I think the biggest issue with certification is that they lull people into a shallow agreement. “He’s got that CSM certificate, I got it too, so we agree on stuff.” “He’s got an ISTQB cert, so he knows all the terms about testing.” This sort of agreement is shallow. If you don’t believe me, and yet don’t believe my story from above, go to any two testers and ask for their definition of “integration testing” and check the results. Personally, I think this most ambiguous term in software testing should be banned completely. Heck, there should be a fee of 200,000 USD each time someone uses it.

Shallow agreements make our life sad and disappointed. For example I recently asked my father-in-law to get ourselves some wood for our oven. He got us wood for the oven, but I still have to cut it down to fit into our oven. Now I got several cubic metres of wood in my car port which I have to cut down, resulting in a lot of work to be done in order to get our home warm during the winter months. All of this was based on a shallow agreement. I had wood ready to fit in our oven in mind, while my father-in-law had wood as cheap as possible in mind. Probably a mismatch in underlying values maybe.

The same holds true for the contents of certification programs. While the contents are part of every training, you’re not guaranteed at all that all trainers agree to it. Yet, after leaving the course you might think that people have the same understanding as you have from the topic. Giving people a common understanding is a shallow agreement. You won’t know whether you reached the same understanding until actually challenging their understanding. There are some folks out there who did challenge some of the certification programs, and their represents, but without any success so far. It seems that shallow understanding is a pattern found in this field.

Needs

This leads the discussion for me to the actual necessity for certification programs. I am truly convinced that SJ-types (see Myers-Briggs Type Indicator for a grasp on the model) are the main driver for certification programs. By their preference these folks seek safety and reliance. They bring stability to the organization. Remarkably they fail to bring to necessary changes to the work environment if these undergo the challenge for change in the market.

The need for certification arises from people seeking safety and reliance. They seek to hire good testers, yet they base their safety and reliance upon a shallow agreement as a certification. Even worse, in case certification programs indeed provide a common ground for understanding, hiring people only by their certifications results in a confirmation bias strategy for hiring people. You could actually hire certified monkeys instead.

Yet, how should you oppose such needs as a claim for safety and reliance? The first step to overcome the certified monkey hiring fallacy is to realize that it’s uncertain what will happen once you hire anyone. This is a key lesson I learned from complexity thinking. If you’re in the position to hire someone, you should be able to take the responsibility to deal with the consequences. As I discussed earlier it’s uncertain whether the terms of the certification program reached a similar understanding in your colleagues as in the newly hired person. The human system dynamics which set in once the new hire reaches the team also provide an uncertain future. No piece of paper can change that. If you hired that person, you should provide the ground for their growth, and seek to exchange with your colleagues how to self-organize your team.

Containers

Finally, certification programs provide an artificial container for people. Certification not only splits up people into certified vs. not certified, but also provides barriers for communication and exchange. IF your department consists solely of people being certified, you won’t know what you miss from the knowledge of the uncertified people. In terms of complexity thinking these different groups of people are called containers. They shape the environment for people. In a self-organized system you need trandformational exchanges to overcome the difference between these two containers.

This brings me back to the discussion of exchanges of thoughts between certification people and non-certification people. Based on my personal history it seems that certification people get offended quickly by arguments against their programs. From a human standpoint this seems natural. Certification people seek to serve their need to make money form the program. That’s why they put a whole lot of effort into creating the program. Yet, this makes them blind to criticism from other areas. Human nature tends to neglect some critics when it comes to serving necessary needs in their value system.

At face value, this makes transformational exchanges more challenging. So, we got a catch-22. In order to get along with good certification programs, we need exchange between non-certification people and certification people. One of the differences between these folks is a different value system as well as a difference in the needs they’re trying to serve with their decisions. So, an exchange won’t happen whereby certification programs will become worse as the craft continues to advance.

Conclusion

There are a bunch of reasons for and against certifications. I provided some of my thoughts, yet I still know that these are my personal opinions. Yet I also know that there are exceptions, and I have met many people involved in providing certification courses who actually do a fantastic job. My personal preferences call for independence to the degree that I neglect any authorities. As James Lyndsay remarked in the tagging on entaggle healthily so. My only hope is to get certification and non-certification people together for an exchange – but I doubt this will happen based upon the reasons described above.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • LinkedIn
  • Google Bookmarks

One thought on “Certification”

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>