Archive

Coaching

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

 

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 affords 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.

Unusual

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.

Therapy

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

HolyAgile

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?

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

TDR – Test Driven Relationships

TDD (Test Driven Development) seems fairly well known as a software development technique these days – even though uptake and understanding remains “patchy”. TDD purports to improve the quality of code by focusing on the intended behaviour of a piece of code before writing that code.

I believe that relationships – interpersonal relationships, relationships between people – are what really matters in work – and particularly in collaborative knowledge-work. Far more than code quality – although that’s handy, too.

One question which folks ask me regularly is “how might we go about improving the quality of our relationships?” I propose TDR – Test Driven Relationships might offer a way forward.

What is a Quality Relationship?

Psychology and psychotherapy have quite a lot to say about what makes for a quality relationship.

Gregg Henriques offers the “5 Cs” model (Conflicted -> Civil -> Cordial -> Close -> Connected)

Patrick Lencioni has his “5 Dysfunctions” model (Trust -> Positive conflict -> Commitment -> Accountability -> Results)

The Fundamentals of TDR

In improving relationships, it’s often helpful to try things out. For example, if we’re wanting to be more empathetic, it can be useful to try to guess how someone is feeling, and then ask them how close to the mark our guess is.

“In relationship, business, classroom, and parent-child conflicts, we can learn to hear the human being behind the message, regardless of how the message is framed. We can learn to hear the other person’s unmet needs and requests. Ultimately, listening empathetically does not imply doing what the person wants; rather, it implies showing respectful acknowledgment of the individual’s inner world. As we do that, we move from the coercive language we have been taught to the language of the heart.”

~ Marshall Rosenberg

Taking this principle and extending it, TDR says “define the results you expect – or desire – from an upcoming interaction with someone, plan an approach, have the interaction, and then compare the results against those expected / desired”. If the results don’t match up, refactor you approach to the interaction and try again.

As a reference and comparison, here’s the vanilla TDD four-step red-green-refactor process:

  1. Add a test – the simplest possible
  2. See it fail (red)
  3. Make all tests (to date) pass, using the minimum amount of instructions (green)
  4. Refactor

Why It Works

TDR helps us clarify our intent, and experiment in small increments with the way we relate to others, adjusting as we find things that don’t work so well, aw well as things that work particularly well.

“Every time I mess up is a chance to practice.”

~ Marshall Rosenberg

TDR also allows us to better keep the idea of “relationship quality” in our minds, and provides us with a practical means to focus on improving that quality.

For those who object to TDR on the grounds that it’s somehow fake, I offer the following advice:

“Fake it ‘till you make it.”

~ Neil Gaiman

How important is relationship quality to you? And what are you already doing about that, by way of e.g. deliberate practices?

– Bob

The Words We Use

Violence is so endemic in our society and workplaces that we rarely notice it. Nor notice its effects.

Why does it matter? Well, we humans generally feel less happy when victims of violence – however minor or unremarked. But setting aside that general point, anything that negatively impacts our state of mind has similarly negative implications for knowledge workers’ productivity and the quality of that work.

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

~ Peter Drucker

And one wildly underreported source of such difficulty is the unwitting violence that happens every day in our relationships at work.

To illustrate how unaware we can be about the violence we do to ourselves and others, you might like to consider some examples. Examples of some commonly used words which not only seem innocuous, but even carry imagined positive connotations. Even these oft-lauded words can harbour implicit violence:

Discipline (verb)

Most folks take this to mean e.g. self-discipline = forcing, compelling or otherwise obliging ourselves to do things we feel we should be doing. And disciplining others = forcing them, mainly through fear, obligation guilt, shame (FOGS), or the threat of punishment, to do the things we feel they should be doing.

Professionalism

Many folks take “professionalism” to mean “constrained by expectations about how something should be done”. Here again, if we but reflect a moment, we may see the violence inherent in this idea. For example, the fear of e.g. a sanction such as ridicule or shame, when one’s behaviour does not conform to that expected of a “professional”.

Responsibility

This notion often translates to an expectation of obligation. If we are responsible for something, then we (or others) expect us to act in certain ways. Once more, we may choose to see this as raising issues of self-violence (where we take a responsibility upon ourselves) or violence done to us (where the responsibility is conferred – explicitly or implicitly – by other people, or even by rules, policy, social mores, etc.).

We Can Choose Our Words

There are, of course, hundreds if not thousands of other words, in many languages, which carry an implication of violence. How often are we aware of those implications when choosing words, and of the consequences of such choices?

Would you be willing to share some words which you find violent, in effect?

– Bob

Further Reading

Domination Systems – Duen Hsi Yen

Can You Use A Scrum Master?

A giant tied down by little people

I don’t mean “do you have an opening for a Scrum Master right now?”. I mean, “if you hired a Scrum Master today, would you, your development teams and your organisation be able to get any real value out of him or her?”.

There’s a whole bunch of pathologies I see time and again in Agile adoptions. One set of such pathologies is around the role of Scrum Master. These pathologies, unchecked, result in situations which demoralise the new hires and the development teams alike, and rob the organisation of any value from having a Scrum Master, and even from the Agile adoption itself.

Fools Rush In…

The line of so-called reasoning which leads to this particular group of pathologies generally runs like this:

“I’ve just heard about this thing called Agile. Could we use it?”

“We need to do something about our software development around here. It costs too much / takes too long / is not predictable enough / produces low quality resulting in a poor customer experience / insert your gripe here.”

“I know, this new-fangled Agile thing looks like it solves all our problem. I read as much in an inflight magazine last week. Let’s get our tech folks to adopt agile.”

“What flavour of Agile?”

“Um. There are flavours? I’ve heard of something called Scrum. Seems quite common. Let’s go for that.”

“Right! The development teams will start using Scrum next Monday.”

“But they don’t know anything about Scrum. It’s quite different to how they’re working now, I guess. They’ll need someone to show them the ropes and train them in the whole thing. The Scrum book says so. That person is called the Scrum Master.”

“Ok. We’ll hire one of those, then. Now they can jolly well get on with it. It’ll be great. Problem solved – at last. Golf this afternoon?”

And so the scene is set for another train-wreck. Here’s an explanation of some of the pathologies implicit in this dialogue:

Scrum is a Thing

It’s not. It’s an entry point, an on-ramp, a way to get started. The sooner a team becomes comfortable with the basic principles of Agile, the sooner Scrum-By-The-Book can fall away, and the team can continue its journey in whatever directions it deems best, according to the unfolding and evolving situation.

Scrum Can be Mandated

It can’t. If the development teams have no choice but to adopt Scrum, are not involved in the decision, they will likely resent it from the very outset. And resentment breeds opposition.

The Scrum Master is a Management Appointee

They’re not. Or rather, all too often they are – which only compounds the issue of the involvement of the development team in key decisions. Lack of autonomy is not a good foot upon which to get started with e.g. Scrum. Giving a development team little or no say in who gets to be their Scrum Master will again exacerbate their sense of learned helplessness, and breed dissatisfaction and disengagement.

The Scrum Master Is a Trainer

They’re not. Maybe they have some Scrum knowledge, maybe not. (And no, certification will not provide you with any assurances about that, one way or the other). The Scrum Master is no policeman, either, despite some opinions to the contrary. Primarily, the Scrum Master is someone who speaks for the “improvement” of the way the work works, offering some counter-balance to the daily pressure to get stuff shipped. (See also: Two Masters). If they do bring some Scrum expertise to the party, that can afford some short-term acceleration for the team, but often at the cost of longer-term progress – delaying the onset of a team’s confidence in itself and in its ability to learn.

Change is Bounded to the Dev Teams

It’s not. Most of the issues impacting development teams will lie outside the control of the development teams themselves. The Scrum Master will act as a catalyst for the team to bring these issues to the attention of senior management – the only folks in typical organisations that have the scope of authority to get these issues sorted out. This means that the Scrum Master and/or Team will be a regular – and demanding – visitor to the executive suite. Have you space in your schedule for this?

The Problems are Known Beforehand

They’re not. Scrum was created to shine a light on each dysfunction in the organisation. Many of these dysfunctions will have been around for years, if not decades, hiding in plain sight. Managers may think they know what the problems are, Scrum will say something different. Are you prepared to revisit your fondest assumptions?

Hire and Forget

Many folks hiring Scrum Masters assume they can just hire and then leave the Scrum Master to just get on with “fixing the team”. Any Scrum Master worth their salt will demand much time from the senior managers outside the development function. Do you have the time to commit?

All Scrum Masters Are Much of Muchness

Certification can make it seem that all Scrum Masters offer much the same level of skill, experience, and ability to contribute. Not so. Scrum Masters, being human beings, are just as variable as other humans. Do you know the kind of person that will best suit where you want the organisation to be in three, six, twelve months from now?

The Individual Can Trump the System

Many organisations look to the Scrum Master hire to come in and “fix” the dev team, with little understanding of how the existing assumptions, policies, structures, etc., of the organisation can cripple even the best Scrum Master. Deming’s 95% applies here as much as elsewhere. Are you ready to change such things, to enable the Scrum Master to add real value?

The Scrum Master is an Interim Hire

If you believe that the Scrum Master is there to “kick-start” the team, then you’ll miss the key value-add of any Scrum Master (or Agile Coach, or Organisational Therapist, for that matter). Every dev team can improve faster, feel better, and produce better software with the full-time, long-term availability of a competent coach. If it works for e.g. sports teams, why not for dev teams?

The Scrum Master is a Management Patsy, Stooge or Dupe

There are undoubtedly some Scrum Masters out there that are just doing it for the money, willingly toeing the management line, caring little for real improvement or the well-being of their teams. Most, however, will push against the status quo. Which kind do you want to hire?

Scrum Masters Are Selfless

They’re not. They’re just human beings too. They have needs. Most often, the need to make a difference is strong in them. Stronger than the need to conform. Or the need to make money. Making a difference is what you’re hiring them for? But they’re not super-men and -women, able to wave a magic wand to make things happen. So are you prepared to see the changes the teams propose regularly get actioned? Or is their morale and continued engagement not so important to you?

Summary

Most times, those appointing a Scrum Master find themselves in a Market for Lemons – being unable to discern a good candidate from the rest. Making a “good hire” then becomes largely a matter of pot-luck. (See also: Make Bad Hires).

And once a hire IS made, the challenges, far from being over, are only just beginning. Are you creating the kind of conditions in which your new hire can thrive and add real value to your development efforts, or are you just tossing them into a maelstrom and letting them sink or swim unaided?

Good luck!

– Bob

Further Reading

The Perfect Scrum Master ~ Agile Scout

Wolf Magic

Wolves chilling

In a recent blog post I thanked @davenicolette for drawing my attention to an article by Eric Barker, and more specifically to the concept of the Omega Wolf. Setting aside the question of whether the behaviour in wolves is natural or forced, I share Dave’s view that the notion of Omega Wolf makes for a fine metaphor for a particular role in our organisations.

“A really successful team needs at least one person who is not a team player. Someone who’s willing to stand up to authority, to rock the boat. To not make everybody happy. To not pat everybody on the back.”

~ Eric Barker

“Every wolf pack has an omega who bears the brunt of pack members’ frustrations. This individual functions as a sort of social glue for the pack, defusing conflict and aggression before it harms the group’s cohesion…”

~ Dave Nicolette

When I read this, I instantly recognised myself and my roles in various organisations over the years. I also saw the way in which the Omega Wolf complements the Chaos Monkey so well.

And as with Chaos Monkeys, folks in the role of Omega Wolf can easily be misunderstood – as troublemakers, lamers, losers, doormats, clowns or maybe even worse, idealist.

“Looking at the big picture and the long view, the lowest ranking wolf—the omega wolf—may actually be the ‘cornerstone wolf’ — keeping the pack together and peaceful.”

~ Robert Lindsay

Looking at human organisations – and particularly the dysfunctional ones (there are other kinds?) – I’d suggest that the people in the Omega Wolf roles are the great unsung – and often unappreciated – heroes of highly effective – and joyful – teams.

My Omega Wolf Credo

  • I aspire to help people by defusing stressful situations and bringing people together in increasingly authentic fellowship and harmony.
  • I aspire to care for the young cubs, the new hires, and the other folks who may be feeling disoriented and wondering how to become more part of “the team”.
  • I aspire to help people by being playful and encouraging others to “play” more, too.
  • I aspire to help organisations and the folks therein by championing the value of joy and humane relationships in work.
  • I aspire to improve the quality of individual and collective relationships by illustrating the value of nonviolence.
  • I aspire to improve the cohesion of the team(s) and the organisation more widely.
  • I aspire to raise awareness of the value of authentic harmony, the role of the Omega Wolf in contributing to that, and to make Omega Wolf behaviours not only acceptable but highly sought-after.

Who are the Omega Wolves in your company? How much do they contribute to the well-being of the organisational “community”? And how well-understood are they – and the value they add – in this role?

– Bob

Further Reading

Wolfpack Programming

The Antimatter Principle

Photo-realistic simulation of matter-anti-matter annihilation

Antimatter is by far the most valuable substance, by weight, known to Man (around $25 billion per gram). It’s incredibly rare, amazingly expensive and difficult to produce, and yet is by far the most powerful energy source we presently know of. It’s also the very epitome of alienness.

Seems like a good metaphor for the Antimatter Principle – the only principle we need for becoming wildly effective at collaborative knowledge work.

The Antimatter Principle

Inspired by Jim Benson’s Personal Kanban, which has just two simple “rules” – “make work visible, and limit wip” – I’ve been seeking to simplify software and product development – or, in fact, any kind of knowledge work – and reduce it to just one rule:

“Attend to folks’ needs.”

The power of this simplification may not be immediately apparent, so please allow me to explain…

Attend To

Meaning, “pay attention to”. In a complicated or complex group endeavour such as developing a major piece of software, or tech product, we have the opportunity to pay attention to many things. What we pay attention to determines what gets done. Traditionally, these kinds of endeavour might pay attention to value, flow, cost, quality, customers or profits – to name just a few. But if we accept that people are central to this kind of work, then all these typical foci pale into insignificance alongside folks and their needs.

Folks’

Meaning, everyone involved. Software and product development endeavours typically involve lots of people. Not just the “doers”, but the “sponsors”, the “buyers”, and a whole host of other groups and individuals. Some folks will obviously be in the frame from the get-go, many other folks will only come into view as the endeavour unfolds. I have for many year used the term “covalence” to describe this perspective.

Needs

This reminds us that we’re working for and with people, and all people have needs, many of these tragically unmet. Needs are the universal lingua franca of the human race. Sadly, much too often overlooked or down-played. Here’s a list of needs as an example of the kind of thing I have in mind.

Expecting folks to gaily subjugate their personal needs for the Man’s coin is not only naive, but flies in the face of decades of research.

The Antimatter Principle asks us to remember to listen to our own deeper needs – and to those of others – and to identify and clearly articulate what “is alive in us”. Through its implicit emphasis on deep listening – to ourselves as well as others – the Antimatter Principle fosters respect, attentiveness and empathy, and engenders a mutual desire to give from the heart. This is oh so simple, yet powerfully transformative.

Wrap

Does the Antimatter Principle, and this explanation of it, meet *your* needs?

– Bob

Can’t Be Bothered

boredpeople

When folks appear disinterested, apathetic, bored with their work – and their involvement in it, or just happy to “settle”, what do you do?

Shrug indifferently? Sigh in despair? Tear your hair out? Shout at them? Quit?

Or do you bother looking a little deeper? Asking yourself “Why?”?
(Or even Five Whys)?

I’ve worked with many groups that, superficially, appeared indifferent, unwilling or unable to summon much – or any – enthusiasm for what they were doing. Excepting maybe feigning just enough enthusiasm to deflect the unwanted attentions of their higher-ups.

On those occasions when I’ve had the opportunity to delve deeper, I’ve always found not disinterested and bored people, but folks excruciatingly frustrated at not being able to do a good job. Demotivated by faceless corporatism, disinterested or downright obstructionist managers, demeaning policies, pointless make-work and, in general, so put-upon that I wondered why they ever stayed in post.

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

~ Fredrick Herzberg

What is a Good Job?

Many organisations, managers and teams never even get to first base (cf Herzberg) on this question. Fewer yet ever tackle the question of “good”.

Personally, I define a “good job” as one which meets the present, actual needs of the person doing the job. And it seems unlikely that other people will know what those needs are without listening to the people in question, and showing some interest in their personal needs, as human beings.

How often do we see organisations and managers seek out the needs of the people doing the work? How often do we encounter the prevailing assumption that “the needs of the work, the needs of the manager or of the organisation, trump the needs of the individual”?

Of course, if you rush headlong at the work, like a bull in a china shop, then there will be breakages. Including damage to folks’ morale and motivation. Maybe a little more obliquity might pay handsome dividends?

Hardly surprising, then, that many folks “can’t be bothered”.

Some Advice

Would you be willing to consider some advice, drawn from long experience in this area?

If so, read on.

If you are actually bothered about folks being bothered (not a given, by a long chalk), then do you believe in extrinsic motivation, or in intrinsic motivation?

If the former, then the way is relatively clear: Choose some carrots and sticks and apply them enthusiastically. Good luck with that.

If the latter, however, things become much less straightforward. How can we make people feel (and not just act) less bored, more keen? Well, of course, we can’t make people feel anything. So we’re obliged to consider how to bring about a situation where folks can find and grow their own enthusiasms.

How would you go about that?

– Bob

WarningSign Caution! Attempting to treat people as if they matter without winning the understanding and active support of your higher-ups and your peers may cause alienation, organisational cognitive dissonance, damage to your credibility, and to your career.
WarningSign Caution! Attempting to treat people as if they matter, without first winning their trust and understanding may cause suspicion, resentment, gossip, and unforeseen consequences.

Health Warning

WarningSign

Observations

I regularly read posts and articles informing managers and the like of this or that new technique for them to apply in their work. Here’s just one example amongst many.

Many of these techniques come from Agile folks, attempting – it seems – to encourage managers to move towards a more Agile stance in their methods, and in their relationships with the people they manage.

Feelings

I always feel a little anxious and peeved when seeing this kind of advice promoted without a health warning. I have in mind something like:

“Caution! Attempting to follow this advice without winning the active support of your higher-ups and your peers may cause alienation, organisational cognitive dissonance, damage to your credibility, and to your career.”

The question of safety is just beginning to gain a wider profile in the Agile community. Is safety of managers as much of an issue as safety of developers and testers when it comes to trying things out – such as adopting certain new, Agile-ish behaviours?

Needs

Such posts fail to meet my needs for “avoiding possible negative consequences (on behalf of readers)” and for “doing no harm”. I feel that encouraging managers (or other folks) to put themselves in harm’s way fails to meet principles 1. and 2. of my Nine Principles.

Requests

If you’re someone who publishes such advices to managers, would you be willing to include a health warning of some kind in your posts?

And if you’re someone who reads such posts or articles, would you be wiling to signal the absence of such warnings to their authors – and to other readers?

– Bob

Warning

WarningSign Caution! Including a health warning in a blog post or article may cause some folks to think twice about following your advice.

Further Reading

The Hippocratic Oath (Never do harm) ~ Wikipedia
Organisational Cognitive Dissonance ~ FlowChainSensei (blog post)

From Here to Eternity

Eternity

 

What Do You Want?

“Finding deficiencies and getting rid of them is not a way of improving the performance of the system. An improvement program must be directed at what you want, not at what you don’t want. And, determining what you do want requires redesigning the system, not for the future, but for right now, and asking yourself what would you do right now if you could do whatever you wanted to. If you don’t know what you would do if you could do what you wanted to do how could you ever know what you would do under constraints?”

~ Russell L. Ackoff

I work a lot with new folks. That is, teams and organisations that I have not worked with before, or for long.

One regular question I put to these folks is something like “where are you going?” As in, where would they like to be, what kind of future do they have in mind.

I have ceased to be surprised by the lack of coherent answers which ensue.

Most folks have no ides of what a “better future state” might look like, either in general, or specifically for them and their fellows.

I have found several reasons for this, including:

  • Too busy on delivery stuff to think ahead
  • Lack of motivation – no personal stake in the future
  • Absence of support and encouragement from the wider organisation
  • Lack of awareness of the possibilities inherent in a “better future”
  • A disconnect between folks’ needs and their assumptions about possible futures

Does your troupe discuss your common future? Do you have any kind of picture – fuzzy or coherent – about the kind of development shop you’d like your shop to become? How broad is your picture? Does it stretch beyond your own personal future to encompass your team, your shop, your whole organisation? And how far ahead do you look – today, a month, a year, eternity?

– Bob

The Management Violence Inherent In The Golden Rule

GoodyTwoShoes

I’ve never had much time for compassion. For me, the concept seems too violent, too manipulative to embrace it. I’m all for “connecting with others in meaningful ways”, and for generosity, and kindness, (although, niceness, not so much). And for a life of meaning and purpose, too.

com·pas·sion 

noun
1. a feeling of deep sympathy and sorrow for another who is stricken by misfortune, accompanied by a strong desire to alleviate the suffering.

I just don’t find it useful to lump all these ideas together under the banner of “compassion”.

Of course, compassion, especially compassion in the workplace, is going to be better than a lack of compassion. I just feel we can, if we but think about it for a moment, do so much better.

The Golden Rule is a great example of what I’m talking about.

It’s the sheer, brazen unilateralism of the Golden Rule that bugs me. At least, as it is most often, simplistically, perceived. Oh, and the violence inherent in the very notion of “rules”, too.

“Do unto others as you would have them do unto you.”

George Bernard Shaw spotted the flaw:

“Do not do unto others as you would that they should do unto you. Their tastes may be different.”

~ G. B. Shaw

So To The Platinum Question

And thus the Platinum Rule (or here, the Platinum Question) comes into sight:

“How about treating others the way they want to be treated?”

Of course, this means finding out how others might actually want to be treated. Which opens a whole new can of worms regarding dialogue, enquiry, empathy and, yes, humane relationships.

So how about we eschew compassion in favour of empathy and non-violence? How about we consider other folks’ tastes in relating to us, and others? How about we embrace not the Golden Rule, but the Platinum Question?

Would you be willing to give this a go in your workplace, with your colleagues, peers and (God forbid you have any) higher-ups?

– Bob

Further Reading

The Rise of Compassionate Management (Finally) ~ Bronwyn Fryer
The Compassionate Mind ~ Emma Seppia

Coaching and Deming

Photo of Dr. W E Deming

I regularly lament the relative obscurity of Bill Deming and his work. I’m not the only one. God only knows why he’s not better known. Just about everyone who knows of him – and in particular his System of Profound Knowledge – is a fan. How could it be otherwise?

Even just one aspect of his work – his so-called 95/5 rule – has so many implications for businesses everywhere.

I’m not going to get into that today, nor into all his many insights and contributions. Except for the seeming contradiction the 95/5 rule raises in the whole field of personal and team coaching (and, incidentally, training, as well as my immediate specialism these days, therapy).

Aside: By ‘personal coaching’ I’m thinking of things like agile coaching, life coaching, executive coaching and so on.

Here’s the thing: if we accept Deming’s observation that the system – the way the work works – is responsible for 95% of an individual’s (or team’s) performance (in a job or task), why “work on the five percent” (the individuals)? Is that not rather… incongruous?

Granted, folks sometimes hire their own e.g. life or fitness coaches for their own personal reasons. Let’s set aside these cases and focus on those rather more common cases where organisations hire the coaches for one or more people in the organisation. Agile Coaching seems a common example of this.

The aim of such coaching appointments is often to get the individuals being coached to “perform better”. And most often, the implicit assumption is that it’s the performance of said individuals (or, more rarely, teams) that should be the focus of the coaching efforts.

How many folks who seek coaches for their people and teams actually consider the 95/5 rule? How many coaches see their role as more like working on the system than working on the individuals concerned?

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

~ Frederick Herzberg

I can personally attest to the endless frustrations arising from coaching situations where it’s been the system that needed to change, not the fine folks already doing their best in badly designed, badly organised jobs.

– Bob

Further Reading

Herzberg’s Motivation Hygiene Theory 

%d bloggers like this: