Archive

Monthly Archives: June 2018

Stainless Steel Rats

June 28, 2018
General, Prognostication
1 Comment

Stainless Steel Rats

From time to time I step back from the frontline of better software, and write a post trying to put things in a broader context. This is one of those posts.

Managers Don’t Want Software

Managers in companies making and selling products and services don’t want software. It’s a PITA to manage, costly, and troublesome. If someone came along and showed them how to get along without software, most would jump at the chance without a moment’s hesitation. (This is but one of the many reasons for my support for #NoSoftware, btw). The perceived link from software to revenues is tenuous at best. And most managers don’t even give a hoot about revenues or profits. The way the world of work works encourages us all to satisfy our own personal egos, pockets, and other needs.

Companies Don’t Want Long Term

Senior managers and executives are under all kinds of pressure to deliver short terms results. Shareholders and the markets are largely aligned to short-term wins.  And all have little incentive to take a longer-term view. Most KPIs and OKRs focus on the next quarter or year. Getting good at anything seems like a distraction from “making the numbers”. Getting good at tricky, complicated and complex things like software development holds even less appeal. Most senior folks don’t expect to be in post beyond a couple of years, and most expect their present companies to live short, frenetic lives. (The numbers on that largely reinforce that expectation).

Customers Don’t Want Software

They want their needs attended-to – and, preferably, met. The great majority couldn’t give a rat’s arse whether software is involved in that or not. And given the pain they perceive as arising from the software components of many commercial services they have to use, they’d like to see the back of software, too.

Our Bubble

We practitioners live in a software bubble, imagining that the world sees software like we do. Shiny, glitzy, awesome, useful, cool. This just ain’t so. And for the conscientious practitioners, there’s the need to master our trade / craft / profession / discipline. No one else needs us to do this. And few outside the bubble are interested in indulging us in seeing that need met.

The Bottom Line

It’s my considered opinion that software development, “broken” for the past fifty years, remains just as broken today – because almost no one needs it to be any better. What to do then? Is there no hope for us conscientious practitioners?

Little hope, I’d say, excepting doggedly pursuing our dreams of a better world. Finding joy where we can, like stainless steel rats in the wainscoting of business and society. Banding together for mutual support. Seizing each fleeting opportunity to see our needs for better ways of working attended-to, if not always met.

And talking with people outside the bubble. Listening to them. Trying to understand their needs. And seeing if there’s any chance of alignment between what they each need, and our own dreams.

– Bob

The Folks That Matter™

June 22, 2018
Advice Process, Antimatter principle, Dialogue, Doctrine, Engineering, Management, Organisational effectiveness, Product development, Software development
4 Comments

The Folks That Matter™

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

June 19, 2018
Antimatter principle, Nonviolent Communication, Organisational Therapy
Leave a comment

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

Agile Coach to Organisational Psychotherapist

June 15, 2018
Advice sought, Coaching, Organisational Therapy
9 Comments

Agile Coach to Organisational Psychotherapist

My thanks to Beatric Düring for her recent Twitter question:

“If I wanted dive deeper into org psychotherapy – what would be crucial knowledge I would have to acquire working as an agile coach? Where can I draw the line requiring professional psychotherapy education/training?”

Is it feasible to transition from an Agile Coach into the Organisational Psychotherapist role?

Considerations

Given that I was an Agile Coach for years before making the shift myself, I’d say it’s demonstrably feasible. Why might any Agile Coach consider making the shift?

Organisation-wide Scope

For me, it was down to an increasing dissatisfaction with the (limited) value I was able to deliver in the role of Agile Coach (and latterly, Enterprise Agile Coach). Over a number of years it was becoming clearer and clearer to me that the real dysfunctions in any organisation lie outside the domain of any one functional silo. In the white space between people, and between silos, if you like. It became obvious that to deliver real change, change that’s worth having, change that makes a significant impact both on the lives of everyone involved and on the bottom line of the organisation, a more holistic, systemic intervention pays major dividends. And the Organisational Psychotherapist role implies the necessary whole-organisation scope to do that more effectively, and more often, than the Agile Coaching role.

It’s the Client’s Agenda That Counts

There was also, for me, the increasing realisation that I was not actually helping things for a client by making suggestions and having an agenda (a bunch of my ideas about what future would be best for them). Organisational Psychotherapy allows us to cut through that particular Gordian Knot.

It’s About The People

Organisational Psychotherapy is about people, and their relationships – with each other and with the collective psyche of the organisation. I hear from many Agile Coaches that this is a dawning realisation that creeps up on us over several years, at least. Process and management issues fade in importance the more we coach. Ultimately, into utter insignificance.

The Questions

So, to Beatric’s two questions:

What Knowledge is Crucial?

What knowledge, accessible to an Agile Coach, is crucial to diving deeper into Organisational Psychotherapy ?

The journey, for me, was eased by various spells as an Enterprise Agile Coach. This helped me acquire a practical angle on the whole Lean / System Thinking / Synergistic perspective, looking at organisations as a whole, rather than being limited to intervention horizons within a single function (most often, the Software Development or Software Engineering function). Maybe an Agile Coach could transition into Organisational Psychotherapy without that system-wide appreciation. I’d be interested to hear about folks’ experiences in that regard.

On the other hand, there’s a whole world (more than a hundred years in some cases) of work and results across the more than 400 different schools of therapy that comprise the world of psychotherapy as it pertains to individuals. Much of my learning has come from reframing individual therapy techniques for application in the organisational context. I wrote a post some time ago, describing some of these, entitled My Organisational Therapy Toolkit.

Where to Draw the Line?

How far can the Agile Coach progress in his or her personal journey towards mastering Organisational Psychotherapy, before it makes sense to seek professional psychotherapy education/training?

As far as I know, there is no recognised professional education or training for Organisational Psychotherapists. I’m entirely self-taught, and most of my most profound learning has come as a result of interacting with real live clients in real live situations. I do try to share my learnings with others, and when the demand is there I’d be happy to make that more formal, if needed.

I guess one could train as a “normal” psychotherapist, although that looks like a six to eight year full-time study commitment, at least. And I wonder just how useful much of that individual-therapy training would be useful in the context of organisational therapy?

Personally, I’ve always favoured apprenticeships or communities of practice over education/training per se.

And then there’s the whole can of worms labelled “certification”. I’m sure I could rattle up a two day “Organisational Psychotherapy Master” (COpM) certification course, with an honest-to-goodness certificate at the end of it. £2000 a pop seems like a fair price for that. But REALLY? Certified Mastery of Organisational Psychotherapy in two days? I doubt. It’s taken me ten years so far, and I’m still only scratching the surface (and being so far from Mastery, even now).

I’d feel more comfortable seeing folks apply themselves to the subject, gain some early practical experience – possibly under the wing of someone with some relevant experience – and build their own skills and experience through application and interaction. I’d suggest the watchword here is “congruence”:

Congruence means that the therapist is genuine and authentic, not like the “blank screen” of traditional psychoanalysis:

The first element [of the three core conditions of the person-centered approach to psychotherapy] could be called genuineness, realness, or congruence. The more the therapist is himself or herself in the relationship, putting up no professional front or personal facade, the greater is the likelihood that the client will change and grow in a constructive manner. This means that the therapist is openly being the feelings and attitudes that are flowing within at the moment. The term “transparent” catches the flavor of this condition: the therapist makes himself or herself transparent to the client; the client can see right through what the therapist is in the relationship; the client experiences no holding back on the part of the therapist. As for the therapist, what he or she is experiencing is available to awareness, can be lived in the relationship, and can be communicated, if appropriate. Thus, there is a close matching, or congruence, between what is being experienced at the gut level, what is present in awareness, and what is expressed to the client. (Rogers, 1980)

– Bob

Further Reading

Carl Rogers On Person-Centered Therapy (pdf article)

Fundamentals of Organisational Psychotherapy

June 13, 2018
Organisational effectiveness, Organisational Therapy, Therapy
Leave a comment

Fundamentals of Organisational Psychotherapy

By popular demand, I’ve put together this post, which sets out some of the fundamentals of Organisational Psychotherapy (n.b. by no means all of them).

Note: This is a work in progress: I keenly invite your comments and questions.

Fundamental: The Nature of the Problem

The Marshall Model proposes that organisational effectiveness (productivity, product quality, staff engagement, etc.) stems from the collective assumptions and beliefs of the organisation as a whole. (Oftentimes, assumptions and beliefs of individuals concerned differ from those held collectively).

Thus, for organisations needing to improve their effectiveness, this entails a shift in these collective beliefs and assumptions.

The problem, then, for such organisations is: how to effect such a shift? Who owns the problem, and the resources to tackle it?

Fundamental: Organisational Psychotherapy is a Solution Strategy

Given the above statement of the problem, Organisational Psychotherapy proposes that Organisational Psychotherapy is a viable and cost-effective approach to addressing this problem. I.E. Organisational Psychotherapy provides a means for organisations to effect a shift in their collective assumptions and beliefs (also referred to as the organisation’s collective mindset, psyche, or memeplex).

Fundamental: Points of Leverage In A System

Donella Meadows proposed that maximum leverage for changing a system (such as an organisation) derives from 2) shifting the paradigm or mindset out of which the system arises, and 1) by acquiring the power to transcend paradigms. Organisational Psychotherapy provides a means for organisations to grasp and exercise these particular levers (see diagram, below).

Fundamental: Organisations Each Have a Collective Psyche

Organisational Psychotherapy as a solution is predicated on the assumption that every organisation has a collective psyche (distinct from the psyches of the individuals comprising the organisation). And that this collective psyche is amenable to therapy much as is the individual psyche.

Fundamental: Therapy Techniques for the Individual Psyche are Transferrable

There are over four hundred different types, styles or “schools” of psychotherapy for the individual. Many of these are well-established, well-researched and well documented. And many of these are transferable, in whole or in part, from serving individuals in therapy to serving organisations in therapy.

Fundamental: It’s the Client-Therapist Relationship That Matters Most

Much research indicated that for individuals in therapy, positive outcomes are contingent mainly upon the quality of the relationship between the client and their therapist. Organisational Psychotherapy proposes that the same dynamic holds for organisations in therapy – positive outcomes are contingent upon the quality of the relationship between the organisation and its therapist(s).

Fundamental: The Therapist is a Constant Exemplar of Congruence

In some schools of therapy (Rogerian Therapy, a.k.a. Client Centered Therapy, for example) the idea of congruence looms large. And the role of the therapist in modelling/exemplifying congruence assumes a major significance in the relationship between the therapist and the client.

In engagements with larger clients, where the workload may suggest more than one therapist working with the client during a given period, the body (team) of therapists, as a collective entity, also exemplifies this congruence.

Fundamental: Therapists Have No Agenda

Outwith the basic agenda of accompanying the client of its journey, the Organisational Psychotherapist has no agenda. No pet solutions to suggest, no proposals as to how the client might choose to become better. Simply accompanying the client on their journey, with compassion and empathy, is the thing.

Solutions, strategies, new assumptions, beliefs and behaviours are the domain of the client. It’s not the role of the therapist to suggest “improvements” or changes (as might a coach). Rather, it’s his or her role to lend empathy and emotional support to the client in their journey. A journey which *might* include the client discovering more effective strategies, behaviours, assumptions and beliefs to replace some or all of their original strategies, behaviours, assumptions and beliefs.

Fundamental: Psychotherapy is About Treatment (It’s not Psychoanalysis)

I hesitate to use the word “treatment”, with its connotations that the client is somehow less than health, or needs “fixing”. I find these connotations entirely unhelpful in the context of therapy. Yet the word is sufficiently recognised to retain some explicative utility.

As intellectual understanding blocks empathy (Cf. Rosenberg, Nonviolent Communication), the Organisational Psychotherapist tries to avoid understanding what might be happening within the client’s collective psyche. Empathy without intellectual analysis (nor judgment). Just be there for the client. The world is a scary place, the organisation’s journey can be lonely without a friend.

Fundamental: Avoidance of Dependence

Organisational Psychotherapy aims to proceed toward a future where the client can take care of themselves, without the need for external intervention or support from a therapist. A future in which the client has become sufficiently self-aware and skilled in self-care that it can sustain its journey from its own resources.

The journey to self-sufficiency make take time, and proceeds at the pace with which the client is (more or less) comfortable. That is, the experience of therapy may cause discomfort on occasion, but the pace of progress Is never set, or forced, by the therapist.

Fundamental: The Client (Organisation) Owns Their Progress

As in individual therapy, Organisational Psychotherapy proceeds on the basis that clients deeply want change, even if there might be resistance to varying degrees and from various quarters, from time to time.

– Bob

Further Reading

The Nine Principles of Organisational Psychotherapy  ~ Think Different blog post

Most Models Are Wrong

June 10, 2018
Culture change, Marshall Model, Organisational effectiveness, Rightshifting
Leave a comment

Most Models Are Wrong

“The most that can be expected from any model is that it can supply a useful approximation to reality: All models are wrong; some models are useful”.

~ George E. P. Box

George E. P. Box

George Edward Pelham Box FRS (18 October 1919 – 28 March 2013) was a British statistician, who worked in the areas of quality control, time-series analysis, design of experiments, and Bayesian inference. He has been called “one of the great statistical minds of the 20th century”. He repeated his aphorism concerning the wrongness of models in many of his papers.

The first appearance (1976) reads:

“Since all models are wrong the scientist cannot obtain a “correct” one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and overparameterization is often the mark of mediocrity.”

 ~ George E. P. Box

He wrote later (1978):

Now it would be very remarkable if any system existing in the real world could be exactly represented by any simple model. However, cunningly chosen parsimonious models often do provide remarkably useful approximations. For example, the law PV = RT relating pressure P, volume V and temperature T of an “ideal” gas via a constant R is not exactly true for any real gas, but it frequently provides a useful approximation and furthermore its structure is informative since it springs from a physical view of the behavior of gas molecules.

For such a model there is no need to ask the question “Is the model true?”. If “truth” is to be the “whole truth” the answer must be “No”. The only question of interest is “Is the model illuminating and useful?”.

~ George E. P. Box

What’s A Model?

The Marshall Model belongs to the group of models collectively referred-to as Scientific Models.

“A scientific model seeks to represent empirical objects, phenomena, and physical processes in a logical and objective way. All models are in simulacra, that is, simplified reflections of reality that, despite being approximations, can be extremely useful. Building and disputing models is fundamental to the scientific enterprise. Complete and true representation may be impossible, but scientific debate often concerns which is the better model for a given task.

Attempts to formalize the principles of the empirical sciences use an interpretation to model reality, in the same way logicians axiomatize the principles of logic. The aim of these attempts is to construct a formal system that will not produce theoretical consequences that are contrary to what is found in reality. Predictions or other statements drawn from such a formal system mirror or map the real world only insofar as these scientific models are true.

For the scientist, a model is also a way in which the human thought processes can be amplified.”

“Models are typically used when it is either impossible or impractical to create experimental conditions in which we can directly measure outcomes. Direct measurement of outcomes under controlled conditions (see Scientific Method) will always be more reliable than modelled estimates of outcomes.”

The Marshall Model

I’ve written a number of blogs posts (plus a White Paper) on the Marshall Model, and its relationship with Rightshifting, so I’ll not repeat that material here.

How is the Marshall Model Useful?

  • Explains the fundamental source of productivity – or lack of it – in organisations generally.
  • Predicts the likely path of attempts to “go Agile or “be Agile”, embark on Digital Transformations, adopt Lean or Theory of Constraints, etc..
  • Situates a range of approaches to business productivity along a spectrum (the Rightshifting spectrum), in order of effectiveness.
  • Defines the challenge facing organisations that wish to significantly improve their productivity and effectiveness.
  • Illustrates the role of the collective psyche (within social systems).
  • Offers a way forward to higher productivity, joy, engagement and seeing folks’ needs better met.
  • Provides interventionists with insights in how to intervene in organisations seeking to improve, similar to the way the Dreyfus Model provides interventionists with insights in how to intervene in situations where individuals seek to improve their skills. (How to best adapt and adopt styles of intervention to suit where the organisation is at, in its journey towards maximum effectiveness).
  • Offers a seed for building a shared mental model of the factors governing an organisation’s relative effectiveness, as well as a means to understand the mental models typically in play within organisations.

Some time ago I wrote a post on how folks might use the Marshall Model.

Aside: Please let me know if you would value an elaboration of any of the above points.

Summary

“Truth … is much too complicated to allow anything but approximations.”

~ John von Neumann

The Marshall Model is not Truth. It is truthy, in that it has some utility as described above. It is a hypothesis, one I’d be delighted for folks to debate, dispute and discuss. Do you have, for example, your own go-to model for explaining organisational productivity? Where does the Marshall Model sit, for you, on the spectrum of “highly useful” through to “not very useful at all”? Would you be willing to share your viewpoint or hypothesis on organisational effectiveness and productivity?

– Bob

Further Reading

All Models are Wrong ~ Wikipedia Entry
Scientific Modelling ~ Wikipedia Entry
George E.P. Box ~ Wikipedia Entry
Mental Models ~ Wikipedia Entry
Models Are The Building Blocks of Science https://utw10426.utweb.utexas.edu/Topics/Models/Text.html

The Marshall Plan

June 8, 2018
Antimatter principle, Community, Culture change, Dialogue, Leadership, Organisational effectiveness, Organisational Therapy, Rightshifting, Software development, Teambuilding
2 Comments

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

Status Quo or Change?

June 7, 2018
Organisational effectiveness
2 Comments

Status Quo or Change?

Doing things in the same (old) way appeals to organisations and their managers because it’s predictable. But for those organisations that want different outcomes (lower costs, faster delivery, better quality, or whatever) there arises a conflict between predictability and change. Learning (and improving) demands we try different approaches, experiment with new ways of working. But that impacts predictability. Or does it? Is this a real dilemma or just an imagined one?

Here’s a Conflict Resolution Diagram (also know as an Evaporating Cloud):



Aside: Maybe box A would read better as “Have a successful business in changing times”?

Evaporating the Cloud

Could we conceivably try different approaches without impacting predictability? Or maybe predictability is not as important as we lead ourselves to believe (whom amongst the people that matter hold it as a key need of theirs?) Or maybe we can achieve predictability by mean other than “using the old, established, tried and tested ways of doing things?” Maybe, even, the demand for predictability is what’s holding us back from “a successful business” and we just have to let go of that comforter in order to find real success?

What intervention would you favour, which assumption(s) would you challenge, in order to “evaporate” this cloud?

– Bob

Further Reading

Evaporating Cloud ~Wikipedia entry

Difficult Conversations

June 4, 2018
Antimatter principle, Dialogue, Listening, Nonviolent Communication, Organisational effectiveness, Rightshifting, Software development
1 Comment

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

Wants, Needs

June 3, 2018
Antimatter principle, Dialogue, Engineering, Innovation, Lamentation, Leadership, Management, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addressing the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

A Hiding To Nothing

June 2, 2018
Agile, Antimatter principle, Culture change, Dialogue, Engineering, Leadership, Management, Organisational effectiveness, Product development, Rightshifting, Software development
3 Comments

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob