Archive

Monthly Archives: March 2022

Why Quintessence?

I suspect there are some folks who skip right over Quintessence because it’s not clear why I created the idea (and wrote the book). Just in case you’re one of those folks, here’s a post especially for you. ❤️

Why The Name?

Quintessence is a noun meaning “the most perfect or typical example”. Incidentally, it also means “the fifth and highest element in ancient and medieval philosophy that permeates all nature and is the substance composing the celestial bodies”. It can also mean “the pure and concentrated essence of a substance”.

So I use the name, in context, to indicate the epitome, acme or “very best” of ways in which to deliver software. Aside: I don’t claim to have a monopoly on this understanding. Nor even to fully understand “the best of ways”. Rather, I offer Quintessence as a means for motivated organisations to find their own path to their own manifestation of “Quintessence”.

Why The Idea?

It’s been my life’s work to understand software delivery, and share what I’ve learned with others. This in the hope that fewer people will waste their potential as human beings working in ways that are relatively ineffective and joyless.

Specifically, Quintessence deliberately chooses to avoid instructing people in how to approach software delivery. It’s neither a method, nor a process. Aside: Cognitive science invites us to consider the dysfunctions inherent in people following instructions and advice, in the creation of which they did not directly participate.

So What is Quintessence (the book, the approach)?

For me, it’s a collection of principles seen to be present in highly effective organisations. Principles guiding and shaping the way in which these organisations approach software delivery (amongst other things). And principles guiding and shaping product delivery – that is, the delivery of new product lines into the market – more broadly, btw.

My recent book “Quintessence” (Marshall 2021) contains some seventy different principles, each illuminating just one facet of the whole kaleidoscopic picture that is software delivery within organisations..

I choose to regard “Quintessence” (the book) as a map or blueprint of the highly effective software delivery organisation, expressed as guiding principles, couched as specific assumptions and beliefs. Aside: I’d be amongst the first to admit that very few such organisations exist today.

Why Does Quintessence Upgrade Agile?

I’ve written recently about Quintessence as a long-overdue root-and-branch replacement for Agile.

Agile is now over twenty years old, and for those that have been paying attention, it’s shortcomings have become ever more obvious, and it’s failure rate ever more disheartening.

Leveraging our learnings – more than 27 years of study and learnings, in my case – we can do so much better.

Quintessence is one articulation of what “better” looks like. And indeed what “best that we can currently conceive” looks like.

It’s neither prescriptive, didactic, nor a description of a “future state”. As “the best we can conceive”, Quintessence invites us to embark on a lifelong journey of learning and discovery. Not implement a waystation or fixed state.

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence [Accessed 16 Mar. 2022].

Quintessence – The Long Overdue Upgrade to Agile

We’ve laboured under the Agile yoke for more than twenty years now. As well as its other failings, Agile has choked off all innovation in the way software is developed.

We’re long overdue an upgrade, and yet there seems no game-changing innovations in sight. Might we conclude that decision-makers are content that current means are good enough to meet their needs? That breakthrough capabilities are of no interest? Or that no new breakthroughs are even possible?

It sure seems like it to me. And yet I continue to propose new, tried and tested, ground-breaking ideas. For those few who are not content to luxuriate in the prevailing status quo. Ideas like Flowchain, Prod•gnosis, the Antimatter Principle, Organisational Psychotherapy, and most recently, Quintessence.

Quintessence is that long overdue upgrade to Agile. Not a downgrade like, for example, the everything-and-the-kitchen-sink abortion that is SAFe.

Nor even a next-generation Agile, which will inevitably include all the shortcomings of the existing Agile approach(es).

Radical Departure

Quintessence is the radical departure from Agile norms, based as it is on people-oriented technologies such as sociology, group dynamics, psychiatry, psychology, psychotherapy, anthropology, cognitive science and modern neuroscience. Technologies conspicuous by their absence from businesses everywhere.

If logic had anything to do with it, thousands of businesses would be working in the Quintessential way now. But of course logic gets nary a look-in. We human beings are creatures of habit, emotion and bias. Our inner chimps hold sway over the human part of our brain most all of the time.

I guess you’ll dismiss this post much like you’ve dimissed all my other posts on e.g. Quintessence. C’est la vie. That’s monkeys for you.

Further Reading

Peters, S. (2016). The Chimp Paradox. Vermilion, An Imprint Of Ebury Publishing.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).Available at: https://leanpub.com/quintessence [Accessed 11 Mar. 2022].

If Putin Ran A Software Development Business

Or a tech business in which software development was a core capability – much like military forces are a core capability for any nation, including Russia.

If Putin ran a business where software development was a core capability, he’d:

  • Ask for estimates and rail against his project managers and middle-managers when those estimates proved unreliable.
  • Wonder why new features were stuck in a long queue of undelivered features.
  • Not notice that developers were so demoralised that they were just going through the motions, not caring a hoot about requirements or deliverables or even customers’ need.
  • Ask regularly and bitterly “why can’t they (developers) just do as they’re told?”.
  • Have little clue about the state of his tools and hardware, the skills – or lack of them – of his developers.
  • Apply huge resources to bludgeon through problems and delays, only to find that doesn’t work.
  • Discount the importance of morale and motivation in his employees.
  • Be secretly embarrassed about the quality and accuracy of his employees’ work.
  • Not understand the importance of learning, skills development, training and senior staff.
  • Underestimate the difficulties inherent in all software development endeavours.
  • Blame competitors and market conditions for his people’s failures.
  • Belatedly hire external contractors in the naïve and forlorn hope that they might accelerate progress.

Maybe you know of some other CEOs that make the same choices?

Yayy for Ukraine!

– Bob

Further Reading

Marshall, R. W. (2013). Product Aikido. [online] Available at: /wp-content/uploads/2013/04/productaikido041016.pdf

I encounter many senior and middle managers who believe that their software teams are poor at estimating, and seek to improve estimation accuracy and etc.

In most cases, the problem is NOT poor estimation skills or techniques. Rather, the problem is poor due-date performance (how often things are delivered on time).

As the world of #NoEstimates shows, delivering on time has little to do with estimation competence.

If you’d like to discuss some things you CAN do to improve due date performance (delivering on time more reliably) please do get in touch.

So, you need to see improvements in your company’s approach to software development?

Improvements such as:

  • Quicker development and delivery.
  • More reliable due date performance and confidence in schedules.
  • Reduced costs.
  • Improved quality.
  • More responsiveness to changing business conditions.
  • Increasing hiring and retention of the best people.
  • Etc..

And you want to do all that without shifting your culture?

Good luck with that!

Culture Shifting

For the past twenty years my work has been focussed on helping tech organisations shift their culture towards something more aligned to their aspirations and objectives. I have found that few indeed are the tech organisations that understand the role of culture, and its importance to their results.

The Role of Culture

Many business leaders over the years have emphasised the primacy of culture. Here’s a few:

The only thing of real importance that leaders do is to create and manage culture.

~ Edgar Schein

The thing I have learned at IBM is that culture is everything. It took me to age fifty-five to figure that out.

~ Lou Gerstner, CEO, IBM

If you get the culture right, most of the other stuff will just take care of itself.

~ Tony Hsieh, CEo, Zappos.com

What is Culture?

Culture is the collective programming of the mind which distinguishes the members of one group from another.

~ Geert Hofstede

According to Ed Schein, culture is a shared set of basic assumptions and beliefs:

Culture is the deeper level of basic assumptions and beliefs that are shared by members of an organisation, that operate unconsciously and define in a basic ‘taken for granted’ fashion an organisation’s view of its self and its environment… 

It’s a pattern of shared basic assumptions invented, discovered, or developed by a given group. 

~ Edgar Schein

The Organisational Psychotherapy Viewpoint

Organisation Psychotherapy asserts that culture is no more, and no less, than a read-only manifestation of an organisation’s collective psyche – of its collective assumptions and beliefs. Read-only because culture cannot be manipulated directed, but only via changes to those underlying collective assumptions and beliefs. (Marshall 2021).

Organisational Psychotherapy provides the context, the means and the tools to address changing such collective assumptions and beliefs.

The Culture In Your Organisation Today

Here’s a few questions you might like to bring up next time your peers discuss organisational culture:

  1. What does the term “organisational culture” mean to the folks in your organisation? 
  2. Does everyone share the same meaning, or are folks “all over the map”? 
  3. What impact does your organisation’s culture today have on your ability to achieve your purpose, your goals?
  4. How might you describe your organisation’ culture, as it is, right now?
  5. If you decide you need to effect some changes to your culture, how might you go about doing that? 
  6. To what extent are your senior folks and decision-makers agreed on the relative importance or significance of organisational culture? And the rest of the folks in the organisation? 
  7. What’s the impact of culture on financial performance (your bottom line)? 
  8. What’s the interplay between culture and the way the work works? 
  9. What’s the interplay between culture and the structure of the organisation? 

– Bob

Further Reading

Schein, E.H. (2016). Organizational Culture and Leadership. John Wiley & Sons. 

Hofstede, G.H. (1991). Cultures and Organizations Software of the Mind. Mcgraw-Hill. 

Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms. Available at: https://leanpub.com/memeology/ [Accessed 11 Feb. 2022].

My favourite quote this week:

What distinguishes exemplary boards is that they are robust, effective social systems … The highest performing companies have extremely contentious boards that regard dissent as an obligation and that treat no subject as undiscussable.

Perhaps the most important…is the capacity to challenge one another’s assumptions and beliefs. Respect and trust do not imply endless affability or absence of disagreement. Rather, they imply bonds among board members that are strong enough to withstand clashing viewpoints and challenging questions.

~ Jeffrey A. Sonnenfeld

How often do we see folks touting “tech innovation” with nary a mention of e.g. relationship innovation, and innovations in “being human”?

Here’s some valuable non-tech innovations you could be pursuing:

  • Nonviolent Communication (Marshall Rosenberg).
  • Empathy.
  • Compassion and Compassionomics.
  • Zen.
  • Nancy Kine’s Thinking Environments.
  • Dialogue skills.
  • Appreciation of Power Dynamics in the workplace.
  • Reflection and surfacing one’s own assumptions and beliefs.
  • Attending to folks’ needs..
  • Apprciation of the role of the Domination System and the Myth of Redemptive Violence.

Managers Are PONC

Number 4 in Phil Crosby’s Four Absolutes of Quality is “The measurement of quality is the price of nonconformance (PONC), NOT indices.”

By which he meant, that the price of non-conformance to requirements tells us how often and the degree to which our organisation achieves quality. 

Le’s unwrap that a bit further.

In Absolute number 1, he says “The definition of quality is conformance to requirements, NOT ‘goodness’”.

So when we’re delivering stuff to our immediate customers that fails to conform to their requirements, that is not contributing to their success, we are failing to provide quality goods or services. 

We can measure this failure in terms of the price of non-conformance. That is, the costs involved in reworking, retesting, correcting, substituting, fixing-up or otherwise remediating the things we deliver so they do conform to our customers requirements.

In short, any cost that would not have been expended if quality had been perfect contributes to the price of non-conformance.

Managers Are PONC

If we look at the typical work of managers, almost all of what they do on a daily basis is all those fire-fighting remediations mentioned above. Indeed, in most organisations, this is the raison d’être of the manager’s role (minuscule other reasons include prevention of problems, and growth of the organisation and its revenues, profits).

Therefore it’s but a small jump to see that managers are one of the major contributors to their organisation’s price of non-conformance. In other words their costs (salaries, etc). are almost entirely consequent on their fire-fighting role.If fire-fighting was unnecessary, so would be the managers, and their costs.

– Bob

Further Reading

Unknown (2013). Manager Thought: Price of Non Conformance (PONC). [online] Manager Thought. Available at: https://rkc-mgr.blogspot.com/2013/07/price-of-non-conformance-ponc.html [Accessed 4 Mar. 2022].

Merbler, K. (2021) The Entrepreneur Who Created A Business Camelot: Philip B. Crosby. Dominionhouse Publishing & Design, LLC. Kindle Edition.

28 Years Ago

Twenty eight years ago (i.e. 1994) almost no one was interested in doing software development differently. Waterfall and the V Model ruled the roost. And structured methods (SSADM, Dataflow diagrams, etc.) were de rigeur. I was fortunate in finding the ear of the Finance Director of Barclays Bank, who had two urgent projects he needed to see completed in double-quick time, and with no wiggle room for missing the delivery dates. He felt he could no afford to go down the traditional (slow) route.

Of course, in 1994 the term “agile” had not then been applied to software development (at least, in the way the Snowbird folks appropriated the term circa 2001),

After successfully delivering Barclay’s projects, I moved on to Sun Microsystems’ UK Java Center and brought my “new” approach (then being called “Jerid”) with me.

Having transferred my approach and ideas into several of Sun’s corporate client base (mainly banks and other financial institutions in the City), I moved on to found “Familiar” circa 1996. (Being then the first 100% Agile software house in Europe). Jerid served us well, and continues to do so – now named Javelin – up to the present day.

28 Years On

Twenty eight years on and history repeats itself. Almost no one is interested in doing software development differently. This time around, I find myself the guardian and steward of the Quintessential approach. Another step forward at least as great as Jerid was in 1994.

Sigh. And deja vue.

– Bob