Archive

Organisational effectiveness

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

What Orgs Want

Offices

Or, more accurately, what organisations need. (Wants and needs are very rarely the same thing).

First off, does it make any sense to talk about what an organisation might need? Sure, we can discuss the needs of the various groups within an organisation – the Core Group, the shareholders, the employees, and so on. And the needs of the individuals involved – not that the subject of individual needs get much airtime in the typical organisation.

NB I recently wrote a post about the needs of some of these groups in “Damn Outcomes!”.

Back at the main theme of this post: what might be the needs of a given organisation?

Well, like individuals, we make sweeping generalisations at our own risk. At least for individuals, we have some guidance in the form of Maslow’s hierarchy of needs.

From the perspective of Organisational Psychotherapy, an organisation’s needs, whilst fundamental, rarely receive much overt attention. In the course of the therapeutic relationship, the organisation itself may come to a clearer awareness of its own (collective) needs. Those needs may even change and morph as they emerge, become more explicit, and become a valid topic for dialogue and discussion (i.e. ”discussable”).

But we have some basic options for consideration re: the possible needs of an organisation. I wrote about these options some time ago now, in a post entitled “Business Doctrine”. Extrapolating from that post, here’s some possible business (organisational) needs:

  • The need to create and keep customers (Drucker)
  • The need to supply goods and services to customers (serve the needs of the customer) (Drucker)
  • The need to provide a service (Burnett)
  • The need to provide a product or service that people need and do it so well that it’s profitable (Rouse)
  • The need to act as a nexus for a set of contracting relationships among individuals (Jensen and Meckling)
  • The need to optimise transaction costs when coordinating production through market exchange (Coase)
  • The need to serve society (McLaughlin et al)
  • The need to maximise the medium-term earning per share for shareholders (US business schools)
  • The need to make a profit so as to continue to do things or make things for people (Handy)
  • The need to make money (Slater)
  • The need to make a profit (Watkinson Committee)

Given the Rightshifting perspective that the purpose of any given business is more or less unique to a time, a place, and the people involved, we might reasonable say that the needs of any given organisation are also more or less unique to a time, a place, and the people involved.

Summary

To sum up: I choose to believe that organisations, collectively, do have needs. Each organisation is different – it has its own, different and sometime unique needs. The dialogue involved in surfacing any given organisation’s needs brings benefits in and of itself. Absent clarity on those needs, how can the organisation decide on its priorities, on what matters?

– Bob

Further Reading

The Future Of Software-Intensive Product Development – Think Different blog post

 

My Work

My work of the past ten+ years tells executives, managers and employees:

  1. What is the root of the problems in their organisation
  2. What to do about it (how to fix it)
  3. Why they won’t do anything about it

The Root of the Problems

The root of the problems in your organisation is the collective assumptions and beliefs (I generally refer to these as the collective mindset) held in common by all people within the organisation. Most significant (in the conventional hierarchical organisation) are the assumptions and beliefs held in common by the senior executives. In the Marshall Model I refer to the most frequently occurring set on collective assumptions and beliefs as the Analytic Mindset.

In knowledge-work organisations in particular, the Analytic Mindset is at the root of most, if not all, major organisational dysfunctions and “problems”.

What to Do About It

The way forward, leaving the dysfunctions of the Analytic Mindset behind, is to set about revising and replacing the prevailing set of collective assumptions and beliefs in your organisation with a new set of collective assumptions and beliefs. A collective mindset less dysfunctional re: knowledge work, one more suited to (collaborative) knowledge work. In the Marshall Model I refer to this new, more effective set of collective assumptions and beliefs as the Synergistic Mindset. Yes, as an (occasionally) rational, intentional herd, we can change our common thinking, our set of collective assumptions and beliefs – if we so choose.

Why You Won’t Do Anything

You may be forgiven for thinking that changing a collective mindset is difficult, maybe impossibly so. But that’s not the reason you won’t do anything.

The real reason is that the current situation (the dysfunctional, ineffective, lame behaviours driven by the Analytic Mindset) is good enough for those in power to get their needs met. Never mind that employees are disengaged and stressed out. Never mind that customers are tearing their hair out when using your byzantine software products and screaming for better quality and service. Never mind that shareholders are seeing meagre returns on their investments. Those in charge are all right, Jack. And any suggestion of change threatens their relatively comfortable situation.

So, what are you going to do? Just ignore this post and carry on as usual, most likely.

– Bob

The Aspiration Gap

Some years ago I wrote a post entitled “Delivering Software is Easy“. As a postscript I included a chart illustrating where all the jobs are in the software / tech industries, compared to the organisations (and jobs) that folks would like to work in. It’s probably overdue to add a little more explanations to that chart.

Here’s the chart, repeated from that earlier post for ease of reference:

Chart illustrating the gap between available jobs and jobs folks would like to have.

The blue curve is the standard Rightshifting curve, explained in several of my posts over the years – for example “Rightshifting in a Nutshell“.

The green curve is the topic of this post.

The Green Curve

The green curve illustrates the distribution of jobs that e.g. developers, testers, coaches, managers, etc. would like to have. In other words, jobs that are most likely to best meet their needs (different folks have different needs, of course).

Down around the horizontal zero index position (way over to the left), some folks might like to work in these (Adhoc) organisations, for the freedom (and autonomy) they offer (some Adhoc organisations can be very laissez-faire). These jobs are no so desirable, though, for the raft of dysfunctions present in Adhoc organisations generally (lack of things like structure, discipline, focus, competence, and so on).

The green curve moves to a minimum around the 1.0 index position. Jobs here are the least desirable, coinciding as they do with the maximum number of Analytic organisations (median peak of the blue curve). Very few indeed are the folks that enjoy working for these kinds of organisations, with their extrinsic (imposed) discipline, Theory-X approach to staff relations and motivations, strict management hierarchies, disconnected silos, poor sense of purpose, institutionalised violence, and all the other trappings of the Analytic mindset. Note that this is where almost all the jobs are today, though. No wonder there’s a raging epidemic of disengagement across the vast swathe of such organisations.

The green curve then begins to rise from its minimum, to reach a maximum (peak) coinciding with jobs in those organisations having a “Mature Synergistic” mindset (circa horizontal index of 2.8 to 3). These are great places to work for most folks, although due to the very limited number of such organisations (and thus jobs), few people will ever get to experience the joys of autonomy, support for mastery, strong shared common purpose, intrinsic motivation, a predominantly Theory-Y approach to staff relations, minimal hierarchy, and so on.

Finally (past horizontal index 3.0) the green curve begins to fall again, mainly because working in Chaordic organisations can be disconcerting, scary (although in a good way), and is so far from most folks’ common work experiences and mental image of a “job” that despite the attractions, it’s definitely not everyone’s cup off tea.

Summary

The (vertical) gap at any point along the horizontal axis signifies the aspiration gap: the gap between the number of jobs available (blue curve) and the level of demand for those jobs (green curve) – i.e. the kind of jobs folks aspire to.

If you’re running an organisation, where would you need it to be (on the horizontal axis) to best attract the talent you want?

– Bob

Footnote

For explanations of Adhoc, Analytic, Synergistic and Chaordic mindsets, see e.g. the Marshall Model.

 

Obduracy

I tweeted recently:

“The things organisations have to do to make software development successful are well known. And equally well known is the fact that organisations will absolutely not do these things.”

Here’s a table comparing some of the things we know are necessary for success, alongside the things organisations do instead.

Necessary for Success What Organisations Do Instead
Teamwork Heroic individualism
Primacy of people skills Primacy of tech skills
Self-organisation, self-management Managers managing the work(ers)
Systems view of the organisation Partition the organisation into discrete silos
Manage the organisation/system as an integral whole Manage each silo separately
Use systemic measures to steer by Use silo-local measures to steer by 
Relationships matter most (quality of the social dynamic) The code’s the thing (e.g. velocity)
Effectiveness (do the right things) Efficiency (do things right)
Zero defects (quality is free) (defect prevention) Testing and inspections
The workers own the way the work works Mandated processes and methods (management owns the way the work works)
Workers are generalists Workers are specialists 
Trust Rules, policies
Theory Y Theory X
Intrinsic motivation, discipline Extrinsic (imposed) motivation, discipline 
Everyone’s needs matter (everyone’s a customer and a supplier) Only the bosses’ needs matter (your boss is your only customer)
Explicit requirements, negotiated and renegotiated with each customer, just in time No explicit requirements, or Big Requirements Up Front
Incremental delivery against the needs of all the Folks That Matter, short feedback loops  Big Bang delivery, some or all constituencies overlooked or ignored, long or no feedback loops
Kaikaku and kaizen, to serve business goals Kaizen only, by rote
No estimates, flexible schedules Estimates, fixed schedules
Smooth flow (a regular cadence of repeatably and predictably meeting folks’ needs) “Lumpy” or constipated flow 
Work is collaborative knowledge work Work is work
People bring their whole selves to work People limit themselves to their “work face”.

Do you have any more entries for this table? I’d love to hear from you.

– Bob

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Something’s Gotta Give

 

“The things businesses have to do to make software development successful are well known. And equally well known is the fact that businesses will absolutely not do these things.”

This reality puts us in a bind. We find ourselves in a position where we have to trade off successful development against conforming to organisational norms. We can have one – or the other. It’s not a binary trade-off, we can for example relax some norms and gain some (small) improvements in success. But by and large it’s a zero sum game. At least from the perspective of those folks that find value in everyone conforming to preexisting norms.

I don’t think many business folks realise this trade-off exists. Almost all the business folks I have met over the years seem unaware that their norms are what’s holding back their success in software (and product) development. I put this down to the absence of any real understanding of the fundamentally different nature of collaborative knowledge work (different to their experiences and assumptions).

Some of the Things

By way of illustration, here’s just a few of the things that are necessary for successful software (and product) development, that businesses just won’t do:

De-stressing

Removing stressors (things that create distress) from the workplace. These things include: job insecurity; being directed and controlled; being told where, when and how to work; etc..

Stressors serve to negatively impact cognitive function (amongst other things).

Trusting

Placing trust in the folks actually doing the work. We might refer to this a a Theory-Y posture.

Experimenting

Finding out through disciplined and systematic experimentation what works and what doesn’t. See: the Toyota Improvement Kata.

Being Human

Embracing what it means to be human; seeing employees as infinitely different, fully-rounded human beings with a broad range emotions, needs and foibles (as opposed to e.g. interchangeable cogs in a machine).

Intrinsic Discipline

Relying on intrinsic motivation to encourage and support a disciplined approach to work.

Meaningful Dialogue

Talking about what’s happening, the common purpose, and what the problems are.

Eschewing Numbers

Realising the limitations with numbers, dashboards, KPIs and the like and finding other ways to know whether things are moving in the “right direction”.

Prioritising Interpersonal Relationships

In collaborative knowledge work (especially teamwork), it’s the quality of the interpersonal relationships that’s by far the greatest factor in success.

Summary

If your organisation needs to see more success in its software (and product) development efforts, then something’s gotta give. Specifically, some of its prevailing norms, assumption and beliefs have gotta give. And given that these norms come as a self-reinforcing memeplex (a.k.a. the Analytic Mindset), a piecemeal approach is highly unlikely to afford much in the way of progress.

– Bob

%d bloggers like this: