Monthly Archives: December 2021

Build the Quintessential organisation and the talent will come. In fact, the talent will form a humungous queue down the street and around the block.

Not that having a queue of talent knocking at the door matters much – quintessential organisations don’t depend on talent for their awesome effectiveness.

The Quintessential Developer

In my recent book, “Quintessence” I write, of the Quintessential organisation, that “everybody does things differently”. By which I mean, every role in a quintessential organisation looks very different from its counterpart in more conventional organisations, even though the name of the role may be similar, or the same..

This post looks at the role of the developer, and how – in quintessential organisations – this role differs markedly from the role in more conventional organisations.

Here’s a contextualising excerpt from Chapter 2 of Quintessence:

Everybody Does Things Differently

The quintessential organisation invites everyone involved to surface and reflect on their individual and collective assumptions and beliefs about work and how work should work. Progress towards the quintessential depends on progress with respect to changing these assumptions and beliefs.

This is the foundational reason why we see so few quintessential organisations, and why making the transition to a quintessential organisation is so difficult, and so rarely achieved successfully.

Here’s a brief outline of roles that look very different from the quintessential perspective:

The Manager’s role looks very different. So different, in fact, that the term “manage” ceases to be relevant. Managers in a quintessential organisation have relinquished ideas of control, and embraced a role of enablement, resourcing and support.

The Developer’s role looks very different. So different, in fact, that “software” and “technology” cease to be relevant. Developers in a quintessential organisation have downplayed a focus on “hard” technical skills, such as coding, and embraced and learned social skills, including skilful dialogue, empathy, self-organisation and compassion.

The Tester’s role looks very different. So different, in fact, that “testing” a.k.a. “inspection” ceases to be relevant. Testers in a “quintessential organisation have have relinquished a focus on inspection skills, and embraced means of preventing defects, and ensuring that attending to the need of the Folks That Matter™️ is “baked in” to how the work works.

The Customer’s role looks very different. Customers of a quintessential organisation get to have conversations about their needs, and have those needs attended to, more often and with more clarity than customers of more traditional organisations.

Even though a rational explanation of these differences serves little purpose, and will convince no one, we’ll take a more detailed look into the rationale later in this book.

Quintessence presents my experiences from over forty years of leading, working in, and advising software development shops and companies. I invite you to find inspiration, motivation and connection from my journey. Quintessence presents an ideal approach to making money (and other things) via attending to folks’ needs

Note: I say an ideal, not the ideal. There may well be other ways of achieving the same ends.

The Quintessential Developer Role

Note: This section describes the role of developers in a quintessential organisation. That is, the adjective “quintessential” applies to the organisation within which developers work, rather than the developers themselves.

In a quintessential organisation, developers pay much less attention to “technical” competencies such as coding, and much more attention to identifying the Folks That Matter™️, and understanding their (evolving) needs (cf. the Needsscape).

Developers in a quintessential organisation (being self-organising, self-managing and self-directing) focus on understanding what needs to be done (and for whom), compared to developers in conventional (poorly effective) organisations.

Necessary developer skills, in order of significance (most significant first): 

  • Dialogue skills – for conversations with the Folks That Matter™️ about their needs, and identifying other folks that may also matter.
  • Empathy – for establishing and maintaining humane relationships with all the Folks That Matter™️. Assuming, of course, that the organisation permits developers to actually talk with e.g. customers. A fairly rare scenario, to be sure.
  • Self-organisation – absent middle managers, project managers, etc., organising the work and then assigning work items to individual developers (and teams), developers in quintessential organisations have the freedom to to organise the work, and their assignments, themselves. This can range in scope from a single work item of a few hours, all the way through to new product features and indeed whole new products.
  • Risk Management – cultivating awareness of risks, their likely impact, and identifying and implementing active mitigations.
  • Opportunity Management – one step further than risk management.
  • System thinking – for reflecting on how the work works, with a view to continuous improvement.
  • Quality – building quality into the way the works works (as contrasted with hand-offs to e.g. testers and other QC personnel).
  • Researching and Learning – to discover and apply new ideas and techniques, both regarding how the work works and new technical skills/tools..
  • Investigating solutions – especially #NoSoftware solutions. 
  • Technical skills – including various implementation technologies, such as human systems (solutions staffed by human beings), paper prototypes and implementations, and, in extremis, writing software (a.k.a. programming, coding).

To recap:

Working/playing for/with a quintessential organisation is a fabulous experience (both literally and metaphorically). But the developer role is awesomely different from the conventional developer role. Can you grok it?

– Bob

Further Reading

Marshall, R.W. (2012). So You Really Want to be an Agile Developer? [online] Think Different. Available at: [Accessed 30 Dec. 2021].

Crisis or Not?

So many needs going untended…

In my posts I occasionally mention the Software Crisis. The authors of that Wikipedia entry seem to intimate that the Software Crisis is a thing of the past. And some of those who have heard of the term seem to share that view.

Personally, I see the Software Crisis as being as profound now as it ever was. Maybe even more profound, given the impact software has on our lives and societies – and the number of folks now working in the software industries, as well as the number suffering from the fruits(?!) of they labours.

Here’s that Wikipedia entry’s list of manifestations of the software crisis:

To which above list I’d add some more manifestations I see almost everywhere, daily:

  • Confusion over who matters (Cf. Cost of Focus).
  • Attending to the needs of the Folks That Matter solely via software solutions (a.k.a. “Working software”).
  • Fear of, and/or disinterest in, improving the way the work works.
  • Delusions as to the real reasons “successful” software development is actually successful.
  • Absence of dialogue as to the assumptions and beliefs governing effectiveness of various approaches to software development.
  • Blindness to the role of (organisational) culture in effective software development.

In short, I posit that the Software Crisis remains a chronic crisis, whose scope and impact continues to grow.

And from the #NoSoftware perspective, maybe the very term “Software Crisis” is just a mask for the broader “Needs Crisis” being suffered by humanity as a whole?

– Bob

Further Reading

Cohane, R. (2017). Has the Software Crisis Passed? [online] Medium. Available at:


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

Quintessence: Who Matters?

A sample chapter excerpted from my new book “Quintessence“ – book available now on Leanpub (free sample also available).

Note: Each of the eighty-odd chapters in Part II of the book takes a specific meme, and describes the collective beliefs and assumptions that quintessential organisations hold in regard to the meme. By taking all the memes in toto, we can understand the way quintessential software development organisations see the world of work – and what makes them so effective. This particular sample meme is about who matters.

Chapter 15. Who Matters


Quintessential organisations regard the needs of their customers, staff, managers, investors, etc. as central to the way the work works. Collectively, these folks are sometimes called The Folks That Matter™️. These organisations invest much effort in:

  • Identifying the various constituencies and the people who belongs to these constituencies.
  • Tracking the set of constituencies, and the changing membership of these constituencies, over time. 

“Understand stakeholder symmetry: Find the appropriate balance of competing claims by various groups of stakeholders.”

~ Warren G. Bennis

The quintessential organisation exhibits the following (collective) attitudes and feelings towards the Folks That Matter™️:

  • A keen urge to understand and track the needs of all the Folks That Matter™️.
  • Inviting folks to come up with explicit policies for defining and tracking membership of the set of all Folks That Matter™️.
  • Practices to both discover and attend to these needs.
  • Defining organisational success in terms of needs met.

Quintessential organisations recognise the major costs and other risks arising from missing out key members from the set of all Folks That Matter™️. These risks receive their continuous scrutiny – both in terms of accurately identifying members and in terms of ensuring these members’ needs are attended to, and ultimately, met. All work of the organisation is geared towards meeting the needs of the Folks That Matter™️. Maximising the amount of work NOT done is achieved by cautious (risk-aware) exclusion of insignificant groups and individuals from the set of the Folks that Matter™️, whilst striving to drive towards zero the instances of omission of significant groups and individuals from the set of the Folks that Matter™️.


Quintessential organisations recognise the distinction between stakeholders and The Folks That Matter™️. The needs of some stakeholders sometimes don’t much matter, and some of The Folks That Matter™️ aren’t actually seen as stakeholders (employees, for example).  Given these distinctions, choosing different terms helps communication and, more significantly perhaps, improves Cost of Focus.

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.


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

Reposted from Dr. Tony Burns on LinkedIn

TOYOTA ( Deming ) vs FORD ( Six Sigma )

Toyota is widely regarded as the pinnacle of quality, while Ford is left in their wake. Last year (2020), Toyota made a gross profit of USD 45,242M. Ford trailed behind somewhat with a USD 14,392M gross profit.

Despite Ford’s 34 year head start on Toyota, the latter is now three times the size of Ford and makes twice as many vehicles.

Ford’s Six Sigma program focuses on cost savings at the expense of Quality. The result is a collapse of both Quality and profitability.

Toyota focuses on Quality. Their great profitability is a consequence of their great Quality.

The Japanese learned Quality from Deming in the 50’s. The classic Ford transmission study showed that Ford was aware in the 70’s that their focus on the specification and defects, produced inferior product.  Ford knew the Japanese focus on the process and reducing variation, produced superior Quality.

Ford was rescued from disaster in 1982 by Professor Deming. Between 1979 and 1982, Ford had incurred $3 billion in losses. Deming helped return Ford to profitability in just 4 years. Sadly, Professor Deming’s contribution was forgotten. If Ford had continued with Professor Deming’s methods, they may have pulled ahead of Toyota.

Instead, in 1999 Ford bought Mikel Harry’s Six Sigma Snake Oil and went back to counting defects.

If Ford had bothered to investigate, they would have discovered that Harry’s hype was laughably based on the height of a stack of discs! It was blatant fraud from the outset. Like many other companies, it cost Ford dearly.

Ford had plenty of defects upon which to focus. An 8 year study of Ford’s 3,277 “successful” DMAIC projects showed an average of 220,296 dpm AFTER “improvement”. Yes, that’s worse than 1 in 5, with a total of 722,000,000 defects AFTER improvement.

By contrast, Toyota has used Professor Deming’s methods since the 1950’s:
“There is not a day I don’t think about what Dr. Deming meant to us. Deming is the core of our management.”
– Shoichiro Toyoda, Chairman and director of Toyota

Rather than spending months in “rudderless” DMAIC projects, as Bhote described them, and having pseudo “experts” with coloured belts telling workers how to suck eggs, Toyota respects and engages workers in Quality.  Front line, Quality Circles improvement teams, build in Quality.  By keeping it simple and focusing on Quality fundamentals, Quality Circle teams at Toyota have achieved over 2,000,000 process improvements. For example, one such improvement saved 15 employees; reduced the possibility of incidental damage to piston rings; and saved Toyota hundreds of thousands of dollars.

The message is clear. Avoid fads and farce like Six Sigma. Stick to Quality from the giants: Professor Lewis; Dr Shewhart; Professor Deming; Dr Wheeler.

“Dr Deming’s now famous ‘14 points of management’ when followed, appear to move organizations towards prosperity” – Mr Bill Smith

The software crisis will NEVER be over unless and until senior management comes to understand software development, and what makes it highly effective (in those extremely rare cases where it IS highly effective).

What will enable that understanding? Not the promotion into senior positions of folks with front-line experience (most have no experience of effective practices).

Coaching/education might do it – when the senior folks seek it out and engage with it themselves.

I believe exemplars can help (which is one of the reasons I wrote Quintessence).

The most promising way forward is normative learning, especially when guided by capable facilitators. How many senior folks are ever likely to go to the gemba and see what’s REALLY effective?

Alternative: Dispense with management entirely. Also highly unlikely, but beginning to gain some traction as an idea. Cf Reinvention Organizations (Laloux 2014), etc.. This approach doesn’t actually address the issue of folks understanding what effective software development looks like, though.

Further Reading

Laloux, F. (2014). Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness. Nelson Parker.

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 🙂

The Unemployables

There’s a saying in recruitment that the best jobs are never advertised.

There’s another idea, not quite a saying as yet, that the best candidates are unemployable. Allow me to explain. 

Most vacancies as advertised are shaped to fit the mediocre candidate. Any candidate with outstanding skills, experience, capabilities and insight is such a poor match for the position as advertised – with job description, education, certification and experience requirements, and all – they’ll never get past the first filters / gatekeepers (people with no understanding of what it really takes to excel in the job).

The outstandingly capable candidates are thus, for all intents and purposes, practically unemployable.

This leads to my regular refrain – the recruitment / hiring market is irredeemably broken.

Irredeemably broken? Yup. At least until those who unknowingly suffer the consequences of their organisations’ hiring mediocre candidates (CxOs, particularly) go to the gemba and begin to see what’s ACTUALLY happening in their name.

– Bob

Golden Insights From the Gemba

A recent video (57 minutes) exploring the long-term experiences in Portsmouth City Council with the Vanguard Method. Golden.

Also applies to software development (and other functions) within tech organisations. Can you see the parallels?

– Bob


Gifting LeanPub Books

Christmas is the season for giving. Maybe you know of someone who would appreciate one of my Organisational Psychotherapy books as a gift this Christmas? Or maybe all three in the series?

Why Give an Organisational Psychotherapy book? 

I guess the most likely recipient might be your boss or manager, or maybe a colleague or friend at work. You might gift a book to them as a quiet hint that things could be better, or perhaps you know they’re already looking for fresh ideas to make things better in the organisation. And if they do pick up on some of the many fresh ideas in my books, then maybe “better” might mean better for you and your teammates, too. 

Also, gifting an Organisational Psychotherapy book might serve to signal your enthusiasm for seeing the organisation improve. (Yes, I know, unlikely for most employees these days, but maybe you’re that special one?)

Which Book Might I Gift?

I guess it depends on your idea of what the giftee might best need:

If they might need ideas on accelerating the pace of change in their organisation, especially the pace of culture change, then Hearts over Diamonds would be a good choice.

If they most need a catalyst for getting change started, via e.g. surfacing and reflecting on the organisation’s collective assumptions and beliefs, then Memeology‘s the thing.

And if their most pressing need is a blueprint – or map – of what a highly effective (software) development organisation looks like and works like, then I’d suggest Quintessence.

Seven Steps to Gifting a Leanpub book

Leanpub has made it easy to buy books and gift them directly to others. Here’s how to gift one or more books:

  1. Sign in to your existing Leanpub account at or create a new Leanpub account if you don’t yet have one.
  2. Find a book you’d like to gift and then “Add a book to your shopping cart” by clicking the blue “Add Ebook to Cart” button.
  3. In your shopping cart, next to each book you want to give as a gift, find the “Edit” button.
  4. Click the Edit button and then tick the box next to “This purchase is a gift”.
  5. Enter the recipient’s email address and an optional note to go along with the gift, and then click the blue “Update” button.
  6. Repeat steps 2 through 5 for each further book you wish to gift. 
  7. When you complete the purchase, the recipient(s) will receive an email with download links for each of the books.

Links to my Organisational Psychotherapy books on Leanpub



Hearts over Diamonds:

3-book Organisational Psychotherapy series bundle:

And A Merry Christmas to You And Your Giftees!

– Bob

%d bloggers like this: