Archive

Coaching

Quintessential Morons

Quintessential morons are not those folks with a shortfall in intellect, but those folks with a shortfall in awareness of the limitations and boundaries of their personal world view.

The latter group are not open to changing themselves because they remain unaware of the need for, and benefits to themselves and others of, personal change.

The world is stuffed full of quintessential morons.

Chances are, you’re one too.

– Bob

Highlight Problems, Avoid Solutions

It’s wayyy easier to provide solutions than to help folks find their own solutions. What are the consequences of this observation?

  • For consultants, trainers, pseudo-coaches and others whose income depends on selling “solutions”?
  • For folks seeking long-term, permanent solutions to their problems?
  • For folks who choose to hire consultants or other experts to solve their problems for them?
  • For folks habituated to delegating the finding of solutions to their problems to others?

Voltaire asks us a rhetorical question:

“Is there anyone so wise as to learn by the experience of others?”

~ Voltaire

I’ll not be offering any solutions to this conundrum. I am available help you along the path of finding your own.Do get in touch!

#IANAC (I am not a consultant).

– Bob

Further Reading

Rother, M. (2010). Toyota Kata: Managing People For Continuous Improvement And Superior Results. Mcgraw-Hill.
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 16 Jun 2022].

The software crisis will NEVER be over unless and until senior management comes to understand software development, and what makes it highly effective (in those extremely rare cases where it IS highly effective).

What will enable that understanding? Not the promotion into senior positions of folks with front-line experience (most have no experience of effective practices).

Coaching/education might do it – when the senior folks seek it out and engage with it themselves.

I believe exemplars can help (which is one of the reasons I wrote Quintessence).

The most promising way forward is normative learning, especially when guided by capable facilitators. How many senior folks are ever likely to go to the gemba and see what’s REALLY effective?

Alternative: Dispense with management entirely. Also highly unlikely, but beginning to gain some traction as an idea. Cf Reinvention Organizations (Laloux 2014), etc.. This approach doesn’t actually address the issue of folks understanding what effective software development looks like, though.

Further Reading

Laloux, F. (2014). Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness. Nelson Parker.

 

The Organisational Psychotherapy Standup

Daily stand-ups rapidly become tedious to the point of irrelevance. They rarely address core issues, participants generally preferring to gloss over issues so they can get back to “the real work”, e.g. coding, as soon as possible each morning.

Here’s how the Scrum Institute describes the Daily Scrum (Standup):

The Daily Scrum Meeting is a maximum of 15 minutes. These meetings take place every working day at the same time in the same place.

It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team.

Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.

All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience.

Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions.

Question #1: What activities have I performed since the last Daily Scrum Meeting?

Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan?

Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work?

Impediments

Q: What are the biggest impediments to a team’s progress?

A: The collective assumptions and beliefs of the organisation as a whole (and, marginally, of the team itself).

How often are these impediments discussed or even surfaced at the Daily Scrum/standup? Almost never. Or never.

How much do they impact the progress of the team? Lots. Really, lots.

So, for Question #3 (above), who’s going to raise the organisation’s – and team’s – collective assumptions and beliefs impeding or blocking the team’s progress? And who’s going to address these impediments/blockers on behalf of the team?

– Bob

Further Reading

Marshall, R. W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub)

Marshall, R. W. (2021). Memeology: Surfacing and Reflecting On The Organisation’s Collective Assumptions And Beliefs. Falling Blossoms (LeanPub)

Marshall, R. W. (2021). Quintessence: An Acme for Highly Effective Software Development Organisations. Falling Blossoms (LeanPub)

Techniques

Let’s take a look at one (of many) nuanced distinctions between coaching and Organisational Psychotherapy: techniques.

Suggesting

Many coaches will suggest techniques to their coachees, techniques to make their lives easier, and to tackle certain challenges. For example, software coaches might hear their coachees remark that code quality could be better, and invite their coachees to look at TDD as a technique to help the coachees improve it. Or coachees might complain that their code is too difficult to change, and the coach might suggest looking at the idea of connascence, and the techniques derived from that.

Contrarywise, organisational psychotherapists will typically refrain from making suggestions, in this case regarding techniques. Instead, they are likely to ask open, Socratic-style questions inviting reflection, such as: “Are there known techniques techniques that might help improve code quality?” and “Are there ideas that might help with making your code more amenable to change?”

Clean Language formulations of such questions may help further:

Client: “We suspect we have some issues with our code quality.”
Therapist: “What kind of issues are those issues?” …conversation continues…

(Note: The above are rather contrived Organisational Psychotherapy examples, as such topics seem relatively unlikely in the context of Organisational Psychotherapy).

Continuum

Of course, Clean Language and Socratic questions are not the sole domain of the Organisational Psychotherapist. Both coaches and Organisational Psychotherapists may move on a continuum from leading questions to open questions, and back. The distinction I’m trying to illustrate here is that coaches may tend towards leading questions, therapists toward open ones.

And rigid adherence to purely open (Socratic) questions may rankle with clients and coachees, who may just want a straightforward answer, from time to time. One skill of the therapist and coach both, is to be able to resolve this kind of situation to the best satisfaction of the client.

– Bob

Further Reading

Sutton, J. (2020). Socratic Questioning in Psychology: Examples and Techniques. [online] PositivePsychology.com. Available at: https://positivepsychology.com/socratic-questioning/.

The Rightshifting Cause

[Here’s a post that’s been languishing in my “Drafts” folders for ten years now. It dates back to the time when I was just beginning to make my way into Organisational Psychotherapy, as a therapist. Not that I knew it then…]

The Agile Coaching Agenda

I used to to introduce myself to people as an Agile coach. Not anymore. Nowadays, I don’t really know what to introduce myself as. Here’s why.

The term ‘coaching’ is overloaded. There’s sports coaching, agile coaching, life coaching, business coaching and many others. All of them have things in common, but they’re not the same. As well as coaching, there’s mentoring, consulting, advising and whatnot. These terms are sometimes used interchangeably and sometimes they seem to overlap. I’m guessing I’m not the only one who’s had trouble differentiating between them.

Lately I’ve studied coaching with Results Coaching Systems. They have a very strict definition for coaching, which says coaching does not have an agenda. In coaching, according to their definition, the goals are always set by the person being coached. I’ve grown to like their definition of coaching.

However, this does raise a conflict. How can anyone (myself included) call themselves an agile coach if coaching shouldn’t have an agenda? Agile is an agenda. Agile is a solution that I – or my clients – are proposing. And coaching shouldn’t have an agenda. Calling anyone an agile coach actually starts to sound very contradictory if you see coaching as not having an agenda.

So I’ve started introducing myself as a software development coach. That’s more honest. Right? Well…

John Seddon has recently thrown more fuel into my existential fire with his talks. John is the father of Vanguard, a systems thinking approach for service organizations. One of his key points is that if the organization as a whole is doing the wrong things the significance of the method(s) used in its software development efforts is very small. He says “Agile is about doing the wrong things faster”. And I think I’m sure he has a point.

The fact that Agile revolves so much around software development has started to feel like a constraint. Like a sub-optimization. I’ve had this feeling for quite a while, but John seems to have reinforced it. This is also a discussion that has been on going in the Agile community for quite a while.

I would like to see myself as someone who looks at the whole. The whole organisation. The whole business. And of that whole, software development is only a small – mostly inconsequential – part. I want to help organizations do the right things with the right methods. Focusing on software development is not enough.

Thanks to John, even ‘software development coach’ feels weird. So what am I suppose to call myself now?

[Spoiler: As you may have noticed, I’ve come to describe myself as an Organisational Psychotherapist.]

– Bob

If Coaches Were More Like Therapists

In retrospect, back when I was an Agile Coach, my style was always towards the therapy end of the stance spectrum (see table, below):

This did tend to rile management, most of whom seemed to think that a coach should be directive, more like a manager or project manager than anything else.

I guess many experienced Agile coaches would recognise part of their roles as working with the organisation as a whole, rather than their immediate team(s) and people.

Nowadays, in the role of Organisational Psychotherapist, I monitor my interactions for any signs of non-therapeutic coaching, and nip such things in the bud. When I can.

It’s pretty obvious I believe there’s more value in therapy than coaching, both other for my clients and myself. Put another way, in working with tech people, tech teams and tech organisations, I find Organisational Psychotherapy attends to folks’ needs better than coaching.

So, if coaching were more like therapy, what differences might we see?

  • Less advising and guidance, and creating more opportunities for people to discover their own answers.
  • Increased belief and trust that people are capable of taking responsibility for their work.
  • A shift of focus away from technical skills and processes, towards quality of interactions and interpersonal, interdepartmental relationships.
  • A change in practitioner:player ratios (therapists can serve more folks concurrently) with concomitant reduction in costs.
  • A more enjoyable experience at work.
  • Increased initiative-taking and innovation.

What difference might you expect to see if coaching were more like therapy? And would you expect to see any advantages in that?

– Bob

Five Reasons Why Agile Coaching is Bullshit

By popular demand, here’s a short post expanding on a recent pithy tweet of mine:

“Agile coaching” is bullshit – for various reasons.”

1. Agile is a Means to an End, not the End In Itself

“Software development coach” might be a (slightly) less bullshit title. For many organisations, and people, quick and cheap software development is the goal. Setting aside why “software is the goal” in itself is a bullshit concept (see: #NoSoftware), “Agile coaching” implicitly excludes other approaches and other means to improving software development. Other approaches which have proven more effective than Agile. And other approaches which the players (coachees) might reasonably seek to explore or experiment with, yet find themselves unable so to do because those other approaches are deemed beyond the pale. Why not start down a road towards the goal that matters (better products, higher margins, more profits, to make money now and in the future or even – and most realistically – maximising the bosses’ well being), instead of driving into the Agile cul-de-sac?

2. Individual Technical Focus

As coaches, (in theory) Agile coaches follow the interests of the folks they’re coaching. In most coaching contexts (i.e. outside of the software domain) coaches have no agenda of their own beyond assisting their players (coachees) grow and develop their skills and abilities – as those players themselves see fit. In practice, technical folks generally seek to develop their individual technical skills and abilities – which hardly matter in the grander scheme of things, such as from the broader business perspective) – and recoil from any suggestion that other skills and abilities might also be important. Things like interpersonal skills, dialogue skills, business skills, serving the needs of the users and other folks that matter, etc..

3. Agile Coaching is an Imposition

I’ve never seen an Agile coach get hired at the request of the people they’ll be coaching. Nor selected by the folks they’ll be coaching. I hear it happens, but so rarely as to be an extreme anomaly.

4. Coach as Manager

There’s a lot of talk about (middle) managers becoming coaches to their people. In most practical scenarios, Agile coaches are expected by the people that appoint them to become managers of the people they’re coaching. I’d call that regressive. And bullshit.

5. Kaizen vs Kaikaku

In theory (for example, with Scrum), Agile coaching supports the team in reaching out across the organisation to address systemic issues affecting the team’s performance (kaikaku). In practice, for all the above reasons, this almost never happens. The Agile coaches, sensitive to not biting the hands that feed them, avoid raising issues that might disrupt other parts of the organisation, and limit their focus on improvements local to their team (kaizen). Which is entirely understandable, given the coaches’ brief and the dynamic of their position (who’s paying them and keeping them in a job). As Shakespeare wrote :

“To be [remain in a job, helping locally], or not to be [rocking the boat and being vilified and let go]: that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune [refrain from raising thorny organisation-wide issues],
Or to take arms against a sea of troubles [raise those issues and thanklessly suffer the consequences],
And by opposing, end them? [’Tis a consummation devoutly to be wished.]“

– Bob

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)

Coaching, Scrum Mastering, and Expertise

[Tl;Dr: Is it more, or less, effective for coaches, etc. to have technical (non-coaching) abilities?]

Over the years I’ve heard every kind of opinion on whether technical expertise is an asset or liability for coaches, Scrum Masters, and the like. Some folks, mainly executives, have sworn they would never hire a Coach or Scrum Master with technical expertise. Others, mainly coaches and Scrum Masters, have held much the opposite opinion. Those being coached have rarely expressed an opinion (although I suspect that’s because they don’t get asked, or think it won’t count, and not because they’re indifferent on the subject).

Personally, I tend to the opinion that, if it were down to me, I’d look for folks with excellent and demonstrable coaching skills, and not worry about the presence or absence of technical abilities unless they seemed intrusive and likely to interfere with the coaching dynamic. I recognise the argument that technical people lend more credibility to like-minded (i.e. technically capable) coaches because they find it easier to respect and identify with such folks. I also believe this argument to be a red herring, at least in the case where the coach or Scrum Master is effective and capable in the Coaching or Scrum Mastering skill-sets.

This is probably a good place to mention the Inner Game, and the suggestion by one of its founders, Sir John Whitmore, that “technical” knowledge and experience is a decided handicap for coaches and the coached, alike. In his book “Coaching For Performance” he tells several stories about this phenomenon, in particular that of the tennis group who, deprived of their regular tennis coach (and tennis expert) improved much more quickly under a substitute coach (with much coaching and skiing experience but no tennis experience).

Given that opinions on this topic seem all over the map, and many (mainly fruitless) discussions continue, I wonder if you have any experiences you’d be willing to share here?

– Bob

Further Reading

Coaching For Performance ~ Sir John Whitmore

The Organisational Psychotherapy Approach To Agile Coaching

GroupTherapy

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:

Tweet20151124

– 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

 

%d bloggers like this: