Tumbleweed

Tumbleweed: A dusty aggregation of plant matter rolling along the ground by the desert wind. A cliche of cowboy movies, emphasising silence or stillness, e.g. as the hero rides into an apparently deserted frontier town. Often used in connection with the death of a conversation.

Also, that sensation I get whenever I mention an idea of mine to peers and colleagues.

Meaningful Conversations

Over the course of more than twenty years, I guess I’ve had a meaningful conversation about my ideas (FlowChain, Marshall Model, Prod•gnosis, Flow•gnosis, Product Aikido, Antimatter Principle, etc.) maybe two or three times, total.

I’ve always wondered what it might take to up that count.

Reversing the tables for a moment, I sometimes find myself in the position of being invited to consider and discuss someone else’s idea. Reflecting, I’ve found it difficult to engage with such discussions. In retrospect, asking myself why that might be, I guess the following factors come into play:

• I struggle to see the value or benefit of the idea. Absent some insight into same, a discussion can feel purely arbitrary, academic or theoretical.
• I have some reluctance to discuss ideas in the abstract, finding it invites judgment (something I try to avoid) and icky ad hominem considerations.
• My frame of reference is often way off from that of the originator of the idea. The prospect of getting onto the same page (or even close) seems like a mountain to climb, for little return.
• We’re not best equipped to discuss ideas, preferring as flawed humans to stick to our comforting biases, assumptions and beliefs rather than engage in mutual exploration with the risk of discomforting changes.

I guess that having stimulating discussions on ideas generally relies on a normative situation. In other words, unless and until someone begins to implement an idea, begins to try it out in their context, to wrestle with making it concrete, there’s little chance of any deep and meaningful discussions.

– Bob

 

Ambitious

Ever since I can remember, it’s been my ambition to make a difference to the software industry at large. And not just do a good job for individual clients or employers.

I work with clients – and occasionally, employers – to help them, of course. But my main focus is on better understanding the domain of software development – and business, too – at the organisational and industry level, and to share that understanding with as many folks as are interested.

Don Quixote

I accept it’s a largely – if not entirely – quixotic ambition. And yet individuals have occasionally made a difference in other domains.

“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it’s the only thing that ever has.”

~ Margaret Mead

Self-aggrandisement, kudos or fame is not my aim. Rather, even early in my career, I saw the frustration and suffering of fellow developers in positions of powerlessness, writing software that rarely if ever saw the light of day, rarely if ever making it into the hands of users, rarely if ever pleasing the folks for whom the software was intended. And having to cope with endless, senseless handicaps to getting anything done.

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker

Even back then I was determined to do what I could to alleviate folks’ frustrations. To increase the likelihood of the fruits of their labours making it into “production”. Most developers I’ve ever met have shown a strong urge – we might say need, even – to make a positive difference in the world, albeit mostly through software features or products.

What could be more quixotic than wanting to help developers (and more recently, other software folks, such as managers and executives) who seem to not want to help themselves?

– 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

An Overabundance of Planning

“The minimum you can get away with is always far less than you think you need.”

~ @FlowchainSensei

A Common Objection

“We’d be inundated if we attended to even a fraction of all the needs of all the Folks that Matter” is one common objection I regularly hear to the Antimatter Principle.

And yet, in most software development projects, the team is inundated with things to do, based on “the Plan” – regardless of whether that’s a big up-front plan, or an incremental plan (running backlog) assembled by degrees over time. A mountain of work (features, tasks, etc.) stretching out to the misty blue horizon, and back to the dawn of (project) time.

Research (see, for example, Capers Jones’ book “Assessment and Control of Software Risks”) highlights that much of what gets planned, and thus gets done, is pointless and proves unnecessary when (finally) made available to users. This reality is also reflected in the now highly controversial series of CHAOS reports from the Standish Group.

Specious

So, I regard the aforementioned objection as specious. Not intentionally so, most often. But specious never the less.

For me, “Attending to Folks Needs” means doing the least (responsibly) possible, and then seeing if the need (or a need) of the folks in question has been met. Most often those need(s) will not have been entirely met – and maybe not even partially – but the team then has the option to have another go – based on some solid information.

This approach has at least two benefits:

• The person (customer, user, etc.) in question will feel that they matter, that their opinion counts, and that the team is focussed on them as a human being.
• The team will have solid information upon which to validate or invalidate their earlier guesses (and yes, they will always be guesses until so validated).

At some point, it’s likely all the critical needs of all the Folks That Matter will have been met. And that point will like have arrived much earlier that with more traditional approaches. And with reduced costs and effort.

– Bob

Afterword

Some readers may argue that the above approach looks a lot like Agile. In practice (sic) I see enough differences to reject that comparison. For a deeper insight into why, may I invite you to consider #NoSoftware.