Archive

Management

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Red Lines

There’s been a lot of talk about Theresa May’s “Red Lines” in the media recently.

Every organisation I’ve ever known has had their own Red Lines – ideas, principles, practices and policies which are deemed unacceptable, beyond the pale. Many of these latter would make the organisation markedly more effective, efficient or profitable, yet are ruled out.

Here’s a list of such ideas, in roughly increasing order of benefit and unacceptability both:

Transparency of salaries
Attending to folks’ needs
Nonviolence
Restorative justice (vs Retributive justice)
Self-organising / self-managing teams
No estimates
No projects
No tools
No software
Defect prevention (ZeeDee) approach to Quality (vs Testing / Inspection)
Employees choosing their own tools, languages and development hardware
Employees designing / owning their own physical workspace(s)
(colour schemes, lighting, furniture, floor plans, drinks machines, games etc.) 
Employees choosing their own ways of working (methods, processes)
Organising to optimise Flow (vs costs)
Employees choosing their own working locations (office, cafe, remote, etc.)
Employees choosing their own working hours (incl. hours per day / week)
Employees forming their own teams
Employees guiding their own training and career, skills development
Employees hiring their own peers (and coaches)
Paramountcy of interpersonal relationships and social skills (vs tech skills)
Organisational Psychotherapy
Teams appointing their direct managers
Teams appointing their senior managers
“Open book” financials
Employees choosing their own salaries and terms of employment
Teams awarding themselves their own bonuses
No managers (alternatives to control hierarchies)
Fellowship (No positional leadership)
Do nothing that is not play

Where does your organisation draw its red lines – and how much more effective could it be if it redrew them?

– Bob

 

Congruence

What if the last twenty years has been another classic example of software developers solving the wrong problem?♥

What if “agility” was never the issue as far as business was and is concerned? What if business agility is NOT the most useful response to, or strategy for, life in a VUCA world?

We hear so much about the need for agility. It’s now a given, an unchallenged assumption. Maybe even an undiscussable assumption? Well, I’m challenging it. And in the spirit of this blog – always having an alternative to offer – I propose congruence as a more useful response to the challenges of a VUCA business environment.

Agility: the power of moving quickly and easily; nimbleness.

Congruence: Similarity between self-image and actual experience.

Carl Rogers stated that the personality is like a triangle made up of the real [or actual] self, the perceived self, and ideal self. According to Rogers, when there is a good fit between all three components, the person has congruence. This is a healthy state of being and helps people continue to progress toward self-actualisation.

Applied to organisations, we can say that an organisation is made up of the real [or actual] organisation, the organisation as it perceives itself, and its ideal self. When there is a good fit between all three components, the organisation has congruence. This is a healthy state of being and helps the organisation progress toward being all it can be.

Without congruence, organisations won’t know what to do with agility, or how to get it. Without congruence, a VUCA environment presents challenges which incongruent organisations are poorly equipped to meet.

So, forget the past twenty years and the search for agility. Congruence is the thing.

– Bob

Footnote

♥ It was a bunch of software developers that invented and promoted the idea of agility (for software development) some twenty years ago now. Businesses everywhere have seized on this prior art in their attempts to cope with the upswing in perceived volatility, uncertainty, complexity and ambiguity in the business environment.

PS

The same argument also applies to the birthplace of the agility meme: the software development silo. Forget the past twenty years and the search for development agility. Congruence is the thing.

Management Must Manage

Years ago, when I was starting out in my study of management methods, I came across ITT and its then president, Harold S. Geneen. Setting aside his connection with Phil Crosby and the ZeeDee (Zero Defects) quality movement, Geneen was famous for many things, including one quote which has stuck with me ever since I first heard it:

“Management must manage.”

What a soundbite!

Taken at face value, it’s a homily. Management must manage. Those with management responsibilities must execute those responsibilities (rather than dicking around with other things). “Well, of course. What else would they do?”

But there’s another meaning I choose to also find within. Management must manage: when we have people appointed to management positions, those people are the ones that must manage, not some others.

The whole Agile shambles, most often labelled AINO (Agile In Name Only), stems largely from ignoring this second interpretation of Geneen’s admonition.

Early Agilists, wanting to escape from the oversight of managers who had different opinions about how to manage software development, created Agile to wrest de-facto management responsibility from those managers. Thus grew the lame-assed version of self-organisation and self-managed teams so widespread today. I say lame-assed because almost no Agile team is self-managed. How could they be, when managers still have the authority and positional power to manage?

So we have instead a festering conflict of responsibilities, causing confusion and resentment all around, and dragging down engagement and productivity. Agile can “work” when the split of management responsibilities are made crystal clear for all concerned. And when that split has the blessing of management. This is almost never the case.

So, management must manage. Not developers. Not dev teams.

That sucks. Until we realise that it can be no other way. And even then, it still sucks, unless dev teams themselves have the responsibility and authority to manage. Where the dev teams are the management. Then we have the best of both worlds. A world of autonomy, mastery and purpose. A world of engaged people aligned to a common purpose and a common approach.

– Bob

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

Cost of Focus

Or, more specifically, the cost of suboptimal focus – the cost of focusing on some (less relevant) needs of some Folks That Matter to the detriment or neglect of other (more relevant, valuable) needs of other Folks That Matter.

If we commit our (always limited) resources ineffectively, our returns (we might call this ROI) will likewise fall short of what would be possible if we committed our resources effectively, or optimally.

How Do We Decide?

How we as a individual, team, group or organisation decide who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to?  How do we get to know what folks need, and who to ask about the details of those need? How do we choose whose needs we can successfully discount or defer when the inevitable resource (time, money, effort) crunches come? Who matters and who does not? Which needs are more relevant, valuable (with respect our chosen Goal) and which, less?

It might be useful to have some heuristics, or policy, or other forms of guidance, to guide us in decisions on including, excluding and prioritising folks and their needs? Personally, if it were entirely up to me, I’d go with the general principle describe by Goldratt and summarised in my post “What is Value?“.

By way of a quick summary of that post:

Focus on those things that relax the customers’ constraint, so as to increase the overall throughput of their business (a.k.a. “Mafia Offers”). And focus on the customers, or market segments, that you understand best – or at least can work with to find such understanding.

Our aim: to optimise the Needsscape a.k.a. the needs we meet (for example, need for revenue, profit, cost reduction, etc. often sits at top of mind).

Relevance For Workers

This post is not just about decisions made by executives and managers. Everybody has the same dilemma: how do I/we decide where to focus? Which code module would it be better to deliver first? Which tests are more valuable that others? Who would it be better to work with first, to understand their needs (a.k.a. constraints, requirements, or whatever)? Where we choose to focus absolutely determines how others see us and our efforts.

Bottom Line

The bottom line is: the more effective we are at focussing on things that contribute to our personal or business goal (Cf. Goldratt), the more of our goal we’re likely to get. (Is that self-serving? Only if our goal is self-serving. Choose wisely).

– Bob

Further Reading

The Goal ~ Eliyahu M. Goldratt
It’s Not Luck ~ Eliyahu M. Goldratt
Focus ~ Think Different blog post
What is Value? ~ Think Different blog post

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users, snakeholders – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours.

Personally I like to call them The Folks That Matter™.

By way of example, Here’s a partial list of the groups and individuals that are candidates for inclusion in the set of The Folks That Matter™.

  • Your organisation’s Core Group
  • Your manager
  • Your project manager
  • Senior managers and executives
  • Your dev team
  • Other dev teams
  • Ops people
  • The PMO
  • Testers (when separate from the dev team)
  • QA folks (when present)
  • The Process Group (when separate from the dev teams)
  • Your business sponsor(s)
  • Other people across your organisation
  • Your (end) customer(s) (and their purchasing departments)
  • Commercial partners
  • Regulators
  • Wider Society
  • The Planet (Gaia)

The Interesting Angle

For me, when I’m involved building stuff, I have a need know who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to. I need to know what folks need, and who to ask about the details of those needs, if and when the detail moves to front of mind. I need to know whose needs we can successfully discount when the inevitable resource (time, money, effort) crunches come. Whose needs we can reasonably consider as outside the scope of the endeavour in which we’re involved? And I need some heuristics to guide us in decisions on including, excluding and prioritising folks and their needs.

But there’s something much more interesting than who’s on and who’s off the list of The Folks That Matter™, at any given time. The much more interesting question for me, as an Organisational Psychotherapist, is: What governs the choices? How do folks get added to or removed from the set of The Folks That Matter™? Are the means the product of rational thought, discussion and evolution, or maybe they’ve just happened, or been cargo-culted. And what are the consequences of the prevailing means? What impact do those means have on the success or failure of our endeavours? And therefore on our bottom line?

By way of example, here’s some common means for tackling the question of means:

  • Consensus
  • The Advice Process
  • Autocracy
  • Dictatorship
  • HiPPO
  • Cost of Focus

(Aside: Each collective mindset in the Marshall Model has its own popular choice for these “means”: Autocracy for the Ad-hoc, Dictatorship or HiPPO for the Analytic, Consensus or the Advice Process for the Synergistic, and e.g. Cost of Focus for the Chaordic).

Is it helpful for folks on the dev team to be involved in some way in maintaining or keeping the list of the The Folks That Matter™? Is that possible, in any given organisation? Is the question even discussable?

When Resources Are Limited, Some Folks, Needs, HAVE To Not Matter

And what about the folks that don’t matter (that don’t appear in the set of The Folks That Matter™? I know many readers will baulk at the idea that some folks and their needs don’t matter. But, please, get over yourselves. In any situation where resources are constrained (i.e finite, not infinite), choice HAVE to be made. Lines drawn. Resources committed to some areas and held back or withdrawn from others. How could it be otherwise? Inevitably then, in this particular frame, there must be Folks Who Don’t Matter™.

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of prioritising one feature over 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. The question of Cost of Focus.

By definition, we are not meeting some 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, 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 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 whose needs to attend to, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

%d bloggers like this: