And Now For Something Completely Different…

Have you thought about what lies beyond the Agile horizon? Well, it’s something completely different. Companies are now shifting focus towards systems thinking and addressing whole-organization issues. With the changing demographics of the workforce, it’s essential that companies adapt accordingly. It’s no longer about processes, but about embracing culture changes to truly thrive in this dynamic landscape. Companies need to foster a more joyful, inclusive, and collaborative environment that promotes engagement, innovation and adaptability. Exciting times ahead, right?

 

Software Development: It’s Not Even Slightly About Tech Skills and Coding Practices

💡 What’s the undervalued secret sauce of software success? You’re in for a wake-up call as we reveal the overlooked ingredients that make or break software success in the business world.

➡ Blimey, it’s no surprise that most execs – those few that are even slightly interested in software development – reckon it’s all about tech skills and coding practices. But I’ll tell you, there’s more to this picture than meets the eye. Sure, being a dab hand at coding is somewhat useful, but in the context of business operations, it’s just the tip of the iceberg.

You see, the nitty-gritty of software development, especially in a business setting, also involves top-notch communication, teamwork, and adaptability.

And let’s not forget, building strong interpersonal relationships is a piece of cake for no one, but it’s a skill developers need to master to keep things from going pear-shaped.

A good understanding of the customer’s needs and the company’s goals is also crucial. After all, you can’t score a winner if you don’t know where the goalposts are. So, execs might choose to realise that there’s more to software development than just cranking code. And much more to hiring than the recruitment of code toads.

A successful software development team is the whole package. It’s not just about having a bunch of coding whizzes; it’s also about fostering a culture where everyone’s on the same page, working together as a community to bring work to fruition. Otherwise, businesses might find themselves up a creek without a paddle.

Beneath the Agile Mirage: Unmasking the Lipstick-Smeared Swindle of Modern Software Development!

💡 Prepare to embark on a thrilling exposé, where we unravel the tangled web of Agile’s alluring illusion, and reveal the startling truth lurking beneath its glossy veneer – a revelation that will leave you questioning everything you thought you knew about software development!

➡ You know, there’s an old saying that goes, “You can put lipstick on a pig and call it Agile, but it’s a waste of your time and annoys the pig.” It’s such an apt description of the Agile approach to software development, don’t you think? I mean, people talk about how Agile is the be-all and end-all solution to software development woes, but in reality, it’s just one big lipstick-covered pig.

Even when organisations follow Agile to the letter, it never seems to work out as expected. The whole system is supposed to be about flexibility and adaptability, but so often it just ends up being a convoluted mess. Sure, you have all these meetings, sprints, and stand-ups that give the appearance of progress, but it’s really just a bunch of people running in circles.

And let’s not even get started on the endless stream of buzzwords and jargon that’s constantly thrown around in Agile environments. It’s like some twisted game of corporate Mad Libs that doesn’t actually result in any tangible improvements.

So yeah, you can slap a coat of Agile lipstick on your development pig, but don’t be surprised when it doesn’t magically transform into a streamlined, efficient machine. More often than not, you’ll just end up with a frustrated pig and a whole lot of wasted time.

The Future is Now: Unleashing the Full Potential of Cutting-Edge Software Development Culture

For software developers, understanding the role of business culture in the development process can seem entirely irrelevant. Yet, business culture sets the tone for the company’s shared assumptions and beliefs about how work should work, and it can have a significant impact on the efforts, and quality-of-life of software developers.

One example of where the impact of business culture is particularly visible is in the thorny question of permitting or forbidding developers to talk with users and customers.

In many organisations, the relationship between software developers and users/customers is seen as strictly separated. In such cases, developers are not allowed to communicate with users/customers, and all communication is done through customer support teams or business analysts. This is primarily driven by the belief that developers cannot be trusted, and must focus solely on the technical aspect of the product, leaving customer interactions to others.

However, in some organisations, the opposite is true. Developers are actively encouraged to engage with users and customers, and they are seen as a vital link between the technical side of the product and the needs and desires of the customers. This approach is often driven by a culture that values transparency, customer satisfaction, and continuous improvement.

The impact of these differing business cultures on the role of software developers is significant. When developers are not allowed to talk to users/customers, they are limited in their ability to truly understand the customer’s needs and desires. This can lead to products that are technically sound but miss the mark when it comes to user experience and customer satisfaction. On the other hand, when developers are encouraged to talk to users/customers, they are more likely to create products that are not only technically sound but also meet the needs and expectations of the customers.

It is important to consider how changing the business culture can change the nature of what developers are allowed to do.

In conclusion, software developers play a crucial role in the development process, and it can help to understand the impact of business culture on their efforts. The question of permitting or forbidding developers to talk with users and customers is just one example of how business culture can impact the development process. By considering the impact of business culture and making changes as necessary, companies can ensure that their developers are empowered to create the best products possible and drive better business results.

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.

Unlocking the Secrets of the Heart: How Emotioneering is Revolutionising the Way We Create New Products

Emotioneering is a term coined by marketing expert Martin Lindstrom in his book “Buyology” to describe the use of neuro-marketing techniques to tap into consumer emotions in order to increase product appeal, revenues, and profits. While the concept of using emotions to sell products is not new, the use of neuro-marketing techniques such as functional magnetic resonance imaging (fMRI) and electroencephalography (EEG) to understand consumer emotions is a relatively new concept.

Despite the potential benefits of emotioneering, it appears that many companies are not yet using these techniques to increase their product appeal, revenues, and profits. There are a few reasons for this.

First, the use of neuro-marketing techniques is relatively new and not yet well understood by many managers and executives.

Second, many managers and executives may not see the value in investing in emotioneering as they may not understand how it can benefit their business. They may not be aware of the potential impact that emotions can have on consumer behavior and may not realise that tapping into consumer emotions can lead to increased product appeal, revenues, and profits.

Finally, some managers and executives may be hesitant to use emotioneering because they are concerned about the ethical implications of using neuro-marketing techniques to manipulate consumer emotions. They may be worried that using these techniques could be seen as unethical or manipulative, which could damage their company’s reputation.

Despite these challenges, it is likely that the use of emotioneering will increase in the future as more companies become aware of its potential benefits and as the spread of neuro-marketing techniques increases. This will help to alleviate concerns about the ethical implications of emotioneering and will ensure that companies are able to use these techniques to increase product appeal, revenues, and profits in a responsible and ethical manner.

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

Quickie: Muntzing

Hardware design / development has had Muntzing since the 1940’s. How about importing the idea into software design / development?

Could this facilitate the spread of #NoSoftware?

Or are programmers too self-indulgent to cut out much of their crap?

 

Building Things

We could describe my whole career as one of building things.

Early on, these things included software, hardware and tech products such as fax servers, compute clusters, compilers, interpreters, network systems, operating systems, development languages, applications, databases, and so on.

Later, things morphed to building teams, communities, software development and delivery groups, business units and tech companies.

Most recently, the things I build have morphed again, into techniques, approaches, tools and know-how applicable to building things.

Learnings

This post is mainly concerned with sharing some of the insights I’ve gleaned over the years. Insights into effective ways of building things:

Purpose

When embarking on building a new thing, I choose to dwell for a while on the purpose of the thing I’m building: Who’s it for? What will they use it for? How will they use it? What needs do they have that this thing willl address?

Needs

What does the Needsscape look like? How can we anticipate it changing over time? And how will we monitor and respond to those changes?

Intentionality

Doing things with a clear understnading of where those things fit in the scheme of things. Rather than just spinning the wheels for the sake of feeling busy.

Quality

Answer the question: “How will we ensure that what we’re building manifests the quality/qualities needed by all the Folks That Matter?

Risks

Manage all key risks facing us in bulding the thing (and in deploying, using it too). See Tom Gilb’s “All Holes In The Boat” principle (any one key risk can sink the whole effort).

Incrementality

Build things in small increments. Get regular feedback from all the Folks That Matter, early and often. Whilst continually remaining open to the system-wide impact of what’s being built.

Clarity of Communication

One can never have too much communication. One can never have too much clarity of communication. I prefer to use Quanitification as the means to improving clarity of communication.

Make Things Visible

Particularly with the kinds of things I’ve been building over the years, things nebuluous and more or less invisible most of the time, it helps to find ways to make e.g. progress visible and clearly understandable to all the Folks That Matter.

PDCA

Often called the Shewhart Cycle or Deming Cycle. PDCA (Plan-Do-Check-Act) offers a conceptual framework for building things:

• Plan what we’re going to do in the next days or weeks.
• Do stuff according to that plan.
• Check how well we did stuff (identify shortcomings)
• Act to address some shortcomings in our doing, so that the next cycle’s doing goes better.

Ownership

Deming banged on about the necessity for people to have pride in what they do. I find pride is enhanced through people feeling they own what they’re building.

Build Less

Build as little a possible. With the lowest tech possible. Commensurate with meeting folks’ needs. Remember YAGNI.

Summary

I don’t expect the above list to be of much use to anyone. Because, normative learning. C’est la vie.

– 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.com. Falling 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.

Quickie: Value Engineering And #NoSoftware

Invitation to discuss:

#NoSoftware is the acme (or logical extreme) of Value Engineering in software development?

28 Years Ago

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

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

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

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

28 Years On

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

Sigh. And deja vue.

– Bob

An Open Letter To All Organisations

Having been involved in software (and hardware) for some fifty years now, I thought it might be time to mark the occasion with this open letter to all organisations. Especially to those organisations engaged in CKW (Collaborative Knowledge Work), such as product development and software development.

Enormous Levels of Waste

You’re wasting 80% of your time, effort, money, and human potential on bullshit work*.

You may know this already, but are too embarrassed, fearful of the consequences, or indifferent to admit it.

Or maybe your owners have so much money that wasting 80% of your operating costs is of little or no consequence to them, and thus to you.

Or you may be unaware of the potential upside of adopting modern organisational practices, and of the downside of retaining your traditional management assumptions and beliefs**.

*Bullshit work: a.k.a. busywork – work that consumes time, effort and energy yet adds no value, and meets no needs of any of the Folks That Matter™️.

Rightshifting

The Rightshifting Chart illustrates just how much time and effort gets wasted in CKW organisations:

The Marshall Model

And the Marshall Model explains the source of such waste (it’s the consequence of the collective assumptions and beliefs a.k.a. mindset, or memeplex, of these organisations):

Over the years, various independent consultants have validated these models.

Consultation in Confidence

**If you’d like a brief, utterly confidential, and no obligation chat about how your organisation could benefit from wasting less of your time, energy and effort, please get in touch via e.g. LinkedIn: https://www.linkedin.com/in/bob-marshall-flowchainsensei-3a2a5b164/ – or via whatever channel you may prefer.

– Bob

Seeds of Failure

Agile has become widespread and popular mainly because it promises “improvements” without demanding that the decision-makers change. Of course, without people changing (in particular, managers changing their collective assumptions and beliefs) Agile has zero chance of delivering on its promises. It then becomes “just one more packaged method to install in the development teams” – and just one more debacle.

As the French say:

“Plus ça change, plus c’est la même chose”.

Thus Agile carries with it the seeds of its own inevitable failure.

“But what if managers DO change?” I hear you ask.

Well, if they change themselves in ways that move them and their organisations towards the quintessential, they won’t choose Agile.

Seeds of Success

And if you’re wondering what the seeds of success might look like, you may like to take a look at my recent book “Quintessence” (Marshall 2021).

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

Rightshifting and Quintessence

Long-time readers of this blog will already be familiar with the concept of rightshifting. 

Shifting an organisation to the right (i.e. in the direction of increased organisational effectiveness, and towards the quintessential) is not for the work-shy or indolent. Yet the rewards are massive. 

Whilst the Marshall Model provides a general framework for such rightshifting, there’s not been a detailed roadmap describing the shifts necessary to acquire such improved effectiveness. 

My most recent book, “Quintessence”, provides just such a roadmap (or blueprint). It details the shifts in collective assumptions and beliefs necessary to become a highly effective knowledge-work organisation. Shifts of which significant outliers such as Zappos, WL Gore, Morning Star, Semco, and a host of others have demonstrated the benefits.

Go take a look and gaze in awe at what is possible in the way of improvements. 

– Bob

Further Reading

Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Memeology: Surfacing and Reflecting On the Organisation’s Collective Assumptions and Beliefs. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub). 

Effectiveness

It’s long been observed that folks commissioning i.e. product developments have a natural tendency to believe that quality costs money. Which is to say that they tend to believe that a higher quality product costs more to develop and deliver into the market. Even though Phil Crosby put the lie to this fallacy decades ago with his observation, detailed in his book of the same name, that “Quality is Free”.

So it is with effectiveness. I’ve met many folks who unwittingly assume that having their organisations become more effective is going to raise costs, and involve increased time, attention and effort.

Again, nothing could be further from the truth. Highly effective organisations run more smoothly, more predictably and with higher productivity and significantly lower costs. This is, for me, the essence of effectiveness.

How about you? What comes to mind when you hear the term “increased effectiveness”?

– Bob

Product Development Success

What constitutes “success” in the product development arena, and how might we quantify it, or even measure it?

What is the ultimate unit of measure for success?

Some folks say it’s “life cycle profit impact”. But it really isn’t. Nobody gives a hoot about profit (cf. Deming’s First Theorem). Nor do all but a few take a long term (whole life cycle) view of the products in their product portfolio.

In my experience, the ultimate unit of measure for success in product development is the wellbeing of the folks involved. In particular, the personal wellbeing of executives and senior managers with skin in the game. And to a much lesser extent, the personal wellbeing of the middle managers, developers, and customers (most often in that order).

Of course, nobody wants to talk about this, least of all the beneficiaries. So the measures of success remain undiscussable, and spurious proxy measures such as profit are introduced to lull the unwary and naive.

– Bob

Further Reading

Think Different. (2019). Your REAL Job. [online] Available at: https://flowchainsensei.wordpress.com/2019/11/11/your-real-job/ [Accessed 21 Jan. 2022].

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)

Quickie: How To Build A Great Product

Seems like NOBODY in management or product consulting has heard the old adage:

Q: How do you build a great product?

A: Build a great team and they’ll build the great product for you.