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.
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:
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.
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):
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
Marshall, R.W. (2012). So You Really Want to be an Agile Developer? [online] Think Different. Available at: /2012/05/22/so-you-really-want-to-be-an-agile-developer/ [Accessed 30 Dec. 2021].
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:
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
Cohane, R. (2017). Has the Software Crisis Passed? [online] Medium. Available at: https://medium.com/@ryancohane/has-the-software-crisis-passed-d45ce975a1e7.
Happy holidays, everyone!
“Life’s most urgent question is, ‘What are you doing for others?’”
~ Dr. Martin Luther King, Jr.
#AntimatterPrinciple
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.
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”.
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?
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.
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.
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”?
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
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.
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:
“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™️:
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.
Kleiner, A. (2003). Who Really Matters. Currency.
Superheroine Scrum Master
The more your Scrum Masters know about Scrum, the more of a handicap they are, both to their teams and to the wider organisation.
How often do you see coaching as a means for “fixing” others?
How much attending to folks’ needs have you been doing of late?
Without suggestion or recommendation, which pill would you choose, right now?
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 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.
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
The joy of fellowship comes from seeing everyone achieve more than anyone thought they were capable of.
Reposted from Dr. Tony Burns on LinkedIn
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.
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 🙂
Are managers scared silly of excellence, or just unable to recognise it?
NB. Quintessence (the book) is a cure for the latter.
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
A recent video (57 minutes) exploring the long-term experiences in Portsmouth City Council with the Vanguard Method. Golden.
Portsmouth City Council and the Vanguard Method: 15 years on
Also applies to software development (and other functions) within tech organisations. Can you see the parallels?
– Bob
Managers don’t know how to manage. But they have a pressing need to pretend they know. Especially to themselves. And they hate to hear how they personally might go about it.
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?
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?)
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.
Leanpub has made it easy to buy books and gift them directly to others. Here’s how to gift one or more books:
Quintessence: https://leanpub.com/quintessence
Memeology: https://leanpub.com/memeology
Hearts over Diamonds: https://leanpub.com/heartsoverdiamonds
3-book Organisational Psychotherapy series bundle: https://leanpub.com/b/organisationalpsychotherapybundle1
– Bob
Think Different