Forget everything else. THIS is the one Agile crisis I can’t stop worrying about.

Part 1 of 4: Introducing Thesis Four

By J. John Steele

As I’ve mentioned before, many of the Denver Method’s Theses reflect adamantly held values, rules, and maxims that guide my life – my Weltanshauung. A splendid example of this is Thesis Three, the Aegis’ “Code of Conduct,” which speaks to the need to put honesty, fairness, and honor above profit. But of all the convictions I hold, none goes deeper than the credence that every person is a human being and always deserves to be treated as one. I believe this is one of our highest callings as humans, and it diminishes our own humanity when we don’t rise to it. Naturally, the Denver Method contains an axiom based on this notion: Thesis Four.

When Thesis Four instructs the way a business is run, I have found it energizes people to be and give their best. This in turn fuels loyalty and success at every level of the enterprise. Consequently, its guidance sits at the apex of everything the Denver Method stands for. I deeply, passionately believe any conduct of business, however small, must revere and serve Humanity above any other aim because doing so furthers all other worthwhile pursuits.

At the risk of the firestorm of hyperbole I fully expect this to evoke, I formulated Thesis Four because I believe Agile falls arrantly short on making respectful treatment of developers a serious priority. Not one of the four values of the Agile Manifesto, nor the twelve principles supporting it, openly, explicitly and unequivocally demands respect and fairness toward developers (or anyone else, for that matter). I saw the absence of such a tenet in Agile as a shortcoming so grave that without one, I felt obliged to write my own.

Oh yes, I know what the manifesto’s first value says – by heart. Or, if you prefer, I can recite the fifth, eighth and/or eleventh of the “Principles behind the Agile Manifesto” (We’ll call them PBAM’s, for short). So, yes, the founders of Agile intended to add more humanity, respect, and human communication to the software development business, I’m convinced of that. But they didn’t succeed.

If you disagree, simply look at typical working conditions in many self-styled “Agile” organizations today. Any decently-sized random sampling will contain more than enough examples to show we still have a long, long way to go before developers are truly respected and valued. Prolonged hours with unpaid overtime, frequent war-room situations, overbearing management practices, and abbreviate workspaces are just some of the transgressions that ought to be hallmarks of shame to environments brandishing themselves as “Agile.” Nevertheless, they persist nearly two decades on, and neither the Agile Manifesto nor its twelve anointed Principles say anything that specifically extirpates, bans, or condemns such practices. That fact is deeply disappointing to me.

The Agile movement was begun by developers. Most had become managers, business owners, consultants or trainers by the time they went to Snowbird, Utah in 2001, but they all started out as coders. They got together – because of that common bond as developers – to address concerns important to coders. I sincerely believe Agile’s founders hoped for more than merely improving software development efficiency by encouraging the use of ‘lightweight’ development practices in place of ‘waterfall.’ I believe they also wanted to see software developers treated with more respect, trust, and dignity. The handful of Agile values and principles I mentioned earlier support that view to some extent, to wit:

  • AGILE MANIFESTO – FIRST VALUE: [We value] Individuals and interactions over processes and tools
  • PBAM 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • PBAM 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • PBAM 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Manifesto for Agile Software Development and Principles behind the Agile Manifesto

While these maxims clearly parade honorable intentions, I don’t believe they go far enough because they only speak to affectations of engagement-driven productivity; not its merit or purpose. By that, I mean they merely say teams should practice human interaction, sustainable work practices, and self-organizing teams; not why those habits are critical to producing quality software, nor how they do so1.

If you think that doesn’t matter – that it’s not important what the underlying reasons are so long as the processes are valid – let’s take a deeper look at our hypothetical random sampling from a few paragraphs ago. Countless teams and organizations fail to see the larger picture, and I’m not just talking about the obvious “cargo-cults” where ‘stand-ups’ are just meetings, ‘retrospectives’ are just management reviews, teams call themselves ‘self-organizing’ yet remain steeped in classic top-down Taylorism, and all decision-making originates from managers and leaders who lack listening skills. In these organizations, “Agile” is just waterfall with a different name. Nothing has really changed; software productivity flounders the way it always did and developers are no happier with their jobs than they would be in any other setting.

But there’s another “Agile mirage” that corrupts the true meaning of things like human interaction, sustainable practices, and self-organizing teams. In this aberration, business leaders ordain a transition to Agile because, as capitalists, they see Agile as a set of processes and procedures for creating software faster and cheaper. People don’t matter to these executives; speed, cost, and profits do. So technical practices do change, but only inasmuch as they result in enhanced productivity and agility. Teams are indeed more self-organizing, efficient and productive. Yet, somehow, developers remain just as overworked, tired, stressed and miserable as ever – sometimes even more so. Later in this series, we’ll refer to statistics from sources like Gallup and Deloitte that tell us conditions like these impact more than two-thirds of American employees today. Parsimony and indifference in leaders and managers who create such angst are symptomatic of what I’ve come to view as a burgeoning disease. I call it the “Toxic Chimera Pandemic,” and we’ll talk more about it in the next post.

Again, I know these conditions are not what Agile’s founders desired. I’m confident they hoped to see developers treated with more respect and dignity. They could never have foreseen where we are today, so this isn’t a criticism of their intentions. I’m simply saying that, in hindsight, the Agile canon lacks something critical – something I think it must have if it’s ever to fulfill the ideals its proponents aspire to. I’m talking about something more here than just values or principles that encourage the right behaviors; I’m referring to a rule stating emphatically and without equivocation that without trust, honor, dignity, and respect, NO AMOUNT of Agile methods, techniques or practices can truly be called “Agile.”

No uncompromising axiom of this kind exists in Agile now, and I frankly believe that’s why its advent hasn’t changed our workplaces more than it has. The practice of Agile is PERMITTED 2 to be indifferent to the human side of software engineering.

Don’t believe me? Consider this: Almost two decades after Snowbird, we see article after article telling us the latest thing that’s “wrong” with Agile. We hear executives saying Agile doesn’t work, or at least not in their company. We see blog after blog claiming this flavor of Agile is better than that flavor. We see new books every week telling us we need to try this technique or that one – we need to improve the way we deal with responsiveness to change, or stories, or estimates, or just about anything that doesn’t involve building engagement and treating developers the way they deserve to be treated.

We also coo and cluck over companies like Spotify, and chatter endlessly about its matrixed org chart or its motto of “Fail fast and fail often.” We often latch on to trivialities like these and say, “Aha! Maybe that’s the secret!” All the while, we completely overlook the fact that most of Spotify’s practices and methods evolved from things the company did to build engagement… to show developers they are valued, trusted and respected. We completely disregard the notion – or its relevance – that many of Spotify’s pioneering strategies originally came about because leadership listened to developers and let them try out new ideas.

Any organization that truly values its developers and understands engagement instinctively gives them the autonomy to choose for themselves how to work. But, for reasons I can’t explain, so many of us just can’t see that. Instead, we squander our time endlessly hunting for some process or rule that will let us perform the way such organizations do without giving up our precious command-and-control genotypes. I’m not saying companies shouldn’t look for better, faster, higher performing processes and methods; in fact, the Denver Method is replete with ideas that improve productivity and agility. All I’m saying is we need to put the humanity of our developers first and let that change generate its own amazing shift in engagement and productivity. Then we can assist developers in adopting new processes and techniques that take creativity, efficiency, and performance to the next level; something they will now be excited to do.

I can do nothing about what Agile does or doesn’t have in its canon, but – like anyone else – I am totally responsible for what’s in mine. When I began writing my Theses, I knew I had to make honor and decency to employees the cornerstone of my practices. I had to do everything I could to prevent even the mildest forms of employee mistreatment, not only because it’s wrong, but because it is bad business. It should never be permitted, condoned or overlooked. Somehow that had to come across as the very heart – the nexus – of what leading a team is all about.

The idea of Thesis Four has always been in my head and guided my approach to software development management. Still, it took me years to arrive at the phrasing below. I’ve tried endlessly to express the idea the way I truly mean it. Yet, even as I sit at my laptop writing this blog, I still worry if my words will be adequate, despite having reviewed and changed them countless times. I worry they won’t be taken seriously, or they’ll sound too trite, and I worry most of all they won’t be followed. But they simply must be followed, with spirit and heart, or it isn’t the Denver Method. I can countenance nothing less.

With that preface, I present the Denver Method’s fourth Thesis. As I said with Thesis Three, I write Theses from the perspective of training Aegises; the team leads who make the Denver Method work. Consequently, the language applies specifically to Aegises, but the idea applies equally to everyone who adopts the Denver Method as a framework.

My oh-so-clever wording didn’t fool you for a minute, did it? You recognized it right away; it’s just the Golden Rule, with the wording changed a little to make it sound like good business advice. Well, you’re absolutely right – except for two critical things:

  1. It’s not “just” the Golden Rule.
  2. It really is good business advice.

The Golden Rule, sometimes called The Law of Reciprocity, is neither new nor radical. The earliest known version dates to Ancient Egypt almost 4,000 years ago, shortly after the development of written language. We find adaptations in ancient Sanskrit, Tamil, Greek, Roman and Persian traditions. Some permutation of the Golden Rule appears in the Torah, the New Testament, the books of Tobit and Surach, the Quran, Sunan Abu Dawud, the Bhagavad Gita, and the Analects of Confucius. It plays a key, cornerstone role in every major religion or philosophy in human history. Since the dawn of civilization, prophets and philosophers of every creed have proclaimed one maxim above all: “Play nice, children.”

What is new, and in fact remarkably radical, is how its importance has impacted business over the last few years. Not decades – years. The rise of social media has revolutionized the reach of customers and employees in sharing their personal experiences with companies they do business with or work for. One single unhappy experience caught on video can go viral and do immense damage to a company’s trademark. The decision to treat customers and employees not just well – but better than they expected – can not only avoid this kind of disaster, it can potentially lead to positive memes that elevate the enterprise’s brand.

Because of this paradigm shift, a small but increasing number of executives have come to realize what research already tells us – that good behavior is good business. A company’s social capital is every bit as valuable as any other asset it holds because treating employees and customers with honor and respect leads to loyalty, and companies with the highest loyalty have the highest profits.

I know from experience that the Law of Reciprocity drives productivity, creativity and job performance to astounding levels. It has been a crucial pillar of my approach to business and of developing a thriving culture of genuine engagement. I have volumes of rock-solid research proving business leaders who don’t learn to embrace the Golden Rule are largely missing out on opportunities to supercharge the success of their companies. I’ll share much of that information as we proceed in this series.

But there’s a catch.

To be continued….

_______________________________________________________________

1 To be fair, PBAM 5 gets respectably close. Its compass bears true in saying managers need to give developers the support and environment they need, then trust them to get the job done. A core Denver Method principle called the “Three Giv’ems” is based on the same idea. Yet, as a principle, PBAM 5 feels more like a platitude than a commandment, and judging from how little it is quoted or practiced, I’d say that’s exactly how it’s commonly perceived: Not as a basic principle of Agile, but as a morsel of prosaic advice deserving of no more heed than an amiable nod. Most Agile enthusiasts don’t even know it’s there, much less grasp its real meaning. That’s the wording’s fault, though – not theirs. The two sentences sound disparate and unconnected; as if they offered separate pieces of advice, but they don’t. Yes, motivated individuals drive productivity and quality, but developers won’t be motivated unless they have the environment they need and the full support of their leadership. The first sentence of PBAM 5 is utterly pointless without the second for sustenance. Thus, PBAM 5 is probably the most well-meaning Agile principle and everything it says is true, if somewhat unclear. But it has the tone of a nice-sounding aphorism, lacking urgency or exigence, when what is needed is a brave clarion call with the power to catalyze change.
2 I’m going to be taken to task for this anyway, but to be unambiguously clear – and as I’ve already stated twice – I understand this wasn’t the intention of Agile’s creators, and I’m DEFINITELY NOT saying Agile sanctions or approves any form of malignity. I’m only saying such behavior is not clearly and deliberately forbidden, which means companies can get away with treating developers in ways that range from merely insensitive to downright merciless and still call themselves “Agile.” And that, unfortunately, is all the license the wrong kind of executive or manager needs.

Leave a Reply

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