Archive

Agile

All Agilists are Unethical

Are all Agilists unethical? This post argues that, absent objective evidence, it’s simply unethical for Agilists to claim that product and software development in the Agile fashion is reasonably effective.

The Ethics of Belief

London, April 11, 1876. There is uproar in the House. But this is not the House of Commons, rather the Grosvenor Hotel, and the furore is not political but – more unusually perhaps – philosophical.

William Kingdon Clifford – then professor of mathematics and mechanics at University College London – and the youngest ever person to be accepted into London’s elite Metaphysical Society, is presenting his inaugural paper. His audience includes the likes of Alfred Tennyson, William Gladstone, Thomas Huxley and the cream of London’s intelligentsia. The title of his paper is “The Ethics of Belief”.

Even before he finishes his reading, half the audience have stormed out of the room in protest. The remainder are on their feet, heartily engaged either in shouting him down or cheering him on.

What did the audience find so contentious about Clifford’s proposition? In his essay, he asserts that whatever someone chooses to believe cannot be exempt from the ethical judgement of others. A belief may leave someone open to a charge of unethical behaviour, depending on whether they have earned “the right to believe it”.

Ethics In the Development of Software-intensive Products and Services

London, December 2021. Waves of covid infections crash upon the bulwarks of the World’s healthcare systems. Ordinary people in all walks of life look upon the excesses of governments and businesses in a new, and distinctly unflattering light. What has happened to the traditional values of probity, social responsibility, ethics? Good questions indeed. In many quarters, scientists and specialists are regarded as pariahs.

Of course, recent events have only served to propel these issues into the public eye. In many avenues – and over many years – complacency, self-interest and greed seem to have overturned diligence, responsibility and probity. I believe we could all benefit from taking a long hard look at what we have become.

My own focus of concern is the arena of software and product development. I have seen literally hundreds of organisations in the business of developing software-intensive products and services in the course of my career. Most of these businesses have been wasting enormous amounts of time, money, effort, and human potential, through their unwittingly inefficient approaches to the practice of software development.

“…whatever someone chooses to believe cannot be exempt from the ethical judgement of others.”

And in most cases, little or nothing of any effective, practical value is done to address the situation, or if done, then not sustained.

In my experience this almost always comes about because those advising people nominally responsible for the situation – the senior executives of a company – honestly believe that Agile development approaches are effective (even though that rarely seems good enough).

So here’s the rub:

Do Agilists have the right to believe – and proselytise – that their approach(es) are as productive as possible, even if they have not gathered and considered the evidence?

Is such a belief, even when sincerely held, justifiable when these Agilists have acquired his or her belief…

“…not by honestly earning it in patient investigation but rather by stifling his doubts? And although in the end he may have felt so sure about it that he could not think otherwise, yet inasmuch as he had knowingly and willing worked himself into that frame of mind, he must be held responsible for it.”

But what if disaster (or merely loss of profit) does not befall the an Agile transformation or project? Would the Agilist be any less guilty?

“Not one jot. When any action is once done. it is right or wrong, forever; no accidental failure of its good or evil fruits can possibly alter that. The man would not have been innocent, he would only have been not found out. The question of right or wrong has to do with the origin of his belief, not the matter of it; not what it was, but how he got it; not whether it turned out to be true or false, but whether he had a right to believe on such evidence as was before him.”

Prior to Clifford, the established intelligentsia presumed that beliefs could never be examined in an ethical light. A gentleman could believe any damn thing he pleased.

Until recently, it seemed as if that presumption still held sway in many organisations. But today, William Clifford’s question comes back to haunt us. Yes, Agilists may truly believe that people working in an Agile way are being as productive as possible – but do they have any right to believe it?

About the Author

My name is Bob Marshall and I’ve been a specialist in the transformation of organisational performance – particularly in the software development and business technology arenas – for the past forty years and more.

I became interested in the field in the first place because of the egregious waste of time, money, effort and – above all – human potential that I saw time and again in organisations trying to develop software-intensive systems and products. So many people have such a poor time at work, frustrated and unfulfilled every day, in the majority of “Agile” (and other) organisations out there.

And the main reason for all this misery and waste? A simple belief that the Agile approach is beneficial. Or at least, not amenable to further improvement. Such a belief seems widespread, particularly amongst long-standing Agilists.

This distribution suggests that most software personnel have never seen software development at its best (or even, good). Their unfamiliarity with effective practice gives rise to a natural scepticism about whether things are really any better anywhere. Even people who have worked in the software industry for twenty or thirty years might never have seen software development practices anywhere near their best.

Most people will have spent their entire careers working in under-performing organisations. But some lucky few have seen for themselves that Quintessential organisations are indeed much more effective than the rest.

The Ethical and Moral Imperative

How do you feel about people wasting their time? I’m talking here specifically about the waste of effort, time and resources during the working day. There’s the obvious economic cost, of course. If employees are wasting time, by definition that’s costing their employer money. In software development, both the waste – and the cost – are often significant, but rarely visible.

However, I’m not going to dwell on this aspect in this article. Instead I want to talk about the morality of waste. Or rather, the immorality of it all.

We’ve already seen how Clifford caused uproar amongst his peers by suggesting that belief is subject to ethical scrutiny. And I’ve suggested that most Agilists’ belief that things are OK within their clients’ or employers’ software development shops fails that ethical test.

But I feel it goes further than that. Not only is Agilists’ naïve belief in the productivity of their clients’ or employers’ workforce unethical in itself, but the consequences – for individuals, the client organisations and wider society – are immoral too: waste, misery, stress, friction, conflict, disrespect, under-achievement, despondency, profligacy, demoralisation and frustration, to name but a few.

The Ethical Way Forward

So what to do? First, even before looking at the reality of the situation, on the ground, in their own organisations, I would invite responsible Agilists take a look at themselves – and their own motivations and culpability. Have they “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

Have Agilists “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

If the latter, then I suggest Agilists are ethically bound to go look for themselves at the reality of the situation in their clients’ or employers’ organisations. Some may feel uncomfortable doing this, lacking the necessary skills, access, or even simply the time. This need be no bar, however. Various specialist organisations exist to offer the necessary intervention, audit and review services. These organisations can conduct Clifford’s “patient investigations” and furnish the objective evidence.

Having the necessary evidence in mind, executives may then take pride that their beliefs pass the ethical test.

Of course, having real evidence to hand will likely show that the client has much scope for improvement, improvements which dwarf the proposed benefits of “going Agile”.

And finally, Agilists with a new-found or renewed ethical sentiment may begin to examine their peers’ beliefs in an ethical light, too. Thus, ethical business, and a more ethical society at large, grows stronger. Or is that too much to hope for?

In closing, I leave you with the words of Bertrand Russell:

“What is wanted is not the will to believe, but the wish to find out, which is its exact opposite.“

– Bob

Incompatible

Ever wondered why so many “Agile Adoptions” end up in the crapper?

Here’s the thing: Agile development, as described in the Agile Manifesto, and as aspired to by the gullible, is fundamentally and irredeemably incompatible with traditional management approaches (commonly known as command and control, Taylorism, Scientific Management, or some such).

This is neither a matter of opinion nor of experience (although I have many such experiences to relate), but of logic. I’ll not make the logical connections here, although I’m happy to do so if anyone is interested. I predict no one will be so interested.

This fundamental incompatibility is the reason we see so many failed Agile adoptions. Management is almost never going to swap out its existing mental models of how an organisation must be run, and so almost never will we see effective software development. (And almost no one seems in the slightest bit bothered).

BTW This incompatibility accounts for the approximately 80% failure rate of Agile adoptions we now know of.

The Gullible

The real kicker, though, is how Agile, as a local optimisation of the first order, will never deliver the benefits its proponents claim. Even those instances that have some impact on the traditional management worldview will only ever serve to enhance, and only marginally, the effectiveness of the development silo. And have little to no effect on the wider organisation. So much effort and risk of failure for so little gain.

The Alternative

I’m often asked “What’s the alternative, then, Bob?”. In a kind of despairing tone, as if it’s impossible to imagine a viable alternative at all.

I suggest at least one alternative is to look at the organisation as a (whole) system. And apply the precepts of flow to bring that system towards the Quintessential. If you need help with that, I’d be delighted to assist.

– Bob

Seen on Twitter this morning:

Alistair Cockburn@TotherAlistair · 14 Dec

“Agile Software Development has had its shortcomings exposed in the past two decades, revealing it as unfit to tackle business-level issues and to properly address user needs.”

:)) Opening sentence from a long research paper. no tomatoes, please. I’m in admiration 🙂

A Rough Ride

Changing one’s assumptions and beliefs is a rough ride. And the more one has vested in one’s existing assumptions and beliefs, the rougher the ride can be.

The human understanding when it has once adopted an opinion […] draws all things else to support and agree with it. And though there be a greater number and weight of instances to be found on the other side, yet these it either neglects and despises, or else by some distinction sets aside and rejects, in order that by this great and pernicious predetermination the authority of its former conclusions may remain inviolate.

– Francis Bacon

Losing one’s faith – for example, in the precepts and dogmas of Agile, or Management – doesn’t mean just changing our mind about factual matters – it can mean losing our identity, community, friends and family. It means disappointing a whole lot of people. It means looking those we respect in the eyes and confirming their worst fears. It means realising that what we have evangelised as a missionary, what we have taught our juniors and what we have argued against non-Agile colleagues was wrong. In sum, it is a terrifying thing. That is the impression we can garner from listening to accounts of people who have gone through this.

In other words, there are various incentives for Agilists to keep believing. Agilists who have gone through faith crises always say that they desperately wanted the dogma to be true but that they just could not bring themselves, ultimately, to continue believing it. 

Maybe the one thing missing from stories of realisation was the importance of finding some sort of stability or path on the other side of doubt. When we are opening up our minds to being changed, we are treading on new and perilous ground. It helps to know that others have trodden it before, and that what lies ahead is not as dangerous as all that.

Changing One’s Mind Is Painful

Even if most of the stories that we have heard of newly-converted ex-Agilists are success stories in some sense – and of course there is a selection effect here – they still show how utterly crowded faith crises can be with pain and heartbreak. We hear about careers falling apart and teams splitting up. We hear about people being disavowed by their employers, peers, or even partners. We hear about people being shunned by their friends. And we see how painful it is to realise that one has spent one’s whole life living in a kind of diorama.

The processes involved in changing one’s mind are unusually stark when it comes to Agilists changing their minds about their dogmas and faith. This is because various social, cultural and psychological factors incentivise members to keep believing that the dogma is true even as information readily available online makes a compelling argument that it isn’t. Some Agilists overcome these factors and reach the latter conclusion anyway. This is a difficult, disorienting and painful undertaking. But it is also somehow beautiful, and I suppose what I find so beautiful about it is that it is the scout, the doubter, the truth-seeker, an underdog here if there ever was one, who wins out despite it all.

– Bob

Beyond the Software Teams

One of the biggest constraints on the effectiveness of Agile software teams (the real ones, not the much more numerous pretend, faux-agile ones) is the assumption that the structures, assumptions and beliefs of the host organisation will not change. That it is, in fact,  impossible to get these to change, or to expect them to change.

An assumption which becomes a self-fulfilling prophecy.

“Whether you think you can, or you think you can’t – you’re right.”

~ Henry Ford

When this assumption goes unexamined and unchallenged, adopting Agile ways of working within the software teams – or in any part of the organisation, in isolation –  is a highway to hell.

– Bob

P.S. You might like to take a look at my latest book – Quintessence – to see how highly effective organisations approach and solve this challenge.

Further Reading

Marshall, R. W. (2021). Quintessence: An Acme for Highly effective Software Development Organisations. Falling Blossoms (LeanPub)

The Organisational Psychotherapy Standup

Daily stand-ups rapidly become tedious to the point of irrelevance. They rarely address core issues, participants generally preferring to gloss over issues so they can get back to “the real work”, e.g. coding, as soon as possible each morning.

Here’s how the Scrum Institute describes the Daily Scrum (Standup):

The Daily Scrum Meeting is a maximum of 15 minutes. These meetings take place every working day at the same time in the same place.

It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team.

Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.

All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience.

Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions.

Question #1: What activities have I performed since the last Daily Scrum Meeting?

Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan?

Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work?

Impediments

Q: What are the biggest impediments to a team’s progress?

A: The collective assumptions and beliefs of the organisation as a whole (and, marginally, of the team itself).

How often are these impediments discussed or even surfaced at the Daily Scrum/standup? Almost never. Or never.

How much do they impact the progress of the team? Lots. Really, lots.

So, for Question #3 (above), who’s going to raise the organisation’s – and team’s – collective assumptions and beliefs impeding or blocking the team’s progress? And who’s going to address these impediments/blockers on behalf of the team?

– Bob

Further Reading

Marshall, R. W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub)

Marshall, R. W. (2021). Memeology: Surfacing and Reflecting On The Organisation’s Collective Assumptions And Beliefs. Falling Blossoms (LeanPub)

Marshall, R. W. (2021). Quintessence: An Acme for Highly Effective Software Development Organisations. Falling Blossoms (LeanPub)

The Business Agility conference 2021 is on 2-5 November 2021 (online – 4 x half-day sessions). Pricey tickets – an inevitability given the target market (executives/company wallets), I guess. Too rich for me. Although I might have liked to have been invited to speak about e.g. the role of Organisational Psychotherapy and Memeology in Organisational and “Digital” Transformations.

Q: I wonder if Agile business people have any interest in humane business, effective business?

 

Not Ready To Hear

I was participating in a webinar / online conference session a week or two ago, hosted by the Essence For Agility folks (Essence is Ivar Jacobsen’s newish “method”). The title for the session was “The Future of Methods – not just Tomorrow but also the Day after Tomorrow”. The session was recorded. Take a look and see if you’re as frustrated / galled as I was.

Some “big names” were present, including Ivar himself, Tom Gilb, Robert Martin, Bertrand Mayer, and some 200 participants overall.

I say I was participating, but, apart from a few lines posted in the chat window (all ignored) I was much more of a spectator. And not a happy one.

At various points in the presentations and conversations I so wanted to contribute. But it was clear to me that the folks gathered were not at all ready to hear any contributions I might have made, and my message would most likely have fallen on deaf ears.

This is one of the things Thomas Kuhn talks about in his book “The Structure of Scientific Revolutions” (Kuhn, 1962). Aside: Kuhn basically observes that advances in any scientific fields are contingent on the incumbents retiring or dying. Don’t expect them to change their perspectives.

The prevailing frame of the conversation was “Software development methods are good, or if not exactly good, then either inevitable or a given. What will future methods look like?”

As you know, I have long suggested eschewing the whole idea of methods in favour of other paths and means to effectively attending to folks’ needs.

My Message

For the record, here’s my countervailing message:

“While a common way of working brings benefits, that’s only true when the folks doing the work have interpersonal relationships sufficiently well-developed that they can create and own the way their works works. The idea of methods is oppositional to this.”

– Bob

Further Reading

Kuhn, T.S. (1962). The Structure of Scientific Revolutions. University of Chicago Press.

Traders or Traitors

I’ve been listening to lots of audiobooks of late. Mostly narrated by folks with American accents. Current listening is Asimov’s Foundation Series (maybe for the fourth time around).

Aside: I find Zachary Quinto’s narrations of e.g. John Scalzi books just awesome.

trader
[ trey-der ]

noun

a person who trades; a merchant or businessperson.

traitor

noun

a person who betrays another, a cause, or any trust.

 

In an American accent, I find the words “trader” and “traitor” indistinguishable. Setting aside the question “are all traders traitors (to their customers)?” it got me to thinking “are all Agile traders traitors to their customers.” I’m pretty sure that – from the perspective of Agile Transformation outcomes – the answer is “yes”

How about you? Do you find that folks “delivering” Agile transformations are simple traders, or actually traitors to their customers and their customers’ cause?

– Bob