Archive

Innovation

Conventional

Do you feel under pressure to conform to conventions? To do things in accepted and established ways? Irrespective of the relative effectiveness of those conventions?

How do you handle that? 

  1. With good grace, understanding the need for consensus and conformity?
  2. With constructive criticism, attempting to spark discussions on the prevailing conventions and thereby change them?
  3. With surly compliance, resenting the stupidity of it all?
  4. With subterfuge and sabotage, attempting to illustrate the flaws in the conventions?
  5. Other?

I understand all the conventional approaches to software development. I can even reproduce them through teams and development organisations if asked. But why would I want to do that? Who might need me to do that?

Way Less Productive

The simple truth is that conventional approaches are more than five times less productive than unconventional approaches. (ISBSG data indicates that there can be a three orders of magnitude (that’s a thousand times) difference between conventional and unconventional approaches, at the project level).

Fear of the Unknown

Conventional approaches are all that organisations know, of course. Unconventional approaches, almost by definition, are unknown. Fear of the unknown is a strong buttress for the status quo. And so, convention wins out in most cases. 

But what about when organisations purposely try to overthrow a convention? Why is that scenario so problematic and likely to fail?

Maybe we can take a look at this scenario in more detail in a future post, given a demand.

– Bob

Culture Shift

Red hot volcano

The Power of Culture

Giants of industry swear by the power of organisational culture. They could all be mistaken, of course. But the sheer numbers suggest maybe they’re not.

Assuming they’re right, there’s two cases to consider:

Case One: Your organisation has exactly the culture it wants and needs to be totally awesome.

Case Two: Your organisation needs a shift in its culture to become totally awesome.

If case one applies, you’re good. Done and dusted. At least, until the environment (markets, customer demand, technology, society) changes. 

If case two applies, you can continue with that suboptimal culture, or do something about it. If you decide you need to do something, what will that be? How will you shift your culture?

– Bob

The Naming of Familiar

Familiar Limited was a Reading-based software house/consultancy that I started with a colleague in early 1997.

One question I regularly get asked is “How did the name ‘Familiar’ come about?”

I had thought I’d already answered this question, but upon looking for that explanation can’t find it. So here it is (for the record):

I’ve long favoured ambiguous or multi-meaning words (homonyms). We chose the name “Familiar” on that basis. Here’s the three meanings we sought to present:

Familiar as in: well-known, easily recognised.

Our approach to software development was way different to what clients had come to expect from software house suppliers. We were decidedly unfamiliar in our approach, but took pains to appear familiar and comforting from the point of view of our clients interacting and doing business with us.

Familiar as in: Of the Family

We used the family as the metaphor for structuring the company. “Family” were close-knit, and each had equity and a say in the running of the company. “Friends” were (only) a little less invested.

Familiar as in: Witch’s Familiar

What we did for our clients was, for them, largely indistinguishable from magic. Or at least, that was our aim. Our “magic”, our technology, was how we did things. In other words, channelling the Arthur C. Clarke quote:

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C. Clarke

Note also the coquettish reverse “F” in the name, intended to evoke a quizzical, playful spirit (looking a bit like a question mark).

You might like to read my other posts about Familiar too, if this post has piqued your interest.

– Bob

Software Development at Scale

Scaled Agile – or scaling agile – seems like a hot potato at the moment. Here’s a few
thoughts:

Scaled Agile? Don’t. Just don’t. For GOD’S sake don’t.

Agile even at a small scale doesn’t work and scaling something that doesn’t work just leads to an even bigger mess that doesn’t work. Take a look at SAFe if you don’t believe it. Or just listen to Ackoff:

“The righter we do the wrong thing, the wronger we become. When we make a mistake doing the wrong thing and correct it, we become wronger. When we make a mistake doing the right thing and correct it, we become righter. Therefore, it is better to do the right thing wrong than the wrong thing right.”

Mindset (Obvs.)

Mindset (a.k.a. culture, memeplex) over methods, tools, etc.. What an organisation, collectively, believes and assumes has far more impact on e.g. productivity, quality, etc. than any methods or tools. See: Organisational Psychotherapy, the Marshall Model, and my new book, “Memeology“.

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

And Schein also provides us with a definition for “the culture of an organisation”:

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

Flow Efficiency

Goldratt wrote the book on Flow Efficiency (see “The Goal”, in case you’re interested).

Flow efficiency is miles better than resource efficiency (a.k.a. utilisation). What is flow efficiency? I’m sure you can look it up. But for the lazy: Flow efficiency suggest a focus on keeping work moving through its various value-adding steps, with minimal or zero queues and wait times, thereby attending to folks’ needs (value to the Folks That Matter) – and prompting feedback – as quickly as possible.

Formalise Innovation

Formalise innovation, evolve into continuous organisational transformation.

What do I mean by “innovation”?
In the context of organisations, here are a few possible definitions of “innovation”:

  •  A process by which a method, a product, or a service is renewed and refreshed by applying new ideas or introducing new techniques to create new value.
  • Turning an idea into a solution that adds value from the perspective of the folks that matter
  • A new strategy (means) for attending to the needs of the folks that matter.
  • The application of ideas that are novel and useful.
  • Staying relevant – keeping pace with changes to the (business) environment.
  • The implementation of something new – until it’s implemented it’s just an idea.
  • Stop talking about innovation. Focus on organisational transformation.

Here’s my preferred definition:

Innovation: Delivering against an idea which meets a specific set of needs, for all the Folks That Matter.

And “formalise”? What the hell does that mean, exactly? In effect, institute trainings, standard work, measures, etc., around the whole innovation (and, a.s.a.p., organisational transformation) piece.

I’ve been brief here to avoid a rant. Do get in touch if you’d like me to elaborate on some of these themes.

– Bob

Oblivious

It’s long been my belief that the whole software industry could be doing so much better than it is doing, and so much better than it has been doing for the past fifty years and more.

In that belief is where my work on Rightshifting, and the Marshall Model, originated, some fifteen years ago now.And continues today.

In my travels I’ve seen countless organisations, groups and individuals demonstrate an oblivious disregard for the potential for significant improvement. I say oblivious because there’s almost no one in the industry with knowledge of or even a vision for how great things could be.

Oblivious

According to the Merriam Webster dictionary, “oblivious” originally meant “characterised by forgetfulness”. Perhaps those in the software industry today have forgotten what previous generations, long since retired, once knew about effective software development. Or perhaps folks have just never known.

I hear some readers wonder: “is it obliviousness, or just ignorance?”. Given current usage “lacking active conscious knowledge or awareness”, I myself wonder about the roots of the phenomenon.

Through my work, in particular at Familiar, and through study of the positive deviants (outliers) in the industry, I have come to see the scope of possible improvement, and the means thereto, too.

Aside: Positive deviants include SSE (Denmark), Forward Engineering (London, UK), Lockheed Martin, and in slightly different spaces, Toyota, Semco, and Buurtzorg. ISBSG also has much confirming data.

Scope

Data (e.g. ISBSG) shows there’s a x2, x3, x4, even x5 scope for improvement in organisation-wide effectiveness of software-led organisations.

I’m regularly struck by the obliviousness of folks to this scope for improvement. To misquote R Buckminster Fuller:

“You cannot question an oversight you do not know you have made”

Causes

Whether the Software Crisis is a thing – or even was ever a thing – or not, it’s clear to me that software organisations woefully underdeliver vs their potential.

Why is this? I largely attribute it to folks of all stripes being oblivious to the scope for improvement. Whence this obliviousness? I’m guessing now, but I guess it’s down to either a lack of curiosity, or to fear of the wholesale changes to organisational assumptions and beliefs necessary to realise the potential on offer.

Fear

It’s become clear to me over the years that management has to fundamentally change, or even disappear – in the form we have known it – before we see the untapped potential of software businesses begin to be realised. And folks in the industry who may be in a position to effect such change fear for their jobs and careers. As Machiavelli, oft-quoted, wrote:

“It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones.”

Paradigms

Thomas Kuhn, in his book “The Structure of Scientific Revolutions” asserts that science advances vis “paradigm shifts”. Donella Meadows makes much the same assertion with her “12 leverage points of change”.

I posit we’ll not see a widespread uptick in the effectiveness of software organisations, nor in the effectiveness of the software industry as a whole, unless and until the existing paradigm (primarily the prevailing management paradigm) changes.

Interested readers may wonder how, if, and when this might happen. I have some ideas on this, which I’ve set down in numerous posts here on this blog.

– Bob

Postscript

I know that neither data, nor rational argument convinces, nor moves the needle on action. With this post, I only hope to invite some few folks in a position to take action to become a little curious.

Further Reading

The Power of Positive Deviance: How Unlikely Innovators Solve the World’s Toughest Problems ~ Pascale, Sternin and Sternin
All Executives Are Unethical ~ FlowchainSensei (Falling Blossoms White Paper)
The Structure of Scientific Revolutions ~ Thomas Kuhn

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addressing the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

Do Nothing That Is Not Play

If we think about it calmly for but a moment, one logical outcome of nonviolence is folks not working for a living, but playing for a living.

Innovation

Many companies seem desperate for “innovation”. Is innovation more like to come about through folks doing what they’re told (“working”) or through playing with things, as they see fit? I posit the latter is far more likely.

And no, this is not some flight of fancy. Do we really embrace wholeheartedly the set of assumptions labelled by Douglas McGregor as Theory-Y?

Theory-Y assumptions are: (1) physical and mental effort are natural and most people (depending on the work environment) find work to be a source of satisfaction, (2) they generally, on their own motivation, exercise self-control, self-direction, creativity, and ingenuity in pursuit of individual and collective (company) goals, (3) they either seek responsibility or learn to accept it willingly, and that (4) their full potential is not tapped in most organisations.

Could it be that folks’ “full potential is not tapped in most organisations” because they are obliged to “work” rather than play?

Could it be that engagement (and productivity) would take an amazing leap forwards if we invited folks to “play” rather than “work”?

Could you have the courage to experiment to find out for yourself?

Or are we all so in thrall to what Walter Wink calls The Domination System that play as an alternative to work is undiscussable?

– Bob

Further Reading

Serious Play ~ Michael Schrage
The Importance of Play (A Valentine for Marshall Rosenberg, part 2) ~ John Kinyon
What If #7 – No Work ~ Think Different
The Human Side of Enterprise ~ Douglas McGregor
Theories of Motivation ~ Think Different

Holistic Solutions for Product Development Businesses

Several people have been in contact this week to say “It’s all very well talking about holistic solutions for software development, but who really has any notion of what that might even look like?”

Which is a fair question.

Aside: Let’s note that the phrase “holistic solution for software development” is an oxymoron of the first order. By definition, software development is but part (and generally a small part) of any solution that addresses customer or market needs. Even software “pure plays” have a lot of non-software components.

So, I thought I’d describe just one holistic solution for whole organisations that develop new products containing some software. For want of a better name, I’ll call it this example “Flow•gnosis”. With this example, I hope that maybe one or two readers might find a spark of insight or inspiration to broach the question of a True Consensus in their own organisation.

I’ll try to keep this post brief. I’d be happy to come talk with you about holistic product development solutions for organisations, in person, if you have any real interest.

Flow•gnosis?

Flow•gnosis is a hybrid born of FlowChain and Prod•gnosis. FlowChain is not specifically a holistic solution, focussing as it does on improving the flow of knowledge work through a development group or department whilst moving continuous improvement “in-band”. Prod•gnosis is specifically a holistic solution for effective, organisation-wide product development, but says little about how to organise the work for e.g. improved flow or continuous improvement.

Together, they serve as an exemplar of a holistic solution for knowledge-work organisations, such as software product companies, software houses, tech product companies, and organisations of every stripe with in-house product development needs.

Let’s also note that Flow•gnosis is just an example, to illuminate just a few aspects of a holistic solution. Do not under any circumstances consider copying it or cloning it. Aside from the lack of detail presented here, you’d be missing the whole point of the challenge: building a True Consensus, as a group, with your people, in your context.

What’s the Problem?

Before talking more about a solution, what’s the problem we’re trying to solve?

I’ll work through an almost universal problem facing organisations that “do” software development. A problem that some enterprising supplier or management team might choose to address with an “innovative” solution.

Understanding the Problem

Here are some typical Undesirable Effects (UDEs) I hear from many companies involved in software and product development:

UDE: Delivery is not fast enough (long time-to-market)

UDE: New products cost too much to develop (high cost to bring to market)

UDE: We struggle to keep our products at the cutting edge

UDE: We always drop balls in hand-offs of tasks (i.e. between specialists, or business functions)

UDE: Continual contention for in-demand specialists

(For the sake of brevity, I’ll skip the building and analysis of the cause and effect graph. Your analysis will be different, in any case).

Root cause: Developing new software, products and services through a byzantine labyrinth of tasks and hand-offs, between and across dozens of specialisms within the company and its network of suppliers and distributors. This approach causes many delays (waste of time), mistakes (waste of effort, money), contention of resources, etc.

Conflict: A) Specialists must work together in their own specialist groups or silos to maintain their cutting-edge skills and know-how. B) Specialists from across all specialisms must work together as a group else handoffs and queues will cause many delays and mistakes.

Conflict arrow: Specialists cannot work in their own groups advancing their specialist knowledge at the same time as they work together with other kinds of specialist on new product ideas.

Flawed assumption at the root of the conflict: Specialists must work together. What makes this so? Only the old rules of the organisation. That silos (a.k.a. business functions) “own” their clutch of specialists. What if we changed that rule? (Note: this change is one key element of Toyota’s TPDS). And if we changed that rule, what other rules would we need to change too?

A Bird’s Eye View of Flow•gnosis

Prod•gnosis looks at an organisation as a collection of parallel Operational Value Streams, each dedicated to the selling and support of one of the organisations’ (whole) product or service lines. And each with its own team or collection of people doing the daily work of that operational value stream. Further, Prod•gnosis asks “How do these operational value streams come into being?” And answers with “They are made/created/developed by a dedicated Product Development Value Stream.”

FlowChain describes a way of working where a pool of self-organising specialists draws priority work from a backlog, executes the work, and delivers both the requested work item, and posting new work items (for improving the ways the work works) into the backlog. In this way, FlowChain both improves flow of work through the system, and brings continuous improvement “in-band”

By merging Prod•gnosis and FlowChain together into Flow•gnosis, we have an organisation-wide, holistic example which improves organisational effectiveness, reifies Continuous Improvement, speeds flow of new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

The latter point is perhaps the most significant aspect of Flow•gnosis. Having customer, supplier, marketing, sales, finance, logistics, service, billing, support and technical (e.g. software, usability, emotioneering, techops, etc.) specialists all working together (cf. Toyota’s Obeya or “Big Room” concept) enables the evolution of “Mafia Products” and “Mafia Offers” which the more traditional silo-based models of business organisation just can’t address effectively.

Out With the Old Rules, In with the New

Flow•gnosis is an innovation. Irrespective of the promised benefits of Flow•gnosis, we have learnt in recent posts that adopting an innovation ONLY brings benefits when we change the rules.

Let’s apply the four questions to our Flow•gnosis innovation and see what rule changes will be necessary to truly reap the benefits.

Q1: What is the POWER of Flow•gnosis?
A1: Flow•gnosis makes it commercially feasible for a company to repeatably come to market with new “Mafia Products”.

Mafia Product: “A product (or service) so compelling that your customers can’t refuse it and your competition can’t or won’t offer the same.”

Q2: What limitation does Flow•gnosis diminish?
A2:  Serialisation of specialist work (passing things back and forth between various specialist and business functions).

Q3: What existing rules served to help us accommodate that limitation?
A3: Handoffs. Queues. Batches. Separation of command and control from the work. Process. Process conformance. Local measures. Constant expediting. Critical path planning (Gannt charts, WBS). Local optima. Functional management (discrete management of each separate business function).

Q4: What (new) rules must we use now?
A4: Flow. Value streams. SBCE. Holistic measures. Ubiquitous information radiators. Cost Of Delay prioritisation. Buffer management. Constant collaboration. Dedicated teams of generalising specialists. Self-organisation. In-band continuous improvement. Resource levelling. Limits on WIP.

Summary

This post has been a – necessarily brief – look at one holistic solution to (software) product development. Crucially, we have seen how old rules have to be replaced, and what many of the replacement new rules might look like.

I invite you to remember that Flow•gnosis is just an broad-brush example of a holistic solution. Please don’t consider copying it or cloning it. And remember the real challenge: building, as a management group, a True Consensus.

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

Obstacles to True Consensus – Summary

[Tl;Dr: Major improvements in the effectiveness of any organisation go begging, because the skills and experience for reaching the necessary True Consensus are almost always absent.]

This is the final post in my recent mini-series about obstacles to True Consensus.

The Big Picture

Let’s step back and try to take in the big picture for a moment.

I most often label this big picture “Organisational Effectiveness”. You might prefer to call it “improving the bottom-line”, “productivity”, or simply “success”.

Why does this big picture matter to me? Because of the impact ineffective organisations have on the people who work in them, on the people who depend on their products and services, and on society as a whole.

Employees

I’m a software engineer at heart. I have so many times worked with software engineers and other folks wanting to make a difference in the world, and being unable to do so because of the ineffectiveness of the organisations within which they work. Sooner or later, these folks simply give up on their dreams and “check out” (remaining employed but disengaged) or quit. Having been in the same boat myself on any number of occasions, I feel like I can relate. And, BTW, that’s why I now serve organisations in the role of Organisational Psychotherapist, actually doing things – albeit non-software engineering things – to “make a difference”.

Customers

I’m a customer of these organisations, too. We all are. Not out of choice, let me add. I have in mind the various organs of state, in which we have no say regarding the shoddy services and lame products they foist on us. Not that most private corporations are much better.

Society

How do ineffective organisations impact society? Apart from the waste of public money (many are in the public sector) that could be put to better use elsewhere, the sheer number of ineffective organisations lead us all to believe that ineffectiveness is normal and unavoidable. We seem to have lost the belief that we can ever expect to see things become better.

The Key to Improved Effectiveness

It’s pretty much accepted that the ability to transcend paradigms (an organisation’s beliefs, assumptions and rules about work) is the greatest lever to improve effectiveness. And by effectiveness, I mean reducing or eliminating things that should not have been done but nevertheless were done. See my recent post: Reliability and Effectiveness for details and objective measures of this.

In other words, the prevailing paradigm, or mindset or memeplex governing an organisation determines its effectiveness. And so, it’s obvious that to improve effectiveness, we must “shift” this paradigm. This is where most organisations falter and fail. They have no experience or capability in achieving a True Consensus. Such a thing looks like an impossibility.

Aside: Agile

In case you’re wondering if there’s any relevance to tech companies and their employees and customers: All flavours of Agile are essentially forms of local optima. Local optima, in that Agile initiatives are almost always limited to one silo (the “development” or “IT” silo) in the organisation. Most people in organisations doing software development are obliged to place their faith in systems of local optima. This is because the prospect of building a True Consensus across the whole organisation seems so daunting, so impossible, so contrary to prevailing behaviours, as to never receive serious consideration or discussion. And so, systemic ineffectiveness is locked in.

True Consensus

A “True Consensus” is when ALL top managers agree on the exact SAME action plan, with each and every top manager regarding his or her components of the joint action plan as his or her own baby.

Whether in a single organisation, or society as a whole, True Consensus is a prerequisite for concerted action to make things better, to make things more effective. On the path towards effective organisations, progress will only come about if the top teams, and eventually their whole organisations, can agree on their core problems and find coherent, holistic ways forward, together. True Consensus is the necessary prerequisite for Rightshifting any organisation.

This mini-series and its precursors has described one path to arrive at such a True Consensus, including describing the obstacles we can expect to encounter along the way, and ways of overcoming those obstacles.

In brief, the described path consists of repeatedly practicing, as a group and emergent leadership team, these steps:

  • understanding the core conflict in a problem by discovering the inherent flawed assumption
  • agreeing on a direction for a solution
  • elaborating that direction into a full (holistic, company-wide) solution or plan of action
  • agreeing on how to implement that full solution
  • enacting the implementation

You can find more details in the posts of this mini-series:

Obstacles to True Consensus – The Dominant Impatient Visionary

Obstacles to True Consensus – The Smart Conservative

Obstacles to True Consensus – Extrapolating From the Past

Obstacles to True Consensus – Solutioneering

Obstacles to True Consensus – Summary (this post)

and in the four posts prior to the mini-series itself:

Organisational Psychotherapy and the Bottom Line

Pillars

Innovation ALWAYS Demands We Change the Rules

Reliability and Effectiveness

And you can find even more in-depth elaboration of these ideas in e.g. Goldratt’s audiobook “Beyond The Goal”.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Leverage Points: Places to Intervene in a System ~ Donella Meadows
The Asch Conformity Experiment (Video)

Obstacles to True Consensus – Solutioneering

Following on from the third post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

The term “solutioneering” describes our natural tendency to jump to a solution, and elaborating that solution, even implementing something, before we fully understand the problem at hand.

Obstacle: Solutioneering

If we think about solutions while we are analysing a core problem, we will distort reality to fit the solution we have in our mind.

And at the time we’re creating the solution, any time we spend on thinking about how we’ll implement it will distort the solution, too.

In other words, we’ll come up with better solutions, and implement them better, when we tackle any candidate idea in clearly delineated and separated steps:

  1. Analyse the core problem. Simply understand the problem, and the underlying core conflict.
  2. Find the solution
  3. Decide how to implement the solution

You may recognise this approach as the Three Fundamental Questions of Theory of Constraints.

1. What to change?
2. What to change to?
3. How to effect the change?

At each step, we forbid ourselves from considerations better reserved to the other steps. Given the risk of confusion, delusion, distortion, and ineffective conversations, we must maintain the separation between these steps. Absent such separation, the risks of conflating these concerns means we will be that much less likely to achieve our essential True Consensus.

Next time: Summary – Summarising this mini-series.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)
Theory of Constraints: What to Change ~ Dave Lane (blog post)

Obstacles to True Consensus – Extrapolating From the Past

Following on from the second post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people. And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours that have brought the company to its present success.

Extrapolating from the past is not something negative, it’s something positive. If we don’t extrapolate from the past, if we start every time from a clean slate, what are the chances we’ll do anything sensible? Pretty close to zero. Experienced people are, by definition, people that extrapolate from the past. Otherwise we have no intuition, no insights into a subject.

Here, we’re going to look at two different aspects of this obstacle.

Obstacle: Extrapolating From the Past Into What We Might Do In the Future

This is the first aspect of extrapolating from the past. Extrapolating from the past works in our favour. So what’s the problem with it? When we come to build the change, to build the new strategy based on our new rules, to really embrace the power of the synergistic approach, our past contains what? Yup. The old rules. And if we extrapolate from the old rules, what do we get? We get the same strategy we already have – maybe in slightly different words only – and nothing happens.

Remediation: Exclude the old rules

So, how can we make sure we extrapolate from the past, building everything on past experience, except for the old rules. How can we exclude these old rules? By examining each conflict, by identifying our flawed assumptions- rooted in the old rules – and removing these flawed assumption. In this way, we make our past experience more homogeneous, and everything makes much more sense. We’re not abandoning the past. We’re not erasing our past experience. Exactly the opposite. We’ve removed the one thing that causes our experience to be inconsistent. And we’re reshaping our past experience. Making it much clearer and more palatable. Folks love this.

So what we have to do is take a number of key ideas in turn, and apply the same process:

  • Do the analysis
  • Discover the conflict via the flawed assumption
  • Remove the conflict

By doing this, we reshape our past experience. And the minute we do this, we still extrapolate from our past experience, but based on the new rules, rather than the old rules.

And by the way, did you notice how, for this aspect of the obstacle, remediation is much the same approach as we take with the Dominant Impatient Visionary and the Smart Conservative obstacles?

Obstacle: Extrapolating From Past Experience of Each Other

This is the second aspect of extrapolating from the past. Given our experience of the folks we work with, will they collaborate now? Do they really mean yes when they say yes? Can we rely on them? In most companies, extrapolating from the past in this context leads to less than positive feelings, because what we extrapolate from the past is not exactly flattering.

Remediation: Explore, Reflect and Change as a Group

How to remediate? We have to ensure that we reflect on the past, on our past interactions, on our extrapolations of folks’ behaviours, as a group, rather than in one-to-one conversations. In this way, each person will see how everyone else is also going through the same kind of change. This means, by the way, that all the previous remediations we have mentioned in this series also have to be done in a group, not one-to-one.

Aside: This excludes people learning this stuff from books. People have lost the art of reading together in groups.

Next time: Solutioneering – the final obstacle to True Consensus, explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Obstacles to True Consensus – The Smart Conservative

Following on from the first post in this mini-series, today I’ll describe another obstacle to True Consensus. Again, it’s about the behaviour of certain key people.  And again, in line with our belief that “People are Good”, the behaviours we’re discussing are not dysfunctional behaviours, but the outstanding, positive behaviours, the virtues, that have taken the company to its present success.

Obstacle: The (Smart) Conservative

Usually, these are people with an enormous amount of experience, very well respected. But somehow, given any suggestion of what to improve, they immediately find ways to prove to you it should not be done. It’s as if they’re going out of their way to maintain the status quo. Do you know anyone like this? What can we do?

As long as these people are in the crowd – and they’re always in the management crowd – what chance do we have of reaching a true consensus on some idea, or way forward, that is beyond the expectation of almost anyone in the group? It’s not that these conservative people are stupid. Definitely not. Do you think that they’re out of touch with reality? That they don’t know the situation of the company? Of course they know. And very well.

And now if we talk with them and ask them “What do you think? Do you think that if the company fails to embark on a process of ongoing improvement, it will survive in the future? What do you think their answer might be? They thoroughly believe that if we DON’T improve, we’re going to be out of business. So how come that these people – with so much experience, with such strong convictions that the company must improve – block any suggestion for improvement? What are they, imbeciles? How it is that this happens?

Here’s the explanation: These smart conservative people have the gift of being able to see both sides of a conflict. Very clearly. As a matter of fact, when we, through analysis, cause them at last to see the core problem, they will tell us “We already know that. We have already spoken out about it, more than once.” And they really believe the problem exists, and the analysis is correct. They have seen both sides of the conflict. They are keenly aware of both sides of the conflict. But do you see what’s happening? Most suggestions for improvement that they have seen in their careers, the vast majority, anyway, are not solutions or improvements that remove the conflict, they are solutions based on movement on the conflict arrow. To give an example of what we mean by “movement on the conflict arrow” consider the bi-annual flip-flop in many companies; from centralisation, to decentralisation, and back again to centralisation. Each time this movement was presented as “THE thing that will save the company” So many huge and expensive reorganisations. Each time, these smart conservative people oppose such initiatives.

Why? They’ve already seen solutions based on movement on the conflict arrow. They have learned from experience that the ONLY thing that will happen in such cases is the substituting one set of undesirable effects for another set of equally undesirable effects. And if that’s what people want to do, better not to do anything. ”Thank you – we have seen it before, we’ve been there already, why should we try the same thing again?”

Remediation: Block Movement on the Conflict Arrow, Identify and Remove the Flawed Assumption

How then do we cause these conservative folks to move towards our true consensus? Let’s present some new ideas, and for each one show the core problem, the conflict. To begin with they will not be surprised. They know the problems already. But then we show them that we have no intention whatsoever to move on the conflict arrow. More than that, we show that we propose blocking any movement on the conflict arrow, because it would be just substituting one set of undesirable effects with another.

Instead, we highlight the flawed assumption within the conflict. We don’t say ”we have a solution”, but rather “we have a direction for a solution”. In other words, our direction is based on the knowledge that we have found one (or more) flawed assumptions. So now we proceed to the next step: creating the full solution. In Theory of Constraints, the full solution emerges from the creation of a Future Reality Tree.

Yes, But

The Future Reality Tree leverages the remarkable ability of people, especial smart, conservative people, to say “Yes, but…”. Usually, a small yes, and a big BUT…

So, rather than attacking these “yes, but” reservations, we embrace the gift within every “yes, but”: “Yes, I understand the solution, yes, it will remove the conflict, BUT it will create another issue…”.

We help as much as we can to meticulously document the cause and effect of the “but”. We go out of our way to do this, to clarify their reservation. Once we have articulated really clearly what’s bothering someone, their reservation will augment our solution by removing the “but”. In this way we arrive at a full solution. With each reservation making that solution simpler, more powerful, and more intense.

And we ourselves learn the value of taking the time to listen to and clarify folks’ reservations.

Repeating this approach three or four time with a smart conservative person, they begin to realise that we are even more paranoid than they are. In a good way.

As soon as these folks understand our intentions, our rigour in dealing with risks, they become our champions and biggest supporters. In most cases the biggest supporter of True Consensus and all the changes it implies is the CFO.

This is how to remediate the obstacle of the smart conservative.

And by the way, did you notice how it’s much the same approach as we take with the Dominant Impatient Visionary?

Next time: Extrapolating From the Past – another obstacle to True Consensus explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

 

Obstacles to True Consensus – The Dominant Impatient Visionary

In my previous post I describes the necessary condition for successfully approaching a shift away from a company based on local optima (a.k.a. the Analytic-minded organisation) to one based on a holistic view of business (a.k.a. the Synergistic-minded organisation). Goldratt refers to this necessary condition as a “True Consensus” at the top of the company (along with a subsequent smooth spread of that holistic top-level consensus, without resistance and without fighting).

But how to reach such a true consensus? It can look like an impossibility, due to a very common set of obstacles.

In a series of posts I’ll run through describing these obstacles, along with some options for minimising or even removing each of them in turn. In a nutshell, the real obstacles to True Consensus are the behaviours of key people.

In line with our belief that “People are Good”, we might choose to note that the behaviours we’re discussing are NOT dysfunctional behaviours, but the outstanding, positive behaviours, the virtues, that have taken the company to the successful place it occupies today.

The First of Five

So, what are the real obstacles (barriers) preventing a True Consensus? And how to overcome them, systematically, in a way that’s widely applicable across many companies, and minimising the risk of running into brick walls along the way?

There are five obstacles I’d like to explore. This post begins with just one; the Dominant Impatient Visionary.

Obstacle: The Dominant Impatient Visionary

This kind of person drives their company forward to success. They have been, and remain, the engine of the company. Explaining an idea to this kind of person, though, we generally get just a minute or two of their attention before they start to chew us up, to attack or dismiss our idea. Even though this kind of person is so important for the progress of the company, they are also deadly poison for consensus. Their use of positional power and charisma kills any chance of consensus. And god forbid we try to get rid of people like this. On the other hand, these folks are very smart. They do realise that the biggest stumbling block in moving the company forward is their own impatience. Nevertheless they look like they can’t control their toxic behaviour. How is this?

Here’s what happening: their impatience is probably imbedded in the fact that this person has the stamina to shoot for a very high vision for the company. At the bottom of any idea there is a core problem, and the core problem is based in some kind of conflict. This person has unconsciously conditioned himself to look at just one side of any core conflict. Because he’s trying to avoid taking the “hit” to his stamina that will inevitable arise if he spends any time looking at the other side of the core conflict. He has unconsciously blinded himself to the other side of any core conflict.

As soon as anyone presenting a new idea mentions the other side of a core conflict, his impatience kicks in, and this nice pussycat becomes a tiger. This is what always happens.

But there is a way to channel this person’s phenomenal vision, ability and stamina into a direction that helps consensus:

Remediation: Focus on the Benefits of Identifying and Removing the Flawed Assumption

For any idea, we analyse it and show the core conflict explicitly. We show both sides of the core conflict. And then we say that despite the conflict, we’re NOT going to lower our expectations, or lower the vision. We’re not going to compromise. What we ARE going to do is find and remove the flawed assumption.

And when the flawed assumption is found and removed, we’re shooting even HIGHER than before. Amazingly, we can show how the side of the conflict he habitually ignores – where he intuitively avoids looking – contains the flawed assumption.

The minute we find and remove the flawed assumption, then everybody can get behind the idea. The smart person can soon spot this pattern, in maybe as little as three or four instances of highlighting the flawed assumption. And the pattern is: “I’m not afraid any more that by looking on the other side I will reduce my ambitions, or that I will lose my stamina. I’m looking on the other side for only one purpose: to find and remove the flawed assumption.”

Next time: The Smart Conservative – another obstacle to True Consensus explored.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Innovation ALWAYS Demands We Change the Rules

How do you feel about the proposition:

“Innovation can bring benefits if and ONLY if it diminishes a limitation”

Let’s examine this proposition. Do you agree with it? Don’t be too hasty in coming to agree with it. Once we agree, you’re hooked! So, let me explain a little more, starting with some definitions:

Innovations

We’re talking here about all kinds of innovations. Not just tech innovations (new materials, new languages and tools, new industrial processes, new scientific discoveries) but other innovations too (new ways of doing things, new ways of structuring and managing organisations, new ways of developing products and software, plus many others).

Limitations

What do we mean by “limitation”? A limitation here is anything that restricts us from getting our needs met to the maximum possible extent. (And btw that maximum is, itself, a limitation).

Limitations can be “recognised” (for example, a speed limit on a motorway) or unrecognised (for example the physical speed limit for a given curve, with a given vehicle, in specific road conditions).

Examining the Proposition

So, back to the proposition: “Innovation can bring benefits if and ONLY if it diminishes a limitation.”

Do you agree?

We were alive and functioning even before the innovation became available. Correct? It must be, then, that long before the new innovation, we developed modes of operation, modes of behaviour, policies, rules, to accommodate the limitation. I’ll refer to all these as simply “rules”.

We were able to operate. Rather than run smack into the limitation and die. That’s obvious.

Before the innovation, we created certain rules to cope with the limitation (recognised or unrecognised, known to us or unknown).

Suppose, then that we make a very good job of implementing an innovation, and thereby diminish the associated limitation totally. Still, the question is:

What benefits will any innovation bring, if we neglect to change the rules? The rules that helped us to accommodate the limitation, before the innovation was available? What benefits will we see if we neglect to change the rules?

Do you start to see the answer?

The Old Rules Block Any Benefits

What benefits will we see if we neglect to change the rules? Basically, no benefits. None. Why? Because as long as we obey the old rules – the rules that were there to bypass the limitation – for as long as we obey these rules, for all practical purposes we will continue to behave as if the limitation is still there.

Can it be that we’re so stupid that we continue to adhere to our old rules, the rules we originally invented to bypass or cope with the limitation? You know the answer.

This is what is happening every day, for the vast majority of organisations, and for the vast majority of innovations they adopt. For a long time after adopting the innovation we still obey the old rules. And because of this, for a long time we don’t get any of the real benefits from our investment in the innovation.

Four Not So Frequently Asked Question

So, how might we proceed if we need to ensure that innovations really do bring us the promised bottom-line benefits? We might choose to ask ourselves the following sequence of four questions:

Q1: What is the POWER of the innovation? (Just ask the inventors, they’ll be more than glad to explain, and explain, and explain…).

Q2: What limitation does this innovation diminish? (We must find a specific and precise answer, here).

Q3: What existing rules served to help us accommodate that limitation (i.e. what obsoleted rules we must get rid of)? Here we can for the first time evaluate the tangible bottom-line benefits from removing those old rules). (Note: As long as the old rules remain in force, we will never see the promised benefits from the innovation). Ch1 11:10

Q4: What (new) rules must we use now (in place of the old rules which the innovation has obsoleted)?

Let me give you an example. Let’s take Agile Software Development as our innovation.

Q1: What is the POWER of Agile Software Development?
A1: Agile Software Development increases the likelihood that we’re developing software that meets our customers’ real needs.

Q2: What limitation does Agile Software Development diminish?
A2:  Risk of misunderstanding customers’ real needs, both now and as they evolve.

Q3: What existing rules served to help us accommodate that limitation?
A3: Contractual terms. Big up-front specifications. Rigorous plan-driven project management. Change control. Specific duration projects. Formal V&V.  One-off or infrequent release into production.

Q4: What (new) rules must we use now?
A4: Development and delivery as experiments. Short, tight feedback loops. Constant collaboration between customers and developers. Constantly evolving specifications and solutions. Multiple “stop/continue” checkpoints. Incremental and frequent release into production.

Try It For Yourself

Here’s some other innovations we see introduced in e.g. software development organisations. May I invite you to run through the above four questions for one or more items on this list?:

  • Teams / team-based development.
  • Obeya (big-room).
  • TPDS (Toyota Product Development System).
  • Lean Product Development.
  • Cost of Delay.
  • Flow.
  • Python, ELM, or some other new language or tool you may be considering adopting.
  • Self-organisation / self-management.
  • Servant Leadership.
  • Holacracy.
  • Serious Play.
  • Continuous Improvement.
  • [Your own favourite innovation].

We Must Change the Rules

“Human beings cannot progress unless somehow they do things differently today from the way they did them yesterday.”

~ Shigeo Shingo

So now we can see that the real effort we must make is NOT in adopting new innovations, but in changing the rules. And these rules are manifest in the assumptions-in-action, the collective mindset, the culture, of an organisation. This, btw, is the central message of Rightshifting and the Marshall Model.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

%d bloggers like this: