By J. John Steele
I argued in a previous blog that the first of the twelve “Principles behind the Agile Manifesto” misses the mark in naming the highest priority of Agile practitioners. In truth, it doesn’t just miss the mark, it misses the target. As a refresher, the principle reads:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I contended that the principle expresses a false absolute. More importantly, I believe it advances a false allegiance. I don’t believe “satisfying the customer” should be the highest priority of people using Agile frameworks at all. Customer satisfaction certainly matters and it’s not unfair to say it’s a key business priority for any organization. But to call it a singularly transcendent one that surpasses every other goes too far. Whether Agile standards of care are used in the process is inconsequential in making that determination. There are far more important priorities development teams should recognize.
The first and second Theses of the Denver Method, which I introduced in that blog, offer just two examples of valid business objectives organizations might consider to be equally important to satisfying customers. But far more critical are the ethical and moral values a development team must be duty-bound to uphold. These ideals should soar far above any potential business goal or profit motive when a development team is forced to weigh its loyalties.
Imagine, for example, a situation where a team is asked to build an application that clearly doesn’t fit that team’s area of expertise or skillset. Should its top priority be attempting to ‘satisfy the customer through early and continuous delivery’ of a software solution when the developers know very little about that particular area and probably can’t build the app without major flaws? Or should the team lead just be honest and let the customer know the application requested is outside the team’s sandbox, perhaps suggesting another development group more qualified for the task?
As a more prescient example, consider the case of the infamous software-based Volkswagen “defeat device” which, between 2008 and 2015, illegally altered VW diesel engines to keep nitrogen oxide emissions within U.S. EPA limits whenever the software detected vehicles were being tested for emissions, but allowed the same vehicles to emit up to 40 times that limit under normal driving conditions. Ignoring, for now, the question of whether the developers who wrote and implemented the code were ordered to do so, they clearly created this ‘valuable software’ to ‘satisfy the customer.’ So, if the team members used ‘early and continuous delivery’ to create it, can we assume they should be allowed to plead “The First Principle of Agile” in their defense?
Yes, there was a touch of sarcasm there, I’ll admit. But the point remains a valid one. To say, “It’s not my fault – Agile made me do it!” would be a preposterous rebuttal for criminal behavior, and Agile certainly encourages no such dereliction. Yet, as we enter an age where software drives cars, controls weapon systems, monitors health conditions, powers devices that have the potential ability to spy on us in our homes, and even guides life-and-death surgeries; development teams have an ever-greater duty to exercise a standard of care that exceeds every business priority. What concerns me isn’t that Agile encourages unethical or negligent development practices – it doesn’t. What concerns me is that nothing in Agile’s values or principles actively tries to prevent them. Instead, it calls on Agile practitioners to “satisfy the customer” as the practitioner’s “highest priority.” Therein lies the false allegiance.
Let’s look at the VW case again, supposing this time that executives did indeed order the software engineers to create the defeat device, then threw those developers under the bus when the deceit was uncovered. From the facts that have come to light so far, this appears to be what happened – at least superficially. Even if the software engineers only followed their bosses’ orders, they broke both legal and moral codes of behavior by not refusing to comply with those orders. One might say in such a circumstance the executives were the real “criminal masterminds,” but the developers still chose to be their ignominious “minions,” however coerced that choice seemed to them at the time.
In April of 2017, James Liang became the first VW engineer to go to jail for his role in the emissions scandal after a U.S. judge sentenced him to 40 months in prison and a fine of $200,000 for conspiring to defraud the U.S., committing wire fraud, and violating the Clean Air Act. Speaking on Liang’s behalf, his lawyer said, “We’re not saying he didn’t commit a crime, but he’s a good and decent person. He blindly executed a crime because of a misguided loyalty to his employer.” If that is indeed how Mr. Liang saw his actions, his “loyalty” was “blind” indeed: Blind to the jeopardy it placed on his own career, life and family; blind to the livelihoods of hundreds of VW employees who were unaware of the deceit but lost their jobs because of it; and blind to the good faith it destroyed for millions of VW customers around the world. He clearly didn’t see where his real loyalties belonged.
As software becomes an integral part of nearly every aspect of human life; and as that software becomes incomprehensibly complex; we find ourselves racing toward a crisis of loyalty, responsibility and integrity unlike anything the software development industry has ever faced. Imagine, for instance, what happens when an executive insists that a team cut costs “or else.” Now suppose that the developers, already stripped to the bone, determine the only place left to cut is testing. Next, picture what happens when those cuts cause the team to miss a bug in their autonomous driving application, and that bug costs human lives before it is caught and fixed. Finally, consider the developers’ plight when executives, trying to deflect personal blame, accuse the team of criminal negligence for irresponsibly cutting corners.
We must begin thinking about conundrums like these. They are coming. Soon.
I don’t pretend to think I can prevent every crisis of conscience with a few words posted on a blog page. But I do think there are ways to help the development team understand its real priorities and make its decisions a little less arduous or complicated. The secret lies in understanding exactly where a team’s loyalties are. In the Denver Method, this is one of the Aegis’ most important duties.
Each Thesis is written to specifically address the Aegis. I have two reasons for this: (1) Because I first began writing the Theses as a guide for training new Aegises, and (2), because that role personifies the very heart of the Denver Method’s essence. The competence and dedication the Aegis displays in fulfilling that role and manifesting the Theses determines the caliber and integrity of his or her team. This is especially true of the third and fourth Theses, as they embody the ethos and marrow of the Denver Method itself.
My developers and Aegises like to call Thesis Three the “Aegis’ Professional Code of Conduct.” Its substance, however, applies to anyone in a leadership position. Developers and other employees in an organization should find beneficial guidance in Thesis Three as well.
To further define and clarify the Thesis, I’ve written some Corollaries. The first relates to understanding the deeper meaning of the first sentence. Knowing precisely what is right can sometimes be tricky, but Rotary’s well-known “Four Way Test” offers an unlimited free supply of “virtual litmus paper.” Herbert J. Taylor wrote these four simple questions when he worked at Club Aluminum Products in the 1930’s, at a time when the company faced looming bankruptcy. Taylor posted the maxim for other employees to see, hoping to change the company’s ethical climate and thus its fortune. Years later, Taylor became an international director of Rotary and offered the organization his Four Way Test, which it readily adopted. Today, Rotary continues to promote the axiom as the standard by which all behavior should be measured.
THESIS THREE, Corollary 1: It is sometimes difficult to know with conviction what path is the right one, but if it can’t pass Rotary’s time-honored standard of behavior keep looking, because you haven’t found it yet.
“The Four Way Test”
Is it the truth?
Is it fair to all concerned?
Will it build goodwill and better friendships?
Will it be beneficial to all concerned?
NOTE: Okay… I need to admit I’m not being truly honest here; at least syntactically. My exhortation to “keep looking” is meant to ensure the Aegis goes outside the box as far as possible before settling for a lesser path; because any course of action that can’t pass every stipulation of the Four Way Test remains, at the end of the day, a lesser path. Thus, when an Aegis has explored every imaginable alternative with the test in mind and fearlessly resolves that no path is better, then I will trust he or she has found the best solution there is.
I firmly believe that meeting the first two challenges is never impossible; therefore, any course followed must, at the very least, be the truth and fair to all concerned. On rare occasions, however, no practical solution exists that benefits everyone or builds “goodwill and better friendships.” While win/win answers should always be the goal, sometimes the only viable choice – even though it’s as fair as humanly possible – leaves someone feeling they’ve lost. When that happens, the Aegis must look to the Thesis’ hierarchy of loyalties to know whose interests he or she must try to protect.
Notice that the Aegis’ boss, per se, is not one of those interests. This is deliberate. Nothing in the Thesis addresses the organization’s hierarchy of command, because if leadership in general (and the Aegis’ superiors specifically) always uphold genuine loyalty to the company, the community, the customer, and the law – and always have the Aegis’ back regarding the welfare of the team – there will never be a conflict between them. If a leader or group of leaders’ loyalties diverge from the Code of Conduct, however, the Aegis must stand by the Code. There is a Corollary for that, too.
THESIS THREE, Corollary 2: While an Aegis should always be a good corporate citizen and respect his or her leadership, it remains a critical part of the Aegis’ duty to his or her team and to the reputation of the company to know when the instructions of a superior must be resisted in a fair and honorable way. When a directive or policy will result in loss of well-being or livelihood to those the Aegis serves as guardian to, or when it is illegal or immoral, the Aegis has a duty to speak up and take necessary steps to prevent its implementation.
The next Corollary my Aegises and developers jokingly call “The Aegis’ Conduct of Code.” It points out that, as part of honoring the priorities in Thesis Three, an Aegis should realize the software his or her team creates can affect the lives and welfare of countless others.
THESIS THREE, Corollary 3: It is the Aegis’ apodictic responsibility to ensure that every line of code published by the team serves the higher good of the customer, the user, and the community. The Aegis’ vigilance in this duty reflects on the team, the company and everything the Aegis stands for.
In the next blog, I will introduce Thesis Four, which is existentially linked with Thesis Three, defining the way in which the Denver Method creates a thriving culture of genuine engagement; one that is palpable, exciting, and magnetizing for highly creative people.