The issue of certification has been around forever. Every so often interest spikes again as people like Jonny Williams and Chris Stone reignite the debate (in LinkedIn). Software engineering in the 1980s aspired to be considered “Professional,” equivalent to the status given accountants (CPA), other Professional Engineers (PE), or lawyers. In the 1990s the big push among many organizations was to become certified at Capability Maturity Model (CMM) level 1-5 (although this was conferred on organizations not individuals). Discussions have continued to rage in the agile movement since. The issue has been polarizing. I think the discussions boil down to considering five key questions:
- Does certification work? The underlying purpose of the Agile Manifesto was to develop better software and improve workplaces for us all. Has certification helped?
- Do we give customers what they want? The contingent who oppose certification are somewhat violating the agile value of being customer driven. Are they telling customers “You can’t have certification even though you want it?”
- Does certification make money? The answer to this question is pretty obvious. It does. But does the amount of money spent and made on certification become a barrier to change?
- Does certification stagnate innovation? Do certifications lead eventually to bureaucracy? That happened to the CMM. While proponents touted it as a learning model, implementations became increasingly bureaucratic.
- Does certification convey an appropriate level of professionalism?
📋 The discussions about certification at Agile Project Leadership Network (an organization established in 2005 to promote and support Agile Project Management) board level epitomized the arguments about certification. The board was divided into 3 contingents: those who supported certification and were quite comfortable with existing certification models; those that generally opposed certification on the basis that agility was not inherently certifiable; and finally the group in the middle willing to consider certification but was not comfortable with what they called “certification 1.0.” The concern was that traditional certification models were based on validation of learning against a relatively static body of knowledge, yet that was at odds with the nature of agility. While the third category garnered a great deal of discussion, there seemed no way to administer such a certification at a reasonable cost.
The LinkedIn discussion got me to thinking about the word “certification.” For many/most of the agile certifications the word means you completed a course. PMI’s certifications go a little further in that you take an exam after completing preliminary requirements (experience for example). The PMI agile exam is 120 multiple choice questions and takes 3 hours. Some other agile certifications require an exam, but agile certifications remain primarily knowledge acquisition based..
Let’s look at what certification means in two other professions—financial accounting and civil engineering.
📠 Obtaining a Certified Public Accountant (CPA) certificate has preliminary requirements such as a bachelor’s degree, 150 hours of relevant course work, and 2-years of public accounting experience. The CPA exam takes 16 hours, includes 4 topics such as financial accounting and business law. The exam answers are written, not multiple choice, and the hardest part of the financial accounting practice section can be determining what the dang problem is first and then deciding on the solution (at least this was true years ago when I took the exam). About 50% of people pass the CPA exam. Most people consider it more difficult than the legal bar exam.
And what does the CPA get for all this time and mental anguish? She or he can now “certify” an organization’s financial statement as require by law. They are “accountable” to the public for accurate results.
In the early 1990s the Enron scandal resulted in bankruptcy for the $60 billion dollar firm and the dissolution of Arthur Andersen LLP, which had been one of the largest auditing and accounting companies in the world. Andersen “certified” Enron’s financial statements and paid a steep price for its failure.
🏢 For public buildings Civil Engineers must obtaining a professional engineering license conferred by the state (my undergraduate degree is in electrical engineering). The legislative intent of licensing is:
“It is illegal for a practicing engineer to jeopardize public safety in any way. This means that an engineer must hold herself or himself to the highest level of technical and moral conduct reasonable or suffer litigation if an engineering system fails causing harm to the public… . Breaches of engineering law are often sufficient grounds for enforcement measures, which may include the suspension or loss of license and financial penalties. They may also include imprisonment (Wikipedia).” I wouldn’t want to be the civil engineer who signed their name to the Miami suburb Surfside Condo drawings (it collapsed in 2021).
💻 Think about what legal certification would mean to software engineers. A “Professional Software Engineer (PSE)” would certify that their team’s product “Would not jeopardize public safety in any way.” How many Scrum or other Agile certifications would you need to affix your signature and be accountable to this degree?
So there is a distinction between attaining a certain level of knowledge and being accountable for applying that knowledge. But please don’t assume from this post that I’m advocating for a CPA or PE level of certification for software development–I’m not, not, not. But I do have some concern about the proliferation of agile “certifications” as they have become a fancy word for training. Knowledge acquisition is a wonderful outcome, but let’s not forget that other professions elevate titles such as CPA or Professional Engineer to the next level—the application of that knowledge and acceptance of accountability for results. As software engineers/developers we should strive to find new ways to demonstrate our knowledge, competency, and accountability to clients, customers, and the organizations we work for.
©2023 Jim Highsmith