Archive

Innovation

Innovation Revolution: How a Culture Change Can Ignite Breakthroughs

The Thinking Environment is a concept which aims to promote the creation of spaces enabling people to think more effectively and creatively. It’s based on the idea that the quality of a person’s thinking is directly related to the quality of the attention they receive. (Note the resonance with the #AntimatterPrinciple – Attend to Folks’ Needs).

The Thinking Environment is built on a set of ten principles, which include giving attention, asking incisive questions, giving equal turns, and appreciating diversity. These principles are designed to create a space where people feel safe and valued, and where they can engage in deep, reflective thinking. The goal is to create a collaborative space where people can share their ideas, explore new possibilities, and solve problems together.

One of the key principles of the Thinking Environment is the idea of giving attention. This means that when someone is speaking, everyone else in the group is focused on listening and understanding what they are saying. This helps to create a sense of safety and trust, which in turn encourages people to speak more openly and honestly. When people feel that they are being heard and understood, they are more likely to engage in creative thinking and problem-solving.

Another important principle of the Thinking Environment is asking incisive questions. These are questions that are designed to help people think more deeply and critically about a particular issue. By asking incisive questions, facilitators can help to expand people’s thinking and encourage them to consider new possibilities.

The Thinking Environment is also characterised by giving equal turns. This means that everyone in the group has an opportunity to speak and contribute their ideas. This helps to ensure that everyone’s perspective is valued and that no one person dominates the conversation.

Finally, the Thinking Environment invites appreciation of diversity. This means that differences in opinions, experiences, and backgrounds are seen as a strength rather than a weakness. By embracing diversity, the Thinking Environment creates a space where people can learn from one another and gain new perspectives on complex issues.

Overall, the Thinking Environment is a powerful tool for fostering creativity, collaboration, and innovation. By creating a space where people feel safe, valued, and heard, it helps to unlock the full potential of individuals, teams and organisations. It’s a framework that can be applied in a wide range of settings, from business meetings to classrooms, and it has the potential to transform the way we think and work together.

 

Revolutionise Your Development: The Benefits of Ditching Version Control

Avoiding the use of version control in software development may seem like a daunting task, but there are several advantages to doing so.

First, it can save time and resources. Without version control, developers do not need to spend time committing changes, merging branches, or resolving conflicts. This can lead to faster development and fewer delays in the project.

Secondly, avoiding version control can also simplify the development process. With fewer tools and processes to worry about, developers can better focus on the needs of the Folks That Matter™, and on meeting those needs. This can lead to improved customer satisfaction, fewer bugs and a more streamlined development approach.

Thirdly, avoiding version control can also lead to greater flexibility in the development process. Without the constraints of version control, developers can work on code in any way they see fit. This can lead to more creative solutions and a more efficient development approach.

Lastly, avoiding version control can also lead to greater collaboration among team members. Without the need to constantly merge branches, developers can work on different parts of the codebase at the same time, leading to faster development and a more efficient workflow.

In conclusion, while version control is a powerful tool in software development, there are advantages to avoiding its use as well. By doing so, developers can save time and resources, simplify the development process, increase flexibility, and improve collaboration among team members.

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 imperative 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

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