Archive

Innovation

Waiting In The Wings

What’s going to the next big thing in terms of approaches to software delivery? And when might we expect the transition to that next big thing to become apparent?

“The future’s already here – it’s just not evenly distributed.”

~ William Gibson

The Days of Agile Are Numbered

We can argue about how much life the Agile approach to software delivery has left in it. What’s beyond dispute is that there will be something after Agile. And I propose it will  look much different from Agile. I find it inconceivable that Agile is so perfect that there’s no room for improvement. Even though – ironically, give the exhortations to “inspect and adapt” – many in the Agile supply chain don’t want to talk about it AT ALL. Why rock the boat and derail the gravy train?

Customers and users, however, are waking up to the inadequacies of presently lauded approaches. And current upheavals in organisations, such as remote working and the scramble for talent, are accelerating these folks’ dissatisfaction.

Holding You Back

What’s prolonging the transition towards any new approach? Basically, it’s the prospect of the serious pain that comes with the adoption of effective new approaches. SAFe’s transient popularity illustrates how many organisations prefer an ineffective approach, with the illusion of change, rather than an effective approach that actually brings benefits. Any significant uplift in software delivery and product development performance implies a much different approach to running technology organisations, including, not least, different styles of management.

Your View?

What’s your view? What promising new approach(es) do you see waiting in the wings? And if there’s nothing with a recognisable name or label, what characteristics will a new approach have to have to boost it into consideration?

– Bob

More On Sea Change

Do you need to see a Sea Change in the software industry, or does the status quo suit you and your needs just fine and dandy, thank you very much?

As the inventor of Agile software development circa 1994, I feel uniquely placed to suggest the need for such a sea change,and what that sea change might look like.

It’s all laid out in my most excellent book “Quintessence“, along with its companion volumes “Hearts Over Diamonds” and “Memeology“.

How often have you discussed the subject with your peers, friends, colleagues, higher-ups, etc.?

Without your active support and involvement, a sea change ain’t never likely to happen. Until then, status quo FTW.

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/[Accessed 08 Jun 2022].
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 08 Jun 2022].
Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.comFalling Blossoms (LeanPub). Available at: https://leanpub.com/heartsovediamonds/ [Accessed08 Jun 2022].

The #NoSoftware Option

One of the many things that distinguishes The Quintessential Group from the Software Delivery also-rans is that our Quintessential Teams service provides our clients and prospective clients with a #NoSoftware option. John Seddon and his company, Vanguard Consulting, advise deferring software automation of new business processes and process steps at least until those steps have been trialed and proven through manual implementations – Post-its, paper-based processes, manual steps, etc. For those organisations that buy into this perspective, our #NoSoftware option means our teams will deliver these non-software solutions quickly and cheaply.

Also known as “software last”, a #NoSoftware solution is one that minimises the amount of software in a solution – in particular minimising the amount of custom-written software – ideally to the exclusion of software from the solution entirely.

As Steve Jobs famously said:

The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.

~ Steve Jobs

The Benefits of #NoSoftware

  • Less maintenance overhead

The fewer lines of code in any given solution, the less needs to be spent on keeping that code up to date in line with e.g. changing requirements and discovered defects.

  • More flexibility

Did you know that the term “software” was first coined back in the 1950’s to reflect the idea that software could be changed more easily, quickly and at lower cost than the hardware solutions that then predominated? It was supposedly easier to change a line of code than to reroute traces on a PCB, or swap out soldered components. Nice wishful thinking, but it hasn’t turned out that way. Software is notoriously expensive, inflexible and difficult to change. Less software means increased flexibility and business agility.

  • Savings on up-front costs

Software costs money to write, even before it goes into service. Not only to pay for ever more expensive programmers and their friends, but also the opportunity costs of having to wait for the software to be ready to deploy. In most organisations this can mean months or even years of waiting.

  • Minimal automation

When a new business process or process step is implemented, it’s rare for the implementors to fully understand what’s needed, and to anticipated the unintended consequences of their choices. Premature automation can lock in inappropriate or suboptimal design choices. Once a process or process step has been up and running live in a manual form for some time, it’s generally easier to see where (limited) application of software-enabled automation may bring benefits. Hence “software last”.

  • Try before you buy

Use a #NoSoftware solution live in your business to prove your process or process steps to trial the solution before committing to implementing a software-based solution. You may actually find that a software-based solution is in fact unnecessary, or can be much more limited in scope – and cost – than originally imagined.

Attending To Folks’ Needs

Implicit in the idea of #NoSoftware is the imperativeb of attending to folks’ needs – the primary focus of The Quintessential Group. Generally speaking, folks have little need for software per se. As the old adage goes; folks don’t need a 1/4″ drill so much as they need a 1/4″ hole. When considering the means for attending to – and meeting – folks’ needs, software is often the default, but rarely the optimal means.

Chat More?

We’d be delighted to discuss the idea of our #NoSoftware solution option and how it will be suitable for your business or organisation. Curious? Please get in touch.

– Bob

Further Reading

Seddon, J. (2019). Beyond Command And Control. Vanguard Consulting.

Blockers

Is it really beyond the bounds of credibility to imagine that we could all be twice, three times, four times better at delivering software? The data’s there (ISBSG). The real-world results and exemplars are there (Familiar, not least). The road-map, blue-print or manual is there (Quintessence). The support required to build the necessary environment is there (Hearts over Diamonds, Memeology, Organisational Psychotherapy).

So what’s holding back our industry, our software delivery organisations? Indifference? Ignorance? Learned helplessness? Lack of incentives? Vested interests? Fear? Something else?

I’m sure I don’t know the exact nature of the blocker*.  But it’s clear that there’s blockers.

– Bob

*I have my suspicions. But it seems that no one wants to even talk about it.

 

How To Run A Collaborative Knowledge Work Business

Collaborative knowledge work (CKW) is not like other kinds of work. And few realise this. Even fewer realise that CKW necessitates a kind of “management” entirely different from traditional management. So different as to be unrecognisable as “management”. 

As the world transitions to CKW as its predominant style of work, this realisation is spreading. And the ensuing confusion and distress spreads also. We see this already.

The Priorities for CKW

  1. Avoiding Cognitive Impairment

CKW involves, primarily, the use of folks’ brains. A.k.a. Cognition or cognitive function. Organisations that cultivate an environment conducive to CKW and “brain-work” are, however, few and far between. Much more often, environment-induced cognitive impairment is the order of the day, every day.

  1. Interpersonal Relationships

The second key aspect of CKW is the collaborative nature of the work. CKW involves folks working together to achieve shared goals.Thus, interpersonal relationships become paramount.

  1. Play

So, how to cultivate an environment conducive to cognitive function and relationship-building? I have found that play best enables and supported these things. Whereas in the above paragraphs I have used the word “work”, we’re better off when we substitute the idea of “play”. Can you see the connection between improved cognitive function and relationship-building, and play?

Aside: We can take some of the sharp edges off the unconscionable idea of encouraging “workers” to play on the company dime by using the term “serious play”. By justifying it as a key to innovation. And by further obfuscating the idea of free play by calling it “simulation” or “gamification”. But that’s only candy-coating.

At The Quintessential Group we’re putting this all into practice, as we did with great success decades ago at Familiar. We’d be delighted to share our insights, approaches, learnings and experiences with you, should you be interested.

– Bob

Further Reading

Schrage, M. (2008). Serious Play: How The World’s Best Companies Simulate To Innovate. Harvard Business School Press.

What If #10 – Somebody Discovered the Solution

What if somebody discovered the solution to the vexing question of “how to consistently deliver software products successfully – e.g. reliably, effectively, on-time, with quality, and with controlled costs”?

How would the software community react? I posit it would be just like the reaction of the medical profession to the discoveries of Semmelweis circa 1847. i.e. Ridicule, taking offence, and rejection.

How would the lay (business) people across various industries react? I posit they would remain ignorant, or rail against the suggestion that they examine their perspective.

How would the discoverer react? I posit he or she would becoming increasingly frustrated and eventually suffer a nervous breakdown and maybe die or kill themselves.

– Bob

Other Posts In This Occasional Series

What If #1 – No Management

What If #2 – No Process

What If #3 – No Telling

What If #4 – No Answers

What If #5 – Continuous Improvement Is Useless

What If #6 – Agile Nirvana

What If #7 – No Work

What If #8 – Agile Never Happened

What If #9 – What if we helped folks learn how to think, rather than teach them what to think? (Quickie)

What’s Holding Us Back

It’s become painfully obvious to me that a whole raft of unhelpful assumptions and beliefs is holding us back. And has been doing so for at least fifty years.

And by “us”, I’m referring here to the software industry, businesses, and society in general.

In my most recent books (Memeology, Quintessence) I explore these beliefs in detail and at length, but in keeping with my preference for short(er) blog posts, I’ll summarise…

Here’s some of the major assumptions and beliefs I’ve recently seen holding back organisations back from the success they espouse:

  • Specialists are desirable. Generalist and generalising specialists offer no value.
  • Reorganisations are the way to effect improvements.
  • Change, if ever necessary, is better managed, and in large lumps.
  • Dialogue is a waste of everyone’s time.
  • The only needs that matter are those of the elite (CxOs, managers).
  • It’s best not to describe “success” as this would only expose the elite’s agenda.
  • Culture is what it is – it’s not amenable to intentional change.
  • There’s not other possible organisational structure than hierarchy.
  • Change, when it happens, happens in isolation, independent of existing policies and rules.
  • We must recruit and retain talent, specialist talent. Talent is indispensable.
  • Interpersonal relationships are messy, and have next to no relevance to business results.
  • High pay is the (only) way to attract and retain talent.
  • Productivity ensues from hiring talent.
  • Efficiency is top priority, effectiveness a meaningless and useless term.
  • Business problems are always the fault of certain individuals.
  • Breaking the organisation into parts and managing these parts separately is the only way to go.
  • Extrinsic motivation is much more powerful than intrinsic motivation.
  • Evidence and instruction (telling) are the only means to effect changes in people’s behaviours.

…and so on, and so on. 

All the above assumptions are, of course, false, and proven false by decades of research. Yet nobody is listening, nor interested in the science. Our ignorance is humungous.

– Bob

“The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”

~ Peter F. Drucker

And in case you missed the original post:

The Future of Work

Blueprint For Effectiveness

How would you go about explaining the factors that contribute to a highly effective software development team, group, organisation?

In Quintessence (currently 24% complete), I’ve done it for you! But do you agree with it?

I invite you to take a look (extensive free sample now available).

– Bob

 

Irrelevant

It seems clear to me that my skills, experience and insights have become irrelevant to the majority of folks toiling in the software industries.

No Need

We might say that they have no need of my ideas or my help. 

And as my views and ideas are mostly directed at improving the effectiveness – and results – of software development efforts, I draw the inference that their employers and managers have no interest in such things. 

This seems a relatively recent phenomenon. Even five or ten years ago, organisations and managers seemed at least marginally more interested in productivity, effectiveness, success, and so on.

I suspect it’s connected to COVID and the consequent Great Resignation.

Solutions Ignored

Ironically, my works – Organisational Psychotherapy, the Antimatter Principle, FlowChain, Product Aikido, etc. – are an ideal fit to addressing the issues wrapped up in the Great Resignation. But I guess folks are already too resigned to bother.

What might be more relevant content for these times? “How to Find a Fulfilling Job”? “How to Suck Up to Your Boss”? “How to Give the Finger to the Man”? “How to Whack the Employees You Have Left”? “How to Look Like You”re Doing Something Without Risking Your Credibility”?  Probably more relevant content. But not quite my style.

If you’re one of the very few who haven’t given up just yet, enjoy studying new ideas and learning for its own sake, I’m always happy to help. Pro bono or pro pretio, either, both.

– Bob

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

%d bloggers like this: