Are ‘software developer competency” and “software product delivery” complementary, compatible, or oppositional?
We’re Still Working in the Dark Ages
Medievalism is a system of beliefs and practices inspired by the Middle Ages of Europe, or by devotion to elements of that period. Closely related to and encompassing Feudalism, and the Manorial system.
Despite many legal and social changes since the Middle Ages, from the perspective of folks working in organisations there’s not much difference between serfdom then and employment today. Employees are hired and remain employed at the whim of the Lords of the organisation, and dismissed with as little thought – or maybe even less thought – than serfs.
The relationship between employer and employees remains predominantly one of power-over. And although a relationship, it’s hardly ever a humane relationship. And thus hardly ever a positive contributor to organisational effectiveness.
Whilst any kind of universal solution remains a long way off, and dependent on widespread social change, individual organisations can address the issue and consequences through deploying ideas like nonviolence, the Antimatter Principle, and redefining the collection of The Folks That Matter. Above all, though, progress depends on us recognising the medievalism implicit in the way our work works, and our relationships with that, and each other. Are you bovvered?
Kahane, A. (2010). Power and Love: A Theory and Practice of Social Change. Berrett-Koehler Publishers, Inc.
how often do your managers lead? And how often do your leaders manage? And how often do they do little to zero of either of these things?
Psychological Safety – Oh! The Irony
The march of time seems to have judged “psychological safety” as a passing fad. Not that it’s an irrelevant idea – far from it.
I suspect psychological safety gained some acclaim because everybody wanted it for themselves. “Yes, please. I feel anxious, exposed and at risk when I speak out, so I’d really appreciate some psychological safety, thank you.”
We’ll skip over the unlikely prospect of any managers being interested in providing an environment of psychological safety (why would they need to do that?) and get straight to the irony.
I’ve spoken with some number of colleagues who all attest to feelings of anxiety, being exposed and being at risk of judgement by peers in the software community when they speak out about certain, possibly contentious or unpopular issues.
Aside : I suspect it’s more often fear of the consequences of speaking out that’s at the root of these anxieties, rather that fear of being judged per se.
The irony being, of course, that whereas individuals are fine with accepting psychology safety provided by others, they’re far less interested in extending psychological safety in turn.
What are you doing on a daily basis to extend psychological safety to others?
http://www.psychologytoday.com. (1 June 2015). Tired of Being Judged? Try This. | Psychology Today. [online] Available at: https://www.psychologytoday.com/us/blog/longing-nostalgia/201506/tired-being-judged-try [Accessed 13 Sep. 2021].
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?
“In reality, the Western way of managing is still based on the principles of Scientific Management where the goals of management is control and compliance to rigorous processes. The Toyota paradigm is much different; it is based on ongoing learning, capturing the learning for wide reuse, and continually improving the knowledge across generations of products. To do this takes a lot of management understanding and commitment to guide the change.”
~ Michael Kennedy
What’s the biggest constraint in every organisation?
Always, always, ALWAYS, it’s management thinking*. Specifically, it’s the collective assumptions and beliefs held in common across the organisation a whole. How will you exploit this constraint?
If your approach to running your business fails to recognise this, you will fail at least 90% of the time. And the other 10% will be pure luck.
*Irrespective of whether the organisation actually has “management” or not.
I’m not at all embarrassed to remind you that:
The things organisations have to do to make software development successful are well known. And equally well known is the fact that organisations will absolutely not do these things.
So, pretty much STUCK, I’d say.
How Come Hardly Anything Ever Gets Better?
“Since everyone was in favor of improvement and opportunities abound, there should be an epidemic of things getting better. That begged the question; why is hardly anything getting better?”
~ Philip Crosby
Who is Responsible for Quality Improvement?
Philip Crosby came up with 3 basic reasons:
- The highest paid and most talented people in a company do not work on improvement. They produce strategy books, planning manuals, marketing reports, five year plans etc that are shown like merit badges but are not used or implemented. Everyone is working hard on things that make little difference.
- People who understand a subject do not get help in determining a policy for improvement. Nationally known consumer advocate groups have no experience in quality management. Most business media experts talk about quality and yet their experience is limited. Getting a common definition of “quality” would be difficult and it has been overlaid with emotion.
- Management and labor do not understand each other. There are very few members of management that have ever actually done the work they supervise. Motivation of the workers is the most popular theme for quality improvementprograms. Yet it is management that needs to realize they are the cause of the problems by the way they manage. Union management falls into the same boat as company executives.
On June 24, 1980, Americans widely viewed a NBC documentary called “If Japan Can… Why Can’t We.” The program, part of NBC’s White Paper series, prominently featured Dr. W. Edwards Deming.
Two Suits, No Hoots
Two suits stood in the aisle of the busy open-plan office.
“These people really are dumb,” John said, “even whisper ‘the bottom line’ and they all jump to it.”
“Yup. No one realises that us managers are in it for ourselves, not the bottom line,” Ralph said.
John smiled. “Sure thing. Wouldn’t do to have them find out, though.”
“No problem. They’ve been so brainwashed by life that even if we shouted our self-interest, they’d not believe it.”
John raised his thumb. “Safe, then.”
Where’s the flaw in John and Ralph’s assumptions and beliefs?
Your REAL Job ~ Think Different blog post
Let’s say you’re driving along in your car, and you want to change your speed. Would you grab hold of the speedo needle and bend it, expecting the car to change speed accordingly?
Of course not. Yet this is how organisations often attempt to change their “culture”. Grab hold of the culture “needle”, bend it and expect the culture to change.
Like the car speedometer, culture is just a visual indicator instrument, a read-only device.
To actually change the speed of the car requires an understanding of how the throttle pedal controls the amount of air/fuel mixture entering the engine, how the engine is connected via the transmission to the wheels, and how the rotational speed of the wheels (minus tyre/road slip) dictates the speed of the vehicle. More simply, an understanding of how one’s right foot on the throttle controls the speed of the car, not the needle on the speedo.
Similarly with organisations, controlling the culture invites an understanding of how changing assumptions and beliefs (gas pedal) changes the culture, not bending the culture “needle”.
Awesomely Powerful New Ideas
Most organisations are very closed to new ideas about management (amongst other topics). Tech organisations are no exception in this regard.
Ideas that are new, or alien, come with a price tag of uncertainty and fear.
Uncertainty – will these ideas work for us?
And fear – what long-established rules will we have to change to make them work for us?
The ideas themselves are often as old as the hills. But for various reasons don’t make it past the motte and bailey of the organisations that could benefit from them.
BTW Through organisational psychotherapy, I help tech organisations open themselves up to awesomely powerful new ideas.
Here are just a few of the ideas with awesome potential benefits to adopting organisations:
- Agile Software Development ~ Beck, Gilb, et al.
- Compassionomics ~ Trzeciak
- Idealized Design ~ Ackoff
- Interactive Planning ~ Ackoff
- Lean ~ Ohno, Liker, Ward, Kennedy, Rother, et al. Incl Lean product development, lean software development
- Learning Organisations ~ Senge, Kleiner
- Metrics ~ Fenton, Gilb, et al.
- Organisational Excellence ~ Shingo, Juran, Peters
- Psychology ~ Deming, Schwartz, Ohno
- Quantification ~ Gilb
- Risk Management ~ DeMarco, Lister, et al.
- Statistical Process Control ~ Shewhart, Deming, Juran
- Systems Thinking ~ Ackoff, Deming, Seddon
- Tameflow ~ Tendon
- Theory of Constraints ~ Goldratt
- Throughput Accounting ~ Goldratt, Corbett
- Value Streams ~ Rother, Shook, et al.
- Variation ~ Deming, Tribus
- OODA Loop ~ Boyd
- Auftragstaktik ~ von Clausewitz
- Toyota TPS and TPDS ~ Ohno, Shingo, Toyota et al.
And some of mine:
- The Marshall Model
- Product Aikido
- The Antimatter Principle
- Organisational Psychotherapy
Adoption is all.
How are YOU going about opening up YOUR organisation to awesomely powerful new ideas?
Software Development at Scale
Scaled Agile – or scaling agile – seems like a hot potato at the moment. Here’s a few
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 (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
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, 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.
Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question:
“Why do so many well intentioned founders and companies end up creating management monstrosities?”
The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and Rightshifted outliers are known to be).
But Michele’s question is: “Why?”
Over twenty years and more, I’ve seen dozens of organisations up close and personal. In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.
Collaborative knowledge work is NOT like:
- Factory Work
- Office work
- Service work (e.g. Call centres, Help desks, etc.)
- Individual knowledge work
Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.
Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.
Assumptions and Beliefs
Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are similarly almost never aligned to effective working.
You may now be asking “Why is the category they assign almost never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).
Cost of Focus Revisited
[Recent conversations suggest that my post on Cost of Focus failed to explain the idea clearly enough for readers to grasp easily or quickly. As, for me at least, it’s a simple idea, I thought I’d summarise it in brief with a new post (this one).]
Cost of Focus
Let’s start with a definition in a nutshell:
Cost of Focus is the cost incurred when we fail to include key stakeholders* in our deliberations**.
* I generally refer to these folks, collectively, as The Folks That Matter™.
** By deliberations, I have in mind what old-school folks call “requirements capture” or “requirements analysis”, and what I, nowadays, refer to as “needs investigation”.
Put another way:
Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs.
Note: I could have chosen the name “Cost of Flawed Focus” (the cost of focussing on less relevant stakeholders and less relevant requirements), but this seemed a little less snappy than “Cost of Focus”.
Typically, the costs in question accrue from rejection of part or all of the delivered project / system / product / software application by one or more key parties (such as users) whose needs have not been adequately addressed – and these costs can be massive. In any number of cases, whole systems have had to be abandoned because one or more key stakeholder groups have refused to use the new system. And even when not totally abandoned, oftentimes major costs have accrued from the delays and extra work required to remediate the original errors of focus. (See also Cost of Focus’ kissing cousin – Cost of Delay).
The Folks That Matter™
[The following excerpt first appeared in my blog post The Folks That Matter™. I repeat it here for the convenience of the reader:]
Cost of Focus
Don Reinertsen states that the Cost of Delay – the financial or economic cost of delaying a given feature by prioritising another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.
I propose that Cost of Delay is a subset of the wider question stated above, i.e. the question of Cost of Focus.
By definition, we are failing to meet some folks’ needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.
Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.
FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong (prioritise less valuable features), and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary, black-and-white impact.
What is Cost of Focus?
Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.
“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”
– Donald G. Reinertsen
Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.
Put another way, until we have a means for deciding to whose needs to attend, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.
There are three questions I like to ask my clients upon our first meeting. You might find them equally useful in your own dialogues within your particular organisation. Here are the three questions:
1. Is anyone in your organisation at all interested in productivity (or quality, or effectiveness)?
Note: Many folks will express an interest in productivity, quality or effectiveness, but not act congruent with this espoused interest. You might like to look into the work of Chris Argyris to learn more about this phenomenon (see: espoused theories vs theories-in-use). You may also care to look at what’s really happening within the organisation for evidence of actual interest in e.g. productivity.
If your true answer to question 1 is “no”, then there’s not much point proceeding to the next question.
But if there are folks in your organisation at all interested in productivity (or quality, or effectiveness), then question 2 is:
2. Do all interested parties agree that folks’ collective assumptions and beliefs about work, the world of work, and how work should work is at the root of effectiveness a.k.a. productivity?
If your answer to question 2 is “no”, then I propose you might like to look elsewhere for your answers, rather than proceed to question 3.
But if there are enough folks in your organisation who can agree that collective assumptions and beliefs about work, the world of work, and how work should work is at the root of organisational effectiveness a.k.a. productivity, then question 3 is:
3. How will you go about affecting this collection of shared assumptions and beliefs – in ways which translate to meeting folks’ needs for increased productivity (or quality, or effectiveness)?
Note: In some organisations, maybe there are already some initiatives or actions in train intended to bring about such a change in shared assumption and beliefs.
I’d be very interested to hear your answers.
Beyond Command and Control – A Book Review
John Seddon of Vanguard Consulting Ltd. kindly shared an advance copy of his upcoming new book “Beyond Command and Control” with me recently. I am delighted to be able to share my impressions of the book with you, by way of this review.
I’ve known John and his work with e.g. the Vanguard Method for many years. The results his approach delivers are well known and widely lauded. But that approach is not widely taken up. I doubt whether this new book will move the needle much on that, but that’s not really the point. As he himself writes “change is a normative process”. That’s to say, folks have to go see for themselves how things really are, and experience the dysfunctions of the status quo for themselves, before becoming open to the possibilities of pursuing new ways of doing things.
Significant Improvement Demands a Shift in Thinking
The book starts out by explaining how significant improvement in services necessitates a fundamental shift in leaders’ thinking about the management of service operations. Having describe basic concepts such as command and control, and people-centred services, the book then moves on to explore the concept of the “management factory”. Here’s a flavour:
“In the management factory, initiatives are usually evaluated for being on-plan rather than actually working.”
(Where we might define “working” as “actually meeting the needs of the Folks that Matter”.)
Bottom line: the management factory is inextricable bound up with the philosophy of command and control – and it’s a primary cause of the many dysfunctions described throughout the book.
Putting Software and IT Last
One stand-out section of the book is the several chapters explaining the role of software and IT systems in the transformed service, or organisation. These chapters excoriate the software and IT industry, and in particular Agile methods, and caution against spending time and money on building or buying software and IT “solutions” before customer needs are fully understood.
“Start without IT. The first design has to be manual. Simple physical means, like pin-boards, T-cards and spreadsheets.”
If there is an existing IT system, treat it as a constraint, or turn it off. Only build or buy IT once the new service design is up and running and stable. Aside: This reflects my position on #NoSoftware.
John echoes a now-common view in the software community regarding Agile software development and the wider application of Agile principles:
“We soon came to regard this phenomenon [Agile] as possibly the most dysfunctional management fad we have ever come cross.”
I invite you to read this section for an insight into the progressive business perspective on the use of software and IT in business, and the track record of Agile in the field. You may take some issue with the description of Agile development methods as described here – as did I – but the minor discrepancies and pejorative tone pale into insignificance compared to the broader point: there’s no point automating the wrong service design, or investing in software or IT not grounded in meeting folks’ real needs.
I found Beyond Command and Control uplifting and depressing in equal measure.
Uplifting because it describes real-world experiences of the benefits of fundamentally shifting thinking from command and control to e.g. systems thinking (a.k.a. “Synergistic thinking” Cf. the Marshall Model).
And depressing because it illustrates how rare and difficult is this shift, and how far our organisations have yet to travel to become places which deliver us the joy in work that Bill Deming says we’re entitled to. Not to mention the services that we as customers desperately need but do not receive. It resonates with my work in the Marshall Model, with command-and-control being a universal characteristic of Analytic-minded organisations, and systems thinking being reserved to the Synergistic– and Chaordic-minded.