Archive

Antimatter principle

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.

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

  • Control Document
  • Articles of Understanding
  • Glossary of Terms
  • Statement of Purpose
  • Case for Action
  • Vision
  • Folks That Matter™ and their Needs
  • Risk Parade
  • Top Risks
  • Functional Requirements
  • Non-functional Requirements aka QQOs
  • Critical Success Factors
  • Feature Schedule
  • Quality Plan
  • Test Plan
  • Change Control
  • Cycle Plans
  • Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

Six FAQs Explored

Recently, Adelbert Groebbens (@agroebbe) made an observation on Twitter to the effect that getting other people to understand what we’d like them to understand is a fool’s errand. He illuminated the point with a reference to my Six FAQs post. Al Shalloway expressed his disagreement with many of the points therein. This post explores the subject, via a dialogue between Al and myself, conducted over email recently, and in the context of the original Six FAQs post.

Note: the # numbers relate to the numbered points in Al’s original tweets.

The Dialogue

@alshalloway: (Opening): Thanks. but i disagree with most of the points there [in the original Six FAQs post].

@FlowchainSensei (response): Thanks Al for providing your take on this post. Maybe you’d be willing to enter into a mutual exploration of the subject of e.g. motivation? I guess your comments (provided via Twitter and copied, below) reflect your experiences when working with developers and teams? Likewise, my original post [link] reflects my experiences in similar environments (with a little borrowing from Bill Deming, Russell Ackoff, Marshall Rosenberg and Carl Rogers, to name but a few). It comes as no surprise to me that our experiences differ somewhat, and that our respective conclusions differ likewise. That’s not to say I’m right, or you’re right – we could both be right. Or wrong. Or somewhere in between.

The Annotated Original Post 

Questions I’m frequently asked about software and product development organisations.

Q1: How can we motivate our workers?

A1: You can’t. [see: Al’s #1 follow-up comment, below] Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

@alshalloway: #1:  Pretty much agree but don’t like tone. Most workers will respond to not being de-motivated. the “maybe, just maybe” is what i don’t like.

@alshalloway: #1: (Follow-up): you can’t motivate, you can only stop demotivating. In other words, you can’t motivate them, but you can do other things that are useful. 

@FlowchainSensei: #1: I guess your assessment of the “tone” here differs from mine. How often do e.g. managers or others responsible for the workplace “environment”, when attempting to cultivate a climate conducive to intrinsic motivation, succeed in those attempts? My experiences suggest “occasionally”. I guess you concur on the main point here: that intrinsic motivation can only come from the folks themselves (the emergence of same being aided by efforts to reduce or remove demotivators – shades of Drucker, Herzberg)? 

@alshalloway: Agreed that most managers don’t do this [attempt to cultivate a climate conducive to intrinsic motivation]. But much of that is because it’s never been explained to them [as] a new role they can fill.

@FlowchainSensei: Explaining presupposes they’re motivated to listen to explanations. I’m minded of the following quotations:

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

~ Peter Drucker 

“If you want people to do a good job, give them a good job to do.”

~ Frederick Herzberg

Q2: How can we change the organisation’s culture?

A2: You can’t. [see: Al’s #2 follow-up comment, below] Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that. 

@alshalloway: #2: you can’t change an org’s culture directly, but you can change it indirectly. See my post “Improving Your Company’s Culture”. 

@alshalloway: #2: (Follow-up): you can’t change culture directly, but there are ways to do it indirectly. You can’t change it directly since culture is a result of many things in your company.

@FlowchainSensei: #2: I totally agree that “culture” can be changed indirectly (but not directly). To elaborate on this question, I propose that changing culture through examining assumptions and beliefs (more specifically, supporting folks who are interested in getting together to examine their own *collective* assumptions and beliefs) offers a way forward. For which see: Organisational Psychotherapy.

@allshalloway: I don’t think you need to change minds directly. Rather change how they [people] work.  It’s consistent with the idea “it’s easier to work your way into a new way of thinking than to think you’re way into a new way of working.”

@FlowchainSensei: I’d clarify that as “I don’t think you can change minds directly. Rather enable and encourage change to how the people doing the work choose to work. (See also:The People vs System Conundrum).

Q3: How can we change the mindset of managers?

A3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

@alshalloway: #3: I’ve changed mindsets by guiding people through their beliefs and showing them better ones. I’ve had special training in this.

@alshalloway: #3: (Follow-up): changing mindset is only possible when people are open to it.

@FlowchainSensei: #3: I agree with your follow-up statement. It’s been my experience that folks have difficulties when left on their own in this regard, even when open to the idea of “changing mindsets”. I have found that help, or support, or (your term) guidance can be valuable here. Hence, btw, Organisational Psychotherapy (support-for-changing-assumptions-and-beliefs-as-a-service).

@AlShalloway: Changing mindsets is difficult, and even when possible, takes a long time. It is important to show managers new opportunities and new ways they can interact with the people they work with.

@FlowchainSensei: When and if these managers are motivated to see and learn – see Q1. 

Q4: How can we get teams to take responsibility?

A4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

@alshalloway: #4. Pretty much agree. But again, it’s the skeptic’s tone i object to. Many are ready to take responsibility, but like motivation, we’re de-motivating them to do so.  You could argue we agree – but it’s not clear.

@alshalloway: #4: (Follow-up): You can’t get people to take responsibility, but for those that are willing, you can remove the barriers to it.

@FlowchainSensei: #4: I guess our experiences differ here. I wonder how much that difference has to do with geographies and national cultures (I.e. UK vs USA)? In my experience (UK, and Europe too), many are not ready/willing to take responsibility, often through long experience of being punished or sanctioned for attempting to do so, or even for simply suggesting it. Is “Learned helpless” more prevalent in the UK, I wonder? I agree wholeheartedly with your follow-up statement.

Q5: How can we get managers to trust their teams?

A5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

@alshalloway: #5 Building trust is not easy but it’s possible. Most of the way Agile does it doesn’t work. You can’t presuppose it [trust] or blame people for not having it. Lean management can be helpful here.

@alshalloway: #5: (Followup): You have to build trust, and not everyone is willing to have this built.

@FlowchainSensei: #5: Agreed, especially with your observation that there are some folks who are, on the face of it, unwilling to participate in trust-building. I would love to hear more about the aspects of Lean management which you have in mind. For myself, I have found the Antimatter Principle and Nonviolent Communication both useful in trust-building efforts.

@alshalloway: Trust grows over time as people work together. An expectation that managers will all of a sudden trust their teams is doomed for disappointment. But we can teach managers how to work with people to build trust. Why am I not trusting their [the manager’s people] judgement? What is it that people need to know?

@FlowchainSensei: Agreed. Again, allowing for managers being willing (or unwilling) to be “taught”.

Q6: How can we develop people’s competencies?

A6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

@alshalloway: #6. Your title is inconsistent with what you say. You admit to being able to change competency if they are willing to learn. So it’s not possible.

@alshalloway: #6: (Follow-up): You can only improve people’s competencies when they are already willing to learn. 

@FlowchainSensei: #6: I’m unsure as to the meaning of your original comment. If your follow-up comment serves as a clarification, then I agree entirely. 

In a nutshell, the direct answer to all the above questions is: you can’t. But you can do at least one thing to make progress on all these questions: consider the Antimatter Principle.

Are you willing to be that radical? For that is what it boils down to. 

“We can’t solve problems by using the same kind of thinking we used when we created them.”

~ Albert Einstein

– Bob

Closing

@alshalloway: (Closing) I object mostly to the skeptic curmudgeonly style of the posts – the absolutism of it.  

@FlowchainSensei: (Closing): I guess I’m well-known and loved for my skeptical, curmudgeonly style. :}

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.

– Bob

Further Reading

Cost of Focus ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
Cost of Delay ~ Wikipedia entry

Structurally Broken

“When you have a system in which structural failure is embedded, nothing short of structural change will significantly improve it.”

~ George Monbiot

He was talking about the UK’s transport infrastructure, but I’ve long believed the world’s “Software Industry” system is structurally broken, too. Even the very name “software industry” signals dysfunction. (Of course, this observation applies to many industries, not just software).

Software

“The great Harvard marketing professor Theodore Levitt used to tell his students, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” Every marketer we know agrees with Levitt’s insight. Yet these same people segment their markets by type of drill and by price point; they measure market share of drills, not holes; and they benchmark the features and functions of their drill, not their hole, against those of rivals.”

~ Clayton M. Christensen

We’ve heard time and again that people (customers, the general public) don’t want software, they want the utility that software can bring. Yet we call our industry the software industry, condemning us to build and deliver stuff that our customers don’t want. Granted, “that cat’s outa da bag” as Lt Columbo would say. Renaming the whole industry as something like “the pain solving industry” or the “attending to folks’ needs” industry ain’t going to happen any time soon, if ever.

Industry

Why do we describe the <name to be argued over> field as an “industry” anyways? Images of factories and satanic mills and slave plantations and the Apple “1984” advertisement come to mind. “Art” is rarely labelled as an industry, for example.

Structural Change

So what kind of structural change or changes might bring about some improvements?

#NoSoftware points the way. Analogous to the Paris 15-minute city idea (by implication, #NoCars).

And until customers stop asking for drills (software) and begin explicitly asking for holes (their needs met) we’ll likely not see much change.

What kind of structural changes can you envisage, suggest?

– Bob

Further Reading

Beyond Command And Control – A Book Review ~ Think Different blog post

 

Why We’re All So Angry All The Time

In his book “The Surprising Purpose of Anger” Marshall Rosenberg tells us that anger stems from situations where our needs are not being met. When a need is unmet, we’re likely to feel frustrated and react aggressively (see: Blair, “Considering Anger from a Cognitive Neuroscience Perspective” . And, being human, we’re also likely to look for other people to blame for our needs going unmet.

That may be so. Indeed, Rosenberg’s perspective is a key element informing the Antimatter Principle.

But I have another theory. Or at least, a complementary theory. What if we’re so angry all the time – at a whole host of different things – because we have a need to feel angry? What if we find some real joy, delight – or at least catharsis – in feeling angry?

The theory: We’re all so angry all the time because we like it that way. We delight in the rush of adrenaline and flow of blood to the amygdala – and related parts of the brain – that accompanies our feelings of anger.

This might help explain some of the behaviours I see time and again in work and life. And note in myself, too.

“There’s something delicious about finding fault with something, Especially when our egos are involved (which is nearly always the case), we may protect our anger. We justify it and even feed it.”

~ Perma Chodron

Moral Imperative

We see lots of self-help articles about moderating or dealing with our anger. I suspect an underlying moral imperative along the lines of “anger is bad”. I don’t subscribe. Anger, like any other emotion, strikes me as neither bad nor good – it just IS. Of course, emotion-led responses borne of anger can lead to unfortunate outcomes – such as deterioration in our relationships with others. Which we probably would find useful to avoid, not least in the context of the workplace.

Dealing

Some research suggests that when we attempt to tackle our emotional state head-on, it only makes things worse:

“…when experimental subjects are told of an unhappy event, but then instructed to try not to feel sad about it, they end up feeling worse than people who are informed of the event, but given no instructions about how to feel. In another study, when patients who were suffering from panic disorders listened to relaxation tapes, their hearts beat faster than patients who listened to audiobooks with no explicitly ‘relaxing’ content. Bereaved people who make the most effort to avoid feeling grief, research suggests, take the longest to recover from their loss.”

~ Oliver Burkman

Conclusion

In conclusion, may I suggest we recognise and acknowledge the feeling, embrace the delicious joy of anger, use it as fuel for our spirit, and don’t get caught up in moralistic judgments of ourself or the emotion. And remember, we don’t have to ACT on our anger.

– Bob

Further Reading

Considering Anger from a Cognitive Neuroscience Perspective ~ R. J. R. Blair
The Surprising Purpose of Anger: Beyond Anger Management: Finding the Gift ~ Marshall Rosenberg
Anger And Domination Systems ~ Marshall Rosenberg
How To Get Rid Of Anger: 3 New Secrets From Neuroscience ~ Eric Barker
Buddhism’s Solutions for Anger ~ Barbara O’Brien
The Power of Humane Relationships ~ Think Different blog post

Better Antimatter Customers

[Some years ago I wrote a post entitled “Better Customers“. This is an update of that post, reframed using the AntimatterPrinciple]

More effective organisations need better Folks That Matter™. Where “better” means more demanding discerning. Less gullible.

Folks that demand their needs are met, or as a minimum, attended-to, not tech, nor features, nor hand-wavy “value”.

Folks that refuse to pay when their needs are ignored, met poorly, or not addressed at all.

Folks that hold a healthy skepticism for unevidenced claims and promises.

Folks that disrupt the cosy hegemony of the technologists (see e.g. #NoSoftware).

Folks that push back against complex and expensive non-solutions.

Folks that push through the embarrassment of failure to call suppliers to account.

Folks that understand THEIR Folks That Matter™, and look for partners that want to help them in that.

Folks who see the value in relationships, trust, and evidence, whilst rejecting faith-based arguments.

Folks that buy on criteria other than lowest (ticket) price (cost being just one need amongst many).

Folks that embrace the human element and humane relationships in the world of business.

Folks that understand their own strengths – and their weaknesses, and act accordingly.

Folks that generously share the laurels of success, and share responsibility for failure too.

There are so many folks that feel a need to do better, but desperately need the support of their Folks That Matter™ to make that happen. Without better Folks That Matter™, the reforms and improvements we need will indeed take a long time in coming.

– Bob

 

Your REAL Job

Students of Ackoff and Deming will be aware of Deming’s First Theorem:

“Nobody gives a hoot about profit.”

W. E. Deming

This reminds us that senior executives are demonstrably less interested in the welfare of the organisations they serve than in their own well being.

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

~ Russell L. Ackoff

Of course, it can be career-limiting to bring this issue to general attention. As the well-known psychiatrist R D Laing said:

“They are playing a game. They are playing at not playing a game. If I show them I see they are, I shall break the rules and they will punish me. I must play their game, of not seeing I see the game.”

~ R. D. Laing

And yet, if we look at the implications for “doing a good job” – a preoccupation of many in employment, we can draw the following conclusion:

We’re doing a good job when we’re maximising our executives’ (our bosses’) well being. We’re not doing a good job when we ignore that in favour of focussing on e.g. making the company successful or profitable. This probably rings true with you if you but think about it, in your own context, for a few moments.

This underscores a hidden reality for many: our declared job is a FAUX job. Our REAL job is undeclared, unexamined, unspecified – and being good at THAT is therefore a matter of pure dumb luck and random chance. How often do you have a conversation with your senior executives about how you might contribute to maximising their well being? How can we attend to their needs – as folks that matter – without such a dialogue?

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post

What Is A Customer?

In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints).

And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary:

Value: The degree to which folks’ needs, in aggregate, are being (or have been) met.

But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally?

Here’s my definition, again using the Antimatter Principle as a frame:

Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to.

I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take.

Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality:

Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else.

This definition canonises Crosby’s idea that we’re all customers. And we’re all suppliers, too. And as suppliers, it falls to us to ensure that what we’re supplying is what our immediate customer needs to supply their customer(s).

– Bob

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

Damn Outcomes!

It seems in vogue to extol the praises of “outcomes” when discussing e.g. software and product development. Setting aside the challenges of defining what we might mean by “outcomes” (I dislike getting into rabbit-hole discussions of semantics), there’s one key aspect of this debate that seems to escape folks’ attention. W Edwards Deming nailed it decades ago with his First Theorem:

“Nobody gives a hoot about profits.”

Even so, Deming said little about what folks (managers, in his frame) DO give a hoot about. We can turn to Russell L. Ackoff for an insight into that:

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

As Dr. Ackoff says, a secondary focus on profits is just the cost executives must pay in order to maximize their rewards. The actions taken would be different if the well being of the organization was primary and the well being of senior executives subservient to that aim.

Outcomes

So, to outcomes. The outcomes that delight will be those that maximise the executives’ (and other folks’) well being. When developing a piece of software, how often do the specifics of the well being of the Folks That Matter get discussed? Indeed, is the subject even discussable? Or is it taboo? In your organisation?

How unsurprising then, that software as delivered is so often lacklustre and uninspiring. That it fails to address the core issues of the well being of the Folks That Matter? That it’s the wrong software.

As a developer or team, do you ever afford your customers (a.k.a. the Folks That Matter) the opportunity to talk about their well being? And how what you’re doing for them might contribute to that well being?

So, might I invite you to stop talking about specious and illusory “outcomes”. And start asking the difficult questions of your customers (and yourselves)?

Here’s a possible opener:

“Would you be willing to discuss what it is you need for your own well being?”

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post
Agile Competency Is A Crock ~ Think Different blog post

Random Walks

How well does the almost universal Agile practice of “build it and see if they come” serve us (as developers, as customers)?

I suggest it’s time to rethink our belief that customers (and developers, for the most part) “don’t know what they want until they see it”.

My late, great colleague and friend Grant Rule used to refer to the practice, common in the Agile domain, of building (a portion of) something to see if the customer likes it as “random walks through the problems-solution space”.

Quality Demands Requirements

Philip Crosby, a widely acclaimed “guru” of Quality Management, defined quality as “conformance to requirements”. As simple and blunt as that.

Recently, I’ve been reflecting on my experiences with software product development, especially the development of “quality” products that customers love. In Javelin, we place special emphasis on de-risking delivery through explicitly defining the customers and their respective requirements. Not big-bang, up-front stylee, but incrementally, just enough each couple of days to build a little more of the product and deliver it to the customer(s) for their delight, confidence, and feedback.

But in our approach, requirements (in the frame of the Antimatter Principle we call these needs) precedes building anything. Agile shops these days seems to major in building something before discussing requirements (if they ever get discussed at all). BDD offers an exception, but how many shops do BDD?

Aside: In Javelin, we identify all stakeholders (a.k.a. all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”, in Javelin parlance) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although:

  • This all generally proceeds incrementally, rather than in a big batch up front.
  • The information is always to hand by the time someone gets around to building the relevant part of the thing in question.
  • The requirements come from dialogue(s) with the relevant Folks That Matter.
  • The requirements need not get written down (documented) unless there are some Folks That Matter that need them to be.

People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

By cleaving to the belief that customers “don’t know what they want until they see it”, and structuring the whole approach to development around this belief, Agile shops have no incentive to improve the way they work with customers to understand their needs. No incentive to improve requirements elicitation and capture. No incentive – or means – to prevent defects and deliver zero-defects quality. Indeed, this belief and its associated practices blocks us from working to continually find better ways to create useful requirements (formal statements of folks’ needs) from which to drive quality (cf Crosby) and the improving of relationships with each other (developers, ops) and with customers.

Is this emphasis on working-from-clearly-stated-and-agreed-requirements better? Well, in my experience it makes for happier customers, happier developers, and more successful products. I’ll leave it to you to decide whether and how that’s “better”.

– Bob

The Relevance of Giants – 2. O Sensei (Morihei Ueshiba)

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, O Sensei have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s continue, with this second post in the series, with O Sensei.

O Sensei

Morihei Ueshiba

(December 14, 1883 – April 26, 1969)  (See also: Wikipedia entry)

I’m not going to dwell on his early life and experiences in the Japanese Army, his adventures in Mongolia, nor his experiences in Manchuria and Japan during the time of World War 2.

Aikido

I suggest the primary relevance of O Sensei to most folks working in the field of software development (and production operations) is Aikido – the martial art he developed. Excepting it’s less a martial art, and more a philosophy for life, and for harmonising with others.

Unlike many other martial arts, Aikido is focussed on caring for others, as emphasised by the translation of the three kanji: ai-ki-do as the Way of Unifying Spirit or the Way of Spiritual Harmony. O Sensei envisioned Aikido as an expression of his personal philosophy of universal peace and reconciliation. O Sensei’s goal was to create an art that practitioners could use to defend themselves while also protecting their attacker from injury.

Blending“, one of the core techniques of Aikido, invites us to look at conflicts from the perspectives of the other person – or people – involved. For me, this has a direct connection with empathy – as promoted by e.g. Marshall Rosenberg and others of the nonviolent community.

“Life is growth. If we stop growing, technically and spiritually, we are as good as dead.”

~ Morihei Ueshiba

Where’s the Relevance?

How do we make it more likely that we’re all spending our time on stuff that matters? How do we go about attending to folks’ real needs? I find blending a great asset in identifying with the needs of others. As I blend, I see their perspective, and their needs, more clearly. And in turn, they can feel more listened-to. And choose to reveal other things, crucial things, that means we get to understand more about what matters to us all. With this knowledge – and goodwill – we have a better chance of focusing on what matters, and of reducing the chance of wasting some or all of our time on the inconsequential, on detours, and on dead ends.

Practical Investigation

You might like to join an Aikido dojo, to practice the physical forms of the techniques. And to discuss the philosophy with like-minded people wha have already started the journey. Beware, though, of those dojos and sensei that emphasise the physical forms at the expense of Aikido philosophy.

– Bob

Further Reading

The Life We Are Given ~ Michael Murphy, George Leonard
The Way of Aikido ~ George Leonard
It’s A Lot Like Dancing ~ Terry Dobson

The Needsscape

-scape

suffix forming nouns

  1. Indicating a scene or view of something, esp. a pictorial representation: seascape, cityscape, soundscape.

Word Origin: Abstracted from “landscape”.

The Essence of Business

Business is, in essence, about attending to folks’ needs. Here’s a quick list of typical needs, to illustrate:

  • The financial needs of the owners and shareholders, and of staff.
  • The particular needs of customers, which the business’s products and services attempt to address.
  • The needs of suppliers for revenues.
  • The needs of wider society for commerce, prosperity, growth of social cohesion and living standards, wealth distribution, and so on.
  • The emotional needs of owners, shareholders, executives, managers and staff (examples: status, self-worth, compassion for others, making a difference, safety, love, esteem, curiosity, joy, learning, accomplishment, contributing to society, etc.).

I use the term “needsscape” to refer to the ever-changing set of Folks That Matter, and their ever-changing sets of needs. (Not all the needs listed above might feature in a given business’s needsscape).

In particular, the term Needsscape, for me, evokes the idea of one or more visualisations of the ever-changing set of Folks That Matter, and their ever-changing sets of needs, including the evolution of those sets over time. And especially visualisations of the current and relevant future set of Folks That Matter, their various sets of current and relevant future needs, and where the business is “at” in terms of attending to those folks and their needs. In other words, making all work (and objectives) visible, including attributes such as progress, status, and other interesting aspects of the work (aspects made interesting due, themselves, to the pertinent set of Folks that Matter, and their needs).

Indeed, all value-adding work is attending to (some) folks’ needs. And all wasted work is work where folks’ need are undermined.

What value would a real-time (or near real-time) visualisation of the needsscape bring to your group and/or business?

– Bob

Further Reading

English Words Suffixed with -scape ~ Wiktionary entry

 

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

BenSImoTweets

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapists provide guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research (cf Buy•ology ~ Martin Lindstrom) has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. However, most product development today is driven by rationality:

  • What are the customers’ pain points?
  • What are the user stories or customer journeys we need to address?
  • What features should we provide to ameliorate those pain points and meet those user needs?

Upshot: mediocre products which fail to appeal to the buyers’ emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand, lower market share, and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) – focusing as it does on product features – with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets (and more broadly, in all the Folks That Matter).

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistently through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principle proposes that putting the principle of “attending to folks’ needs” at front and centre of all of the organisation’s policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineering disciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter.

– Bob

What is Expertise?

Hiring an expert is a pretty much everyday occurrence. There’s accountants and lawyers, bankers and insurers, butchers and burger flippers, gardeners and mechanics. Sometimes we hire people not for their expertise, but simply to save us time, for example dog walkers or housekeepers.

For those folks we hire for their expertise, what does that actually mean? In the Antimatter frame, we might choose to say that experts possess – and can apply – more effective strategies for getting (some of) our needs met than we possess ourselves.

We’d not often tell our accountant how to calculate our tax liabilities. Nor our lawyer how to prepare and present our legal case. That’s because, with their more effective strategies, they’re likely to achieve a more effective outcome than we, with our relatively ineffective strategies, could. So we’re more likely to see our needs (in the round) get met.

Where’s this Going, You Might be Asking

Well, let’s turn our attention to hiring people – be that employees, contractors or consultants. Sometimes we’ll hire people to save us time. We could do the job that we’re hiring them to do, but we have more valuable things we can be spending our time on, so we hire them to do the less valuable things.

But sometimes, we’ll hire folks for their expertise. There’s some needs for which we accept our own strategies for getting those needs met are relatively ineffective. Like, running a software team or department, for example. So we find someone who appears to possess – and can apply – relatively more effective strategies.

So far, so good. If we choose our experts well, we’ll see our needs met more effectively – sometimes very much more effectively – than if we chose to attempt to meet those needs ourselves.

However. What happens when the effective strategies employed by our experts seem inexplicable to us? When we just can’t understand how applying their preferred strategies can achieve getting our needs met? We rarely quiz our accountants and bankers on their strategies. But we do quiz our new hires. As if we’d understand.

The Credibility Barrier

We have crashed headlong into the “credibility barrier”. Where it’s our own incredulity that blocks us from hiring those very folks possessing the most effective strategies for getting our needs met. And the most likely outcome being, we’ll reject the expert and their expertise, rather than recalibrate our assumptions and beliefs about what’s credible.

– Bob

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users, stakeholders – 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

The Antimatter Opening Question

In Clean Language, a conversation with a client often opens with the question “What would you like to have happen…?”

This has bugged me for a long time, for two reasons:

  1. Maybe the client doesn’t like for anything to happen (therefore it’s not truly a Clean question). 
  2. In the Antimatter frame, it matters little what the client might like (or want) to have happen. It matters a whole lot more what they might need to have happen.

So, I generally open with “What might you need to have happen…” (the Antimatter frame). 

As I make no pretence to use Clean Language (excepting on the rare occasion), reason 1, above, is rendered moot. And reason 2 dissolves as we expressly ask what the client might need. I’ll just point out that this is a much harder question to answer, not least because folks may be able to quickly state what they’d like, but generally have much more difficulty identifying their needs. For me, this is another point in favour of the Antimatter frame – we can directly begin to explore the question of what they might need to have happen. And for this, I generally opt for the NVC (nonviolent communication) four step approach.

– Bob

The Marshall Plan

I guess most people, when they start a new job or client engagement, have in mind the things they want to do and see happen. Most likely, things they’ve seen or made happen in previous jobs or engagements. Along with, maybe, some things they’ve read or heard about and are minded to try out, given the opportunity. (And what better opportunity than the honeymoon period of a new job or client?)

We might choose to call this an agenda.

My Agenda

I’m no different, excepting perhaps the items that feature on my agenda:

  • Invite participation in discussing “who matters?” (with respect to i.e. the work and the way it works)
  • Empathise with the emergent community of “folks that matter” (not exclusively, but as a priority)
  • Invite folks to listen to each other’s volunteered observations, hear each other’s feelings, and explore each other’s needs.
  • Invite folks to solicit and then begin attending to each other’s requests (explicit and implicit)
  • Offer and provide support to folks and communities in their journeys

Note: I’ve not included on my agenda anything about specific actions that I myself might want to do and see happen, beyond the items listed. Specifically, although I’ve written often about strategies such as Flowchain, Prod•gnosis, Rightshifting, the Marshall Model, self-organising/managing teams, the quality of interpersonal relationships and interactions, etc., I don’t bring these into my agenda. If folks discover these strategies for themselves, they’re much more likely to understand their fundamentals, and maybe come up with even more effective strategies.

The Antimatter Principle is the only strategy I’ve regularly written about that recognisably features on my prospective agenda, and then only by extending invitations to participate in that strategy. (Note: Attentive readers may just notice the tip of the Organisational Psychotherapy iceberg peeking out from the above agenda).

I’ve reached a point in my journey where, keen as my ego is to see all my ideas (strategies) made manifest, my experience tells me that’s not the way to go for the best outcomes for the community as a whole.

As for the Marshall Plan, I believe it’s best, in the longer run, to have the folks involved (in particular, the people that matter) do their own discovery and learning. Discovering for themselves, over time – through means they also discover for themselves – effective strategies for attending to folks’ needs (often including the principles underlying those strategies). I see my role in this Plan as supporting – in whichever ways folks request, or say they need – this collective endeavour. Such support quite possibly to include actively helping the discovery and learning, whenever there’s an explicit (albeit refusable) request for me to do so.

– Bob

Further Reading

The Benefits of Self-directed Learning

Difficult Conversations

Before this turns into a mini-series, I’d just like to add one observation to my previous two posts.

Setting aside the outcomes sought by the people that matter, outcomes related to the business and its needs, there’s the not inconsequential matter of the unexpressed outcomes sought by these folks with respect to their own personal needs. Often, these needs are not discussed, shared or even registered at a conscious level by the individuals concerned. And often, then, explicit outcomes have yet to be identified – both by them and by us.

There’s not much point addressing the needs of the organisation (see my previous post) without also attempting, at least, to address the needs of the individual people that matter. This asks of us more effort, because we’re likely to be starting “further back”, before these folks have even expressed their personal sought outcomes. And because they may be reluctant to get into these kinds of conversations, being unusual in a workplace context. And then there’s the difficulty involved in “speaking to power” or at least empathising with people in positions of power.

Examples

Some examples may help clarify this observation.

Senior managers and executives, in articulating the sought outcomes listed previously, may also want to control the solutions chosen, hence their providing solutions in the form of wants. Often there’s an underlying need to feel “in control”, driven by some need, such as their need for order, or personal safety, or kudos.

Similarly, articulating their sought outcomes may, in part, derive from their need for tangible progress, or a need to be seen as the driver of that progress.

Summary

Entering into, and sharing the exploration of these often intensely personal topics is certainly difficult. But that difficulty can ease when we have the right conditions – such as trust, friendship, skill, and safety. And without such conversations, we’re that much more likely to spend much time and effort on delivering outcomes that no one really needs, or worse – that actively work against folks’ needs.

– Bob

Further Reading

Crucial Conversations ~ Patterson & Grenny
Difficult Conversations: How to Discuss What Matters Most ~ Patton, Stone, Heen & Fisher
Discussing the Undiscussable ~ Bill Noonan
Feelings Inventory ~ List at the Centre For Nonviolent Communication
Needs Inventory ~ List at the Centre For Nonviolent Communication

%d bloggers like this: