The Organisational Psychotherapy Approach To Agile Coaching


What’s the point of an Agile Coach? I guess the most common answer would be “to make development teams more productive”. After all, Agile Coaches cost money, and they don’t do much in the way of development work themselves. If they’re not a “force multiplier” for one or more dev teams, then where’s the cost-benefit justification?

Personally, I’d suggest the most common reason, although rarely articulated as such, is “to raise the pace of improvement”. Or, worst case, to reduce the pace of degradation of performance (given that things are always changing, and some teams may not be able to even keep abreast of change).

There are two essential problems with seeing the appointment of an Agile Coach as a means to improve a development team’s productivity: The Motivation Fallacy and the Local Optimisation Fallacy.

The Motivation Fallacy

Many development teams have little to no manifest interest in improving, nor therefore in the pace of any improvement. This is often compounded or aggravated by the appointment (a.k.a. imposition) of a coach to “encourage” them. An iron first of coercion, even in a velvet glove of a smiling, happy coach, often offends. And rarely is the agenda for improvement part of any joined-up initiative. Much more often it occurs at the behest of one or two people looking to secure their personal bonus or make a name for themselves as innovative go-getters. Such personal agendas also serves to alienate people further, both the folks in the development teams and those folks up-stream and downstream on whose cooperation any joined-up approach would depend.

The Local Optimisation Fallacy

Unless the development team is the current constraint limiting the throughput of the whole organisation, improving the team’s productivity has little to zero effect on the productivity of the whole organisation. Some authorities on the subject go further and suggest that in these (non-bottleneck) cases, improving the team’s productivity will actually make the performance of the organisation as a whole worse. (Cf. Ackoff)

Even when the development team IS the current bottleneck, improving it soon moves that bottleneck elsewhere in the organisation. Agile Coaches and other folks in the development function rarely have the remit or authority to follow that moving constraint. And so rarely if ever does the improvement initiative continue in the newly-constraining area of the business.

Where Organisational Psychotherapy Comes In

Both of the aforementioned fallacies arise in organisations with low levels of congruence. Such organisations have a gulf between how they perceive themselves (self-image), their ideal self, and how they actually experience life. To paraphrase Carl Rogers:

“Organisations behave as they do because of the way they perceive themselves and their situation.”

Where an organisation’s self-image and actual experience are consistent or very similar, a state of congruence exists. Rarely, if ever, does a total state of congruence exist; all organisations experience a certain amount of incongruence.

Organisational therapy serves to help willing organisations reduce the gulf between their self-image and their actual experience. In other words, to improve congruence. Agile Coaches could do this, given the brief (remit) and skills – and some of the more effective ones likely do already. Albeit intuitively rather than with an explicit understand of what’s happening. Oh so rarely is this remit conferred, or sought, however.

The practical side to Roger’s Theory of Self states that being in a condition of incongruence is uncomfortable; therefore each organisation seeks to become more congruent. When the distance between the self-image and actual experience becomes too great, the organisation is more likely to exhibit both distress and anxiety. Likewise the people within it.

Thus organisational therapy helps to:

  • Increase congruence.
  • Reduce stress and anxiety levels.
  • Broadly improve cognitive function (through e.g. lower levels of stress and anxiety).
  • Indirectly, address a wide range of pathogenic beliefs, which in turn may lead to…
    • Improved motivation.
    • Increased collaboration across silos.
    • More joined-up initiatives (fewer local optimisations).

The Therapist’s Stance

All the above is predicated on the Agile Coach – if indeed it is he or she who becomes the agent in this kind of intervention – adopting more of a therapist’s stance:


– Bob


What If #4 – No Answers

What if we refrained from inviting answers, at least until we had sought our own? What if we refrained from providing answers, at least until someone had unequivocally asked?

“I don’t understand this” is a pretty common admission. Although not perhaps as commonly admitted as it is thought or experienced. And what do we do when our friends, peers, colleagues, loved ones make this admission to us? We jump to fill the void. To provide some answers. To help them in their understanding. Helping people to understand is a natural human reaction. But how helpful is it, really?

How often do we tell ourselves that we’re helping someone to understand, when we’re actually just helping them adopt our interpretation?

And what if we helped them to understand something and they came to their own understanding of it? An understanding at odds with our own? How would we feel then?

Personally, the joy I find in helping people understand something is as nothing compared to the joy I take in folks finding their own understanding. Even, and perhaps especially, when it differs from mine.

There are occasions when someone asks me directly. “Just tell me the damn answer!”. On these occasions I mourn for the loss of opportunity. For the lost chance to explore together. For the missed joy we might both have taken from finding answers together. And yet most times I’ll accede to the demand. Albeit with a heavy heart.

What if we refrained from inviting answers, at least until we had sought our own? What if we refrained from providing answers, at least until someone had unequivocally asked us? What if we just tried to listen, to hold the space, to empathise, and to do what we could to relate to people as fellow human beings, walking together for a while, as we each pursue our journeys?

NB. I’m not looking for answers here – at least, until you’ve found some of your own.

– Bob

Further Reading

What Is Clean Language? ~ Marian Way

Other Posts In This Occasional Series

What If #1 – No Management
What If #2 – No Process
What If #3 – No Telling
What If #5 – Continuous Improvement Is Useless
What If #6 ~ Agile Nirvana
What If #7 – No Work
What If #8 – Agile Never Happened


Why Me?

Not, not some lament about the unfairness of life. Rather, an explanation of why, these days, I choose to call myself an Organisational Psychotherapist.

I’ve spent the majority of my 30+ year career studying many “systems” of software and product development (the way the work works). And studying the relationships those systems have to the organisations (a.k.a. systems) they serve. I’ve come to hold some considered opinions about the nature of the problems that most organisations (still) face:

  • Just about all organisations are much less effective than they could be.
  • Their relative ineffectiveness is a consequence of the beliefs these organisations collectively hold about the nature of work.
  • These collective beliefs generally go entirely unexamined.
  • Left to their own devices, organisations are unlikely to devote attention to examining these collective beliefs.

Complementing these opinions, I have some observations about human beings, as individuals and as groups:

  • People generally do not act on, nor deeply learn from, received advice.
  • Very occasionally, advice may trigger someone or some group to go find out (experiment) for themselves.
  • Behavioural changes go hand in hand with changes in assumptions and beliefs.
  • Most often, advice can rob people of their ownership of a problem, reducing the chances of their choosing to find out for themselves.
  • Canned, labelled and pre-packeged solutions offer a crutch to the unengaged and disinterested, substituting for curiosity, inquiry, and deep learning, and exacerbating learned helplessness.
  • Only deep learning (of e.g. governing principles) can afford the possibility of long-term, sustainable change.

Putting these things together, I long ago gave up selling advice for a living. (You might recognise that role as something many choose to call “consulting”).

For years I felt comfortable in the role of coach. Until that too became obviously of little help to most of those on the receiving end. Particularly, as is so often the case in so-called Agile coaching, where those receiving the coaching have no say in the choice of coach or their own part in the whole sorry affair.

And so I’ve come to the role – and stance – of the therapist. As in:

“A person who helps people deal with the mental or emotional aspects of situations by talking about those aspects and situations.”

I find it meets my needs, in that I can help those who seek it to find meaningful connections with themselves and each other, and to see more of their innate potential realised in the context of “work”. And it afford me the opportunity to do something different to the norm.

So now I don’t tout, sell or give advice. I don’t coach. I just try to listen, hold the space, empathise, do what I can to relate to people as fellow human beings, and walk together for a while, as we each pursue our journeys.

– Bob

How To Connect With Folks’ Needs

“The curious paradox is that when I accept myself just as I am, then I can change.”

~ Carl R. Rogers

My key focus as a therapist is providing the wherewithal through which folks can conduct their own inner dialogues. That’s to say, providing an opportunity, a time, a space, for folks to each have a conversation with their own self. And in a group setting – my more common scenario – for the folks in a group or team to have conversations with and amongst themselves.


I find that many groups and teams – and I hear this applies to individuals too – rarely have any kind of meaningful, purposeful or skilful internal dialogue. So, rarely does a group explore its needs, or the needs of its members. And even more rarely, in any kind of effective way.


When I’m working with a group, I’m looking for opportunities to open up their internal dialogue and allow it to flourish. Assuming that’s what they want, of course. I say working, but ideally it’s not work but rather play. Playfully looking for opportunities to support the group’s needs for effective internal reflection, play, sharing, connection and mindfulness.

It’s Mostly About Them

I’m way less focussed on me understanding their needs, and way more focussed on helping them uncover, surface, explore and accept their feelings and needs, for and amongst themselves.

“The kind of caring that the client-centered therapist desires to achieve is a gullible caring, in which clients are accepted as they say they are, not with a lurking suspicion in the therapist’s mind that they may, in fact, be otherwise. This attitude is not stupidity on the therapist’s part; it is the kind of attitude that is most likely to lead to trust…”

~ Carl R. Rogers

And to myself, I generally ask: “How can I best provide a relationship through which the folks in this group or team may best connect with – and thereby attend to – their own personal and collective needs?”

– Bob

Further Reading

Attending To The Needs Of Others ~ FlowChainSensei
On Becoming A Person: A Therapist’s View Of Psychotherapy ~ Carl R. Rogers



Twelve Signs Of A Great Agile Evangelist


1. Don’t Talk About Agile.

The first rule of evangelising Agile is: You do NOT talk about Agile. The only folks who want to hear the word – or the gory details – will be those who are looking for a badge of some kind. Or for bragging rights at the golf club. Or tyre-kickers. Strong prospects will not be interested in the label, or the details, but rather in the fact that you understand and care about their problems (empathy) and have useful – and proven – solutions for them to apply. Some of these useful solutions may involve Agile things. Shhh. For example: Talk about their business issues, and the issues common to their business domain. Telcos might be interested in better customer service, and better customer experiences when using their online services, apps, etc..

2. Know Your Cause

“Doing Agile” is not much of a cause, really. Even “being Agile” doesn’t quite cut it. Why are you enthused by Agile? Personally, I see it as a means to move folks closer to a workplace – and a way of working – that allows those folks to realise more of their potential and get more of their needs met – whilst seeing others’ (customers, suppliers, managers, shareholders) needs better met, too. For example: “Effective agile means people more engaged with their work, more focussed on our customers – and our customers more engaged with our products.”

3. Get down with your motivation

Whatever it is that motivates you, embrace it. People can sense half-heartedness and dilettantism. For example: “We’ve seen major steps forward in happier workers, and organisations which are a joy to work in, and with.”

4. Work With Fertile Soils

Plant your cause’s seeds in fertile minds. With folks that are ready or at least willing to listen. If they think they know what their problems are, and that their existing strategies are good for addressing those problems, don’t waste your – or their – time. There will be a few folks who are either unaware of their problems – these may listen, or aware but dissatisfied with their current strategies (solutions). For example: Engage with new prospects, equipped with a checklist of those things that you believe signify fertile soils. Make it an early priority to gather the information needed to complete the checklist. If a new prospect rates poorly on the checklist, decline their kind offer to take things further.

5. Connect To Folks’ Needs

Make your cause relevant and specific to individuals and their existing needs. Help them see how your cause is a more effective strategy for them than their existing ways of working, and thinking. Of course, to connect with folks’ needs, you’ll have to attend to (explore) those needs. For example: Ask your contacts in the organisation what they need. Enquire as to whether there might be others they could suggest with whom you might have similar conversations. Discuss how new ways of working might address some of their needs, individually and collectively.

6. Supply Metastrategies

Many folks need help in acquiring a suitable metastrategy or two before they can move on from their existing strategies and adopt the one(s) you are proposing.

7. Be Honest About The Pitfalls

In many sales situations, standard advice is to avoid talking about the negatives. In Agile adoptions, avoiding mention of the pitfalls only sets up the client for failure. As DeMarco and Lister said in Waltzing With Bears “Risk Management is Project Management for grown-ups”. Maybe your audience has few to no adults? Then RUN! For example: Talk about the rates of failure (generally estimated at somewhere between 50% and 95%). Talk about the common failure modes (faux agile, management discomfort and resistance, change fatigue, organisational cognitive dissonance, etc.). And talk about some possible mitigations for those common modes.

8. Talk About The Benefits

What are the benefits? Not the old chestnuts of “faster, cheaper, quicker”. But benefits that directly address their own particular specific pain point(s). For example: “I understand your biggest competitor can add major new features to their flagship product in six weeks or less. With the necessary changes, we believe that your team could do the same, in timescales as short as two weeks.” In my post “Pitching Agile” I describe using The Three Box Monty as a sales tool in “selling agile” to executives.

9. Make The First (Or Next) Step A Small One

The Kanban Method, for example, cunningly says “start where you are”. Although this begs the question – where else could one start? In any case, engage the prospective client in discussing options and help them come up with their own way forward. For example: Visualisation (of a part of the current workflow) or explicitly limiting work-in-progress (recognising current implicit limits) might be places to start.

10. Don’t Try To Motivate People

Rah-rah motivational speeches and miraculous stories are best left for the God Squad. They have an audience that responds to that kind of thing. Use empathy rather that motivation.

11. Be Organised

Wow. Really? Not “appear well-organised” But actually be well-organised. For example: Have standard templates, checklists, and other documents and planning tools ready and to hand for each new prospect. Keep track of contacts, needs, dates, conversations, and so on. Again, clients and prospects can tell when you’re organised.

12. Be Humble

Don’t proselytise dogma. Don’t make grandiose claims. Don’t make any claims at all. Not even when you have ironclad evidence. Evidence rarely sways anyone. Great evangelists connect with people, and their existing needs. If what you’re selling isn’t what they need, then smile, wish them well, and move on.

– Bob

Further Reading

The Art Of The Start ~ Guy Kawasaki
The Art Of Evangelism ~ Guy Kawasaki
Value Forward Selling ~ Paul DiModica

Are You Stuck?


Are you stuck between a rock and a hard place? Is your heart telling you to do something, when your head is telling you not to? Or maybe it’s the other ways round – but still as problematic?

Do you see no way forward? No light at the end of the tunnel? Just endless busywork?

Are outside pressures getting to you? Do you have people relying on you? Is your job on the line? Your self-image under threat?

I see this kind of dynamic all too often. I say all too often because it bothers me. To see someone in a quandary bothers me. And it bothers me all the more because, so often, someone can be so stuck that they can’t even see how to find help. Or that “help” might actually help. And I know there are people that can help. Coaches, therapist, friends, fellows. Including me. It’s what I live for, actually.

Is there anything to be done? Yes. And I’m not going to use fear, obligation, guilt or shame to “help” you to get unstuck. Actually, I’m not going to use anything. Just invite you to consider if you are stuck at the moment. And if so, invite you to check out the many, many articles, posts, etc., out there on the intarwebs, offering ideas on getting unstuck.

Because, I’ve found the key to getting unstuck is recognising one’s stuckness in the first place. Oh, and then doing something about that. Natch. There’s even an app for that.

“Getting unstuck is half the fun in life.”

And if you find something that works for you, maybe you’d like to share it, through a comment, here?

– Bob

Further Reading

16 Ways To Get Unstuck ~ Tiny Buddha
7 Ways To Get Unstuck ~ Sura


Write Your Own – Flow

One of my core specialisms these days is organisation-wide product development flow. I was about to write a new blog post on the subject when I saw this, which reminded me there could be a better way:

Students learn better when they think they’re going to have to teach the material.

This set me to thinking. Why write a blog post? That’d be a bit like teaching on the subject, wouldn’t it? How about posting e.g. an outline of topics (using something like the Pyramid Principle) and see if folks would enjoy researching and writing their own version of the post (or article, or mini- e-book)?

So, here’s my outline for a book on Product Development Flow. If you’re inspired to fill in some of the blanks, like you were trying to inform/teach others, great. I’d be happy to help with some pointers, etc. Just drop me – @FlowChainSensei – a line on e.g. Twitter. And if you’d like some wider audience for what you write, please feel free to post the URL or whatever in the comment section below, or tweet me so I can retweet for you.

And if you’d value someone to whom present your writing directly, I’ll be delighted to volunteer to read it.

Here’s the outline:

Product Development Flow

  • Introduction
    • Purpose of this book
  • Overview
  • Definitions
    • What is a “Product”?
    • What is “Value”?
    • What is “Product Development”?
    • What is a “ValueStream”?
      • Where do value streams come from?
      • Prod•gnosis
    • What is “Flow” (of e.g. Value)?
    • What is “Product Development Capability”?
    • What is “Product Development Capacity”?
  • Key Organisational Capabilities / Concepts
    • People
      • Collaboration
      • Motivation
    • Innovation
    • Entropy
    • Continuous Improvement
      • Kaizen
      • Kaikaku
    • Variation and SPC
    • Work In Progress (WIP, WIP limits)
    • Making things – like Flow – visible
    • Organising Intent (a.k.a. Commander’s Intent, Auftragstaktik)
    • Relative Effectiveness
    • Quantification
    • Emotioneering
    • Lean
      • Lean Product Development
      • Lean Startup
      • Lean Service
    • Idealised Design
    • Systems Thinking
    • Queueing Theory
    • Organisational health
    • Philosophy and doctrine
    • Financials
      • Cost of Delay
      • ROI
  • Foundations
    • Russell L. Ackoff
    • W.E. Deming
    • Peter Drucker
    • John Gall
    • Douglas McGregor
    • Taiichi Ohno
    • Eliyahu M. Goldratt
    • Peter Senge
    • John Seddon
    • Donella Meadows
    • Allen C Ward
    • Michael Kennedy
    • Don Reinertsen
    • Tom Gilb
    • Steve McConnell
    • Nancy Kline – Thinking environments
    • Argyris, Isaacs, Bohm et al. – Skilled dialogue
  • Exemplars
    • TPDS – The Toyota Product Development System
    • FlowChain
    • Product Aikido
  • Other / miscellaneous

– Bob

Further Reading

Lean Product and Process Development ~ Allen Ward
Product Development for the Lean Enterprise ~ Michael Kennedy
The Principles of Product Development Flow ~ Don Reinertsen
Lean Product Development Flow ~ Bohdan W. Oppenheim (pdf)
Sketching User Experiences ~ Bill Buxton
Managing the Design Factory ~ Don Reinertsen
Learning To See ~ Mike Rother


Get every new post delivered to your Inbox.

Join 12,634 other followers

%d bloggers like this: