Archive

Software development

Agile Expert, Deprecated

Are you an Agile Expert? Do your revenues depend on your Agile chops? Do you see the writing on the wall?

Newsflash: You’re as obsolete as a buggy-whip maker. Agile Main Street is closing. Your markets are shrinking. You’ll only be dealing with the laggards and bad-faith actors from now on.

iu

As a player in technology markets, you know all about technology adoption curves. We’re fifteen years or more past the Chasm for Agile. And tech markets move much faster than FMCG, manufacturing and other such markets.

What’s the next technology curve where your existing cumulative assets can play best and earn the greatest margins? What legacy issues are holding you back? Are you another victim of the Sunk Cost fallacy? What new assets must you acquire to play well on the new curve? What actions must you take today to best position yourself for tomorrow? Times they are a’changing (as always). Are you changing with them?

And what resolutions do these questions bring to mind?

– Bob

Here’s a bunch of things that readers of this blog – and by extension, software folks and execs generally – are not interested in:

Zeitgeist

What is the Zeitgeist of the software industry, and software community?

I thought I knew, but upon reflection, I’m pretty sure I don’t have a clue.

If I had to guess, I’d say it involves indifference, learned helplessness, and a Mexican standoff between management and developers. But I could be way off base.

Your thoughts, observations?

– Bob

 

 

 

If you love books, and in particular books about business, organisations and software and product development, you’ll probably love Memeology. There’s more than 90 chapters, and almost every chapter has a host of references, in context.

(Aside: I’ve personally read almost every book and paper referenced in Memeology).

PS. I expect Memeology to reach 100% completion in just a few days now.

Category errors (or category mistakes) abound in life, and work. In particular, there’s the category error of regarding collaborative knowledge work – such as software or product development – as like some other category of work. And then expecting the work to work like that other – probably more familiar – category of work.

This only and ever leads to management monstrosities.

Here’s the thing: does your organisation make this kind of category error? And the consequences?

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

Industrialised Learned Helplessness

We often call something “industrialised” when we wish to suggest that it happens on a large scale, and has been dehumanised in some way. 

In many of my Organisational Psychotherapy gigs over the past decade I have seen learned helplessness writ large in individuals organisations, especially in development teams.

Curiosity Died

Ten or twenty years ago software folks seemed interested in new ways of doing things (in particular Agile software development). Curiosity was widespread and optimism too. There was a sweet scent of change for the better in the air. As far as I can tell, this has all but entirely disappeared now. 

Software folks seem more and more resigned to the fact that organisations – to wit, management – will just NOT do those things necessary to making software development successful. 

 

Is there any hope left in the software industry? Or are folks simply resigned to endless frustration and ineffectiveness?

– Bob

How Much Do You Care?

In recent times I have noted an upswing in the frequency of conversations about the ethical dimension of software development. Although still early days, many aspects of the social implications of software are beginning to receive more attention.

Effective Software Development

The dog’s breakfast that is Agile in the real world today exemplifies, for me, a key aspect of these ethical questions. Not that ethical questions are at all limited to the software industry.

What am I talking about? I’m talking about how people with a clear understanding of e.g. Agile software development (yes, there are some) tolerate, even support, a pallid, ineffective version in their workplace because their jobs and livelihoods depend on not rocking the boat. I’m talking about how folks go along with an ineffective and crippled approach for an easy life. Although how easy is it to stand by and watch project after project fail or limp along, with the consequent frustration and angst for all concerned?

With the oft-reported woefully low levels of employee engagement in most organisations, it’s hardly surprising that people just let such things slide by with little or no comment, complaint or action.

Satyagraha

We might take a leaf out of Gandhi’s nonviolent campaign playbook. He placed the idea of satyagraha at the heart of his toolkit of civil resistance. What is satyagraha? Online references describe it as “truth-force” or “the force that is generated through adherence to truth”.

Note: In this context, I choose to regard “truth” as referring to ethical imperatives such as justice, fairness and righteousness, and not simply factual truth. And yes, everyone has their own “truths” a.k.a. assumptions and beliefs. As do groups, such as organisations.

At the core of satyagraha is the willingness to suffer for the truth. Spiritual, emotional and physical suffering, borne in public, serves to emphasise the degree to which the satyagrahi care about the issue upon which they are campaigning.

Do You Care Enough to Suffer?

In the case of Agile, as with other aspects of how organisations run themselves today, it’s fair for folks to ask:

“Is it any of my concern? Don’t senior people with much higher pay grades than me hold the responsibility for these things?”

How is this any different from the old defence “I was only following orders?” 

Do you care? Do you care enough to start to say “No.”? In a civil and polite way, of course.

Are you prepared to suffer to see things become better for all concerned?

– Bob

Scope of Ignorance

Most of the developers and development teams I used to work with when I was a software development consultant had a relatively narrow view of the skills and knowledge necessary to be “competent developers”. Here’s an illustrative graphic:

Generally, to make progress on improving things, and to earn the moniker of “software engineers”, a wider scope of skills and knowledge was necessary. Not only did these development teams lack this wider scope, they were both ignorant of the many additional areas of knowledge and resistant to learning about them. The common response was “What are all these strange topics, and NO WAY! do we need to know about them”:

Aside: Now I’m an Organisational Psychotherapist, their ignorance is no issue – and no stress – for me. They can learn or not learn in their own time. Progress is on them (and their higher-ups).

– Bob

How To Predictably Deliver Great Software

What is “Great Software“?

Great software is software that meets the needs of the Folks that Matter™. The more needs met, and the more comprehensive the coverage of all the Folks That Matter, the “greater” the software.

Aside: I invite you to consider how the Needsscape plays into the above definition.

Ironically, when we dig into the needs of all the Folks That Matter, we find that great software often means no software. Strange?

Further, we regularly find that the needs of the developers and ancillary development staff trump the needs of the users and other customers. So we get software, even though users and other customers rarely need it.

Predictability

Let’s assume for a moment that predictability (e.g. due date performance) is among the needs of some of the Folks That Matter. In this case, predictability is part of the “great” we were just talking about.

Predictability comes from anticipating and managing risks – actively, deliberately and competently. Formal approaches such as set-based concurrent engineering (SBCE) help manage the risk of finding oneself unable to bring a particular aspect of the solution to completion, for a variety of reasons. Identifying the Folks That Matter and their needs helps manage the risks involved in building the wrong thing, as does consideration of the Cost of Focus. Predictability demands we keep on top of all significant risks. (See: the All Holes in the Boat principle Cf. Gilb).

Approach

Know what needs you’re attending to. And whose.
This is not always possible, a priori. So identify as many of the Folks That Matter as you can (expect more to come to light as you proceed). Concurrently, investigate their needs through quickly delivering early exploratory things such as mock-ups, paper-prototypes, sketches of various kinds, and conversations. “Quickly” here means in a few hours, or days at most. Expect to have to iterate on this.

Many developers assume that someone else will be handing them a list of the Folks That Matter along with a definitive statement of the needs of those folks. If that other party is competent and sufficiently resourced, this can work. I’ve never seen it. I prefer to have the developers own this crucial information, and the gathering and updating thereof too. This is not popular in many organisations, shining a light as it does on the inadequacies of the way the work works, the management, the analysts, the product owner(s) and so on.

In parallel with these investigations, make a start on building the solution. In particular, those parts of the solutions which seem relatively stable, and where you feel the needs are relatively well understood. This can even involve writing some software – if you really must. Manage the risk of not knowing how to build certain things through e.g. “Spikes” and other risk mitigations.

Done

“Surely there’s more to it that this?’ I hear you ask.
Well, actually, no. We’ve been hoodwinked into thinking that software development is “the most complex endeavour known to man” ~ Jim McCarthy

Actually, if tackled appropriately it’s quite a pussy cat. People make it much more difficult than it really is. Will the industry ever grow up?

– Bob

Further Reading

Waltzing With Bears ~ Tom Demarco and Tim Lister
Sketching User Experiences ~ Bill Buxton
Principles of Software Engineering Management ~ Tom GIlb
Beyond Command and Control ~ John Seddon

Memeology For Developers

“The greatest determinant of organisational performance is the way we think about the design and management of work.”

~ John Seddon

And, therefore, the greatest determinant of the performance of self-organising software development teams is the way those teams think about the design and management of their work.

Aside: For teams and individuals that are not self-organising, the original quotation pertains.

Memeology is For Whole Organisations, not Teams

I suspect many developers and development teams might see “Memeology” (my new book) as irrelevant to them. As a book that lists memes of little interest, and as a book that surfaces assumptions and beliefs more relevant to senior management – which, to be fair, is the books primary audience.

And yet, as organisational psychotherapy speaks to an organisation’s collective psyche, “Memeology” invites addressing of the collective assumptions and beliefs of everyone in the organisation. So, as far as involving people in the discussions around “Memeology”, I’d suggest encouraging everyone to become involved.

In most organisations, however, local rules apply. Different groups may well be interested in memes specific to their own specialisms. For example: Finance, Operations, Logistics, HR, and yes, Product and Software Development.

I’m chary of promoting local optimisations – for example, the improvement of software development practices in isolation from the rest of the organisation. But developers in Analytic-minded organisations outnumber by far those in Synergistic-minded organisations (the latter being more prone to taking system-wide issues into consideration). Are we to deny a self-help book such as “Memeology for Developers” on the grounds that discussing development-specific memes in isolation might perpetuate specialisms and concomitant local optimisations confined to the “development silo”?

Prospective Content

Here’s just a few of the many memes that “Memeology for Developers” might cover:

  • Requirements (when to capture them, who’s responsible for such capture, formalisms and representations, etc.)
  • Code ownership (individual, group, other, and the trade-offs and consequences)
  • Defect tracking
  • Performance (of the software when in production)

I have a long list of such memes. I’m sure you can suggest memes for such a list, too.

Question

Does the idea of “Memeology for Developers” pique your interest? Would it be a useful book, promoting as it would not only the surfacing and reflection on the assumptions and beliefs developers hold in common, but also promoting experimentation to improve self-organising software teams and the way they work?

I’d love to hear your thoughts.

– Bob

First Principles

I was reading the other day about how Elon Musk “reasons from first principles“. And I was thinking, “Well, d’oh! Doesn’t everyone do that? I know I do.” And then, upon reflection, I thought, “Hmm, maybe most folks don’t do that.” I certainly have seen little evidence of it, compare to the evidence of folks reasoning by extension, and analogy. And failing to reason at all.

Now, allowing for journalistic hyperbole and the cult of the celebrity, there may just still be something in it.

So, in case you were wondering, and to remind myself, here’s some first principles underpinning the various things in my own portfolio of ideas and experiences:

The Antimatter Principle

The Antimatter Principle emerges from the following basic principles about us as people:

  • All our actions and behaviours are simply consequent on trying to get our needs met.
  • We are social animals and are driven to see other folks’ needs met, often even before our own.
  • We humans have an innate sense of fairness which influences our every decision and action.

Flowchain

Flowchain emerges from the following basic principles concerning work and business:

  • All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
  • When Cost of Delay is non-trivial, the speed of bringing new products and feature to market is significant.
  • Flow (of value – not the Mihaly Csikszentmihaly kind of flow, here) offers the most likely means to minimise concept-to-cash time.
  • Autonomy, mastery and shared purpose affords a means for people to find the intrinsic motivation to improve things (like flow).
  • Building improvement into the way the work works increases the likelihood of having sufficient resources available to see improvement happen.

Prod•gnosis

Prod•gnosis emerges from the following basic principles concerning business operations:

  • All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
  • Most new products are cobbled together via disjointed efforts crossing multiple organisational (silo) boundaries, and consequently incurring avoidable waste, rework, confusion and delays.
  • The people with domain expertise in a particular product or service area are rarely, if ever, experts in building the operational value streams necessary to develop, sell and support those products and services.  

Emotioneering

Emotioneering emerges from the following basic principles concerning products and product development:

  • People buy things based on how they feel (their emotional responses to the things they’re considering buying). See: Buy•ology by Martin Lindstrøm.
  • Product uptake (revenues, margins, etc.) can be improved by deliberately designing and building products for maximum positive emotional responses.
  • Quantification serves to explicitly identify and clarify the emotional responses we wish to see our products and service evoke (Cf. “Competitive Engineeering” ~ Gilb).

Rightshifting

Rightshifting emerges from the following basic principles concerning work in organisations:

  • The effectiveness of an organisation is a direct function of its collective assumptions and beliefs.
  • Effectiveness is a general attribute, spanning all aspects of an organisation’s operations (i.e. not just applicable to product development).

The Marshall Model

The Marshall Model emerges from the following basic principles concerning work in organisations:

  • Different organisations demonstrable hold widely differing shared assumptions and beliefs about the world of work and how work should work – one organisation from another.
  • Understanding which collection of shared assumptions and beliefs is in play in a given organisation helps interventionists select the most effective form(s) of intervention. (Cf. The Dreyfus Model of Skills Acquisition).

Organisational Psychotherapy

Organisation psychotherapy emerges from the following basic principles concerning people and organisations:

  • The effectiveness (performance, productivity, revenues, profitability, success, etc.) of any organisation is a direct function of its collective assumptions and beliefs about the world of work and how work should work.
  • Organisations fall short of the ideal in being (un)able to shift their collective assumptions and beliefs to better align with their objectives (both explicit and implicit).
  • Having support available – either by engaging organisational therapists, or via facilitated self-help – increases the likelihood of an organisation engaging in the surfacing, reflecting upon, and ultimately changing its collective assumptions and beliefs.

– Bob

Automate All the Things!

Or not. I prefer not. 

As John Seddon states in his most recent book, it’s far more useful to fully understand customers’ needs, through e.g. simple physical means, like pin-boards, T-cards and spreadsheets, before considering any automation.

And even then, automation has at least two fundamental flaws:

Inability to Cater to Variation in Demand

Automation and automated systems, presently and for the foreseeable future, cannot encompass variety in demand. As we’ve come to relate to the Little Britain meme “ Computer says no”. Customer demand inherently has variation. Thus, automation leads to a poorer customer experience, as many customer needs are handled poorly, or not at all. I cite the British Gas website and customer experience as a particularly egregious example.

Employment 

Let’s also look at the bigger picture of social cohesion, of which people having jobs is a part. Jobs give people meaning, status, and something to do. As well as greasing the wheels of commerce – employed people have disposable income which contributes to companies’ revenues.

The idea of Basic Income is all very fine (I’m a fan) but that concept has some major wrinkles to iron out before it becomes a shoe-in.

In the meantime, how about we try to create businesses – and other organisations – that provide meaningful employment to more people, rather than fewer? Will that negatively impact profit margins? I doubt. And there’s always Deming’s First Theorem in any case.

More and more often, the Software Industry is being called upon to live up to its fine moral pronouncements. Automation is an item in the negative column on that balance sheet.

– Bob

%d bloggers like this: