Archive

Ethics

Sticky Change

Just about everyone involved in team-building must by now have heard of – if not actually read – Patrick Lencioni’s book “Five Dysfunctions of a Team“.

In this book he describes the “five dysfunctions” that any team faces – and has to overcome – on the path to truly effective teamwork. (What DeMarco and Lister call “jelled teams“).

The Roots of Ineffective Change

When working with relatively ineffective organisations looking to Rightshift, I generally see sincere, committed and engaged folks trying out new ideas and new ways of working. (Note: I try to avoid working with organisations where folks are insincere, lacking in commitment, and disengaged). But all too often I see such attempts at innovation abandoned long before they have been mastered, and even before they have been applied enough to assess their merits (i.e. their value, or utility). In other words, most changes just do not stick. Why does this happen?

I attribute it to at least two reasons.

Change is Simple, Isn’t It?

The first is a general belief that introducing new ideas into the organisation is going to be relatively simple and straightforward. With a willing workforce, with relatively little (perceived) resistance to change, why would introducing new ideas be difficult? This is particularly true of organisations with Ad-hoc or Novice Analytic mindsets (see: The Marshall Model white paper).

Why Bother Making Commitments?

The second reason, and somewhat a consequence of the first, is when folks fail to commit – formally and publicly – to what they will do. (See also: the GROW model from Sir John Whitmore, Coaching for Performance).

Note: There are lots of models, methods, workshop exercises, etc. to help teams build mutual trust, the ability to have positive and productive conflict, the ability to make commitments, to raise standards of mutual accountability, and to downplay status and ego. Some I have used to good effect in the past include:

  • Social Styles (Wilson Learning). My first choice for teams who want to get to know one another better in the context of collaboration at work.
  • StrengthsFinder (Gallup). Very useful to help individuals better understand their own talents (strengths). Share the results to build mutual understanding.
  • The Keirsey Temperament Sorter. (A kind of MBTI assessment). Ditto.
  • Meyers-Briggs Type Indicator (MBTI). Ditto.
  • The Belbin Team Inventory. Ditto, plus highlights potential “gaps” in team makeup.
  • Various Exercises from e.g. “The Fifth Discipline Fieldbook” and “Overcoming the Five Dysfunctions of a Team” (c.f. Further Reading section, below).
  • Purposeful Dialogue (c.f. David Bohm, Chris Argyris).
  • Mutual Learning (e.g. Argyris and Schon, Roger Schwarz & Associates, Nancy Kline)
  • Team Coaching exercises from Coaching for Performance
  • Joint Exploration of issues using e.g. Mind Maps, Value Maps, Value Stream Maps, Current Reality Trees, Evaporating Clouds, and other Theory of Constraints, etc. tools.

For those who relate better to visual forms of information, I have drawn up a Current Reality Tree (CRT) to better illustrate this scenario:

Fellowship – Mutually Accountable

If you have read or watched The Lord of the Rings, you might note that members of the Nine regularly make commitments to one another, but rarely need to call each other on those commitments (with the possible exceptions of Peregrine Took and Boromir of Gondor). In other words, mutual accountability happens more-or-less naturally, and with little occasion for challenge or conflict. This aspect of fellowship contributes to my belief that fellowship is a beneficial model for collaboration throughout an organisation (and between collaborating organisations, too).

Summary

Why would anyone think that effective organisational change (improvement) was:

  • Any less difficult than e.g. developing quality software products?
  • Any less valuable, commercially, than the ability to develop quality software reliably and predictably?
  • Any less worthy of a considered, deliberate, disciplined and intentional approach of its own?
  • Any less worthy of investment and commitment of e.g. dedicated (full-time) people to make it happen (c.f. Scrum teams)?

Maybe for the reasons listed in this post?

– Bob

Further Reading

The Fifth Discipline Fieldbook ~ Peter M. Senge et al
Overcoming the Five Dysfunctions of a Team ~ Patrick Lencioni
First Break All the Rules ~ Marcus Buckingham and Curt Coffman
Solving Tough Problems ~ Adam Kahane
Staying Lean: Thriving Not Just Surviving ~ Cardiff University (long PDF)
The Four Obsessions of an Extraordinary Executive ~ Patrick Lencioni

Planning to Flourish

This is a follow-on to a previous post entitled “Focus”, and looks at what might happen after an organisation has held an initial focussing session.

For organisations on a rightshifting journey, thinking and talking with terms such as “assessments”, “symptoms”, “problems” and “solutions” (a.k.a. “treatments”) can in fact add to folks’ anxieties.

Assessment

Most therapeutic interventions start out with some kind of “assessment” by the therapist. From the therapist’s point of view, this is mostly about getting to know their new client, and establishing some rapport. But the very use of the term can be interpreted by the client, unfortunately, as that the therapist is making some judgements or evaluations of the client’s state of mind. And this in turn can lead on to some degree of dependency and learned helplessness. Not good outcomes for the client.

Anxieties

As a consequence of participating in a focussing session – where many symptoms (or as Theory of Constraints calls them, “Undesirable Effects”) are surfaced, perhaps for the first time – I suspect many of the folks involved form the idea that there’s something decidedly “wrong” with their organisation (and, by association, maybe with themselves, too).

In this context then, the organisational therapist can come to be seen as having the role of helper – or worse, judge or validator of the organisation’s ideas and plans. And therapy becomes a byword for “returning the organisation to normal”.

“If we can give up attachment to our roles as helpers, then maybe our clients can give up attachment to their roles as patients and we can meet as fellow souls on this incredible journey. We can fulfill the duties of our roles without being trapped by over-identification with them.”

~ Ram Dass

As an organisational therapist, I believe in the power of compassion and equanimity.
But these are not the sole prerogative of the therapist. On the contrary, they are available to, and potentially valuable for everyone in the organisation.

“I have found that the greatest degree of inner tranquility comes from the development of love and compassion. Cultivating a close, warmhearted feeling for others automatically puts the mind at ease. It is the ultimate source of success in life.”

~ Dalai Lama

Treatment Planning

This was going to be a post about how to write a Treatment Plan (a.k.a. Care Plan). But simply regarding the state (symptoms and root conditions) of the organisation as something that “needs fixing” seems like a problem in itself. Hence the long preamble, above. The term “Treatment Plan” I think might contribute to the confusion, and to the risks, as well as to the state of mind that organisations can unwittingly adopt where they see “Treatment” a.k.a. problem-elimination as the means to achieve their end (a healthy and flourishing business).

To paraphrase some wisdom from the world of Positive Psychology:

“The absence of problems is not success.”

Until we come up with a better label than “Treatment Plan”, then, let’s continue anyway and look at how we might plan some positive interventions for the organisation.

For those familiar with Agile methods, we can see a Treatment Plan as much like a product backlog. Initially empty, as the organisation decides to focus on particular issues, various “improvement stories” can be added to the backlog, and prioritised for action. The highest priority “improvement story” becomes the focus of the moment. If using Theory of Constraints as a framework, this will be a story about the current constraint of the organisation.

Like a product backlog user story, each improvement story may benefit from some grooming prior to implementation. Theory of Constrains suggests various tools, including the Negative Branch Reservation and the Pre-requisite Tree to help in this.

Note: In the FlowChain approach, organisation-wide treatments (“improvement stories”) are integrated with the continuous flow of new product features and user stories in one seamless enterprise backlog.

“If I don’t know I don’t know, I think I know. If I don’t know I know, I think I don’t know.”

~ R. D. Laing

[My apologies for the relative incoherence of this post. A sign of thought-in-progress.]

– Bob

Further Reading

Flourish ~ Martin Seligman
The Solutions Focus ~ Mark McKergow
The Happy Secret to Better Work ~ Shawn Anchor (TED video)
The Advantage ~ Patrick Lencioni
Scientific Proof That Happiness is a Choice ~ Shawn Anchor

Dumb Fraud

This post (*link amended to a Wayback Machine archive) – and its assenting commenters – illustrates why folks lauding Agile are irredeemably screwed. For as long as folks are dumb enough (ignorant of the facts) or fraudulent enough (in possession of the facts but choosing to ignore or suppress them) to believe that we can improve organisations without regard to the issue of local optima, Agile implementations will continue to fail by a ratio of 3:1 or greater (*link amended to a Wayback Machine archive).

So, I’m kind tired of dumbsters and fraudsters whining that the issue of local optima doesn’t matter.

Here’s just one note from Ackoff on the subject: “70% of Business Improvement Programs (TQM, Downsizing, Benchmarking) Decrease Performance” (*link amended to a Wayback Machine archive). If you think the same issues do not apply to Agile, then you’re dumb – or in denial, which is much the same thing in my book. And if you think they do apply to Agile, but you’re not going to mention it to your customers and clients because it’s, ahem, inconvenient, then you’re a fraud. Or worse.

If you’re looking for a non-ranty, reasoned explanation of the subject, may I refer you Ackoff, Senge, or most relevant I think, Goldratt (Theory of Constraints)?

But perhaps despite the opening, the aforementioned post (re: Bitching about local optimisations) was more about making a start, doing what you can, and gaining data from experimentation. Well, I’m all for that, with the important caveat (irony of medical analogy not lost here) of doing no harm.

Ethics

And if you’re hoping (for indeed it is much more of a hope that a certainty) that “making the true bottleneck apparent” to your paying customer or client will have a positive effect, then maybe you might like to exhibit the integrity, courtesy (and courage) to place the risks and possible outcomes (scenarios) on the table before deciding whether to play the cards you’ve been dealt – or to fold?

I think Argyris would approve of that.

– Bob

Further Reading

The Goal ~ Eliyahu M Goldratt
Agile Coaching – Maybe All You Can Do Is Send a Hallmark Card ~ Eric Laramée

Why Does Agile Work?

From the response to my recent post, Barking Up The Wrong Tree, it seems like I did a good job of “burying the lede“. So here’s the key thought:

We don’t know why Agile works.

Oh, there’s a whole bunch of theories, beliefs, assumptions and what have you. But no definitive evidence as to the key ingredients, and how to combine them. Like a Christmas Pudding, which ingredients do we need for a good pudding? Which can we safely leave out? Which ingredients simply add to the flavour or texture, and which constitute the essence of a Christmas Pudding? How does the mixing and cooking affect the result? How should it be brought to the table and presented? What ingredients does a software development team or organisation need to be effective, whilst still calling what they do “Agile”?

And most importantly of all, can we have a nice dessert without having a Christmas Pudding? Would Plum Duff or Mince Pies serve us just as well?

It seems like a lot of folks – including consultants, coaches, etc., seem unconcerned over this. “Given that the developers are happier, I don’t need to know any more” seems to be the general position of some. I gasp in astonishment at this. Maybe it’s just me. I was always taking things apart to find out how they worked when I was a child (but see the section “Complexity”, below). And I subscribe to William Kingdon Clifford’s arguments about the ethics of belief, too.

Let’s set aside the issue of why Agile doesn’t work, for another time (more Agile adoptions fail to deliver the expected benefits than succeed, by a ratio of at least 3 to 1).

Instead, let me make the case for why knowing matters:

Why We Need to Know

“He who loves practice without theory is like the sailor who boards ship without a rudder and compass and never knows where he may cast.”

~ Leonardo da Vinci

If we have no understanding of why our practice(s) work, we are like Leonardo’s sailor, rudderless and at the mercy of fickle fortune. With even a modicum of theory, however, we can at least begin to make choices about where we’re going. Actually, the thought occurs to me that maybe some Agile consultants and the like don’t worry because they have no destination (future state) in mind. Maybe, for them, just being “at sea in the Agile boat” is all they need. Especially if there’s wonga in it. Sounds like being “all at sea” to me.

And maybe some know the waters in which they sail, and the regular tides and the winds, well enough to arrive where they intend. All very well for the knowledgable, in familiar waters.

Do you need to know?

Complexity

Of course, a development team or organisation is a social system, not a machine. So we’re in the realm of complexity, and complex adaptive systems. This means that we can’t simply take the system apart, to examine how it works by considering its individual constituents. That would be Analytic thinking, in any case.

So I don’t propose it’s easy to understand why Agile works (when it works, if it works), or even that it’s possible, in any absolute, mechanistic, definitive sense. Nor do I claim to understand it myself.

But I do claim to understand some of the attractors and barriers involved, and so, some of the ingredients of our Christmas dessert. And in my experience, there’s only a limited overlap between those and the ingredients of the Agile Christmas Pudding.

We all know the proof of the pudding is in the eating, but what proficient chef would not want to know the likely ingredients involved?

– Bob

Further Reading

The Ethics of Belief (1877) ~ William Kingdon Clifford

Mea Culpa

Marcin (@mfloryan) asked me a while ago if I could ‘balance’ (or complement) my posts about Lemon Agile Consultants and the problems of having managers. He suggested another post exploring how some developers seem unwilling to adopt or engage with Agile development methods, or appear disinterested in the whole idea of improvement – either of themselves or the working practices in which they participate.

The Peg

I’ve since been struggling to find a ‘peg’ upon which to hang this idea, and thus, hopefully, make it interesting and relevant. So here it is: mea culpa, mea maxima culpa. My mistake – it’s all my fault.

Assumptions, Assumptions

It seems to me that implicit in the general question of “why do some developers seem uninterested in Agile – or the wider issues of improvement” lies the assumption that anyone in their right mind should be so interested.

Most of the folks that I know, talk with regularly, identify with are so interested.

Thus a lack of interest seems an aberration, a deviation from the norm. I seem to have succumbed to the fundamental attribution error – attributing the behaviour of others (the disinterested developers) to dispositional factors. Factors such as; they can’t be bothered, they’re unimaginative, they have poor a sense of social responsibility, they lack a sense of teamsmanship, and so on.

Are We Learning Yet?

How about we learn from the fundamental attribution error and admit the possibility of situational factors playing the key role? I’m not trying to deny the widely-reported observation that some developers do behave as if they have little interest in raising their personal skills, or the capabilities of their group, team or organisation. But how about considering why this should appear so?

Awareness

Number one on my list of possible reasons why, is that no one ever told them that it’s even possible to spend time on, invest effort in, self-improvement and/or group improvement. (The A.R.C. coaching mnemonic reminds us that Awareness is at the root of commitment to e.g. action). I mean, it’s not like this possibility is taught in schools or Universities, is it? The capacity for “divergent thinking” is actively degraded by our educational systems, according to @SirKenRobinson. Nor is the possibility for intentional improvement taught or experienced in the workplace, either, by and large.

Absent any such information or awareness, is it reasonable to expect folks to have some kind of natural, inborn predisposition towards self-improvement or group improvement? In the general case, I think not. (I’d be delighted if anyone can share any research or findings on the presence or absence of such a predisposition).

Other Factors

And then there’s a whole bunch of other situational factors which can come into play in any given set of circumstances. Can you think of some that might apply in your context, in your team or organisation? (If yes, might you like to share them, here?) .

So yes, I’ve fallen foul of an unwitting assumption about these developers’ dispositions. But maybe, just maybe you could find it in your heart to pray for me? And maybe have a chat with them about their perspectives – on the issues of both self-improvement, and improvement more generally?

Thanks. :}

– Bob

Further Reading

The Three Ingredients of Commitment (Agile Studio Blog post)
Coaching For Performance ~ Sir John Whitmore

All Executives are Unethical

[This post first appeared as a White Paper in October 2008. I have reposted it here for wider accessibility.]

doing the right thing – the moral case for rightshifting

Are all executives unethical? This White Paper argues that, absent objective evidence, it’s simply unethical for executives to believe that product and software development in their organisations is reasonably effective.

the ethics of belief

London, April 11, 1876. There is uproar in the House. But this is not the House of Commons, rather the Grosvenor Hotel, and the furore is not political but – more unusually perhaps – philosophical.

William Kingdon Clifford – then professor of mathematics and mechanics at University College London – and the youngest ever person to be accepted into London’s elite Metaphysical Society, is presenting his inaugural paper. His audience includes the likes of Alfred Tennyson, William Gladstone, Thomas Huxley and the cream of London’s intelligentsia. The title of his paper is “The Ethics of Belief”.

Even before he finishes his reading, half the audience have stormed out of the room in protest. The remainder are on their feet, heartily engaged either in shouting him down or cheering him on.

What did the audience find so contentious about Clifford’s proposition? In his essay, he asserts that whatever someone chooses to believe cannot be exempt from the ethical judgement of others. A belief may leave someone open to a charge of unethical behaviour, depending on whether they have earned “the right to believe it”.

ethics in the development of software-intensive products and services

London, October 2008. Waves of financial crises crash upon the bulwarks of the World’s financial system. Ordinary people in all walks of life look upon the excesses of business in a new, and distinctly unflattering light. What has happened to the traditional business values of probity, social responsibility, ethics? Good questions indeed. Management – and especially financial management – has become tarnished. Executives are regarded with suspicion, even contempt.

Of course, recent events have only served to propel these issues into the public eye. In many avenues of management – and over many years – complacency, self-interest and greed seem to have overturned diligence, responsibility and probity. I believe we could all benefit from taking a long hard look at what we have become.

My own focus of concern is the arena of software and product development. I have seen literally hundreds of organisations in the business of developing software-intensive products and services in the course of my career. Most of these businesses have been wasting enormous amounts of time, money, effort, and human potential, through their unwittingly inefficient approaches to the practice of software development.

“…whatever someone chooses to believe cannot be exempt from the ethical judgement of others.”

And in most cases, little or nothing of any effective, practical value is done to address the situation, or if done, then not sustained.

In my experience this almost always comes about because those nominally responsible for the situation – the senior executives of a company – honestly believe that their software development people are doing the best they possibly can (even though that rarely seems good enough).

So here’s the rub:

Do executives have the right to believe that their people are working as productively as possible – even if they have not gathered and considered the evidence?

Is such a belief, even when sincerely held, justifiable when such an executive has acquired his or her belief…

“…not by honestly earning it in patient investigation but rather by stifling his doubts? And although in the end he may have felt so sure about it that he could not think otherwise, yet inasmuch as he had knowingly and willing worked himself into that frame of mind, he must be held responsible for it.”

But what if disaster (or merely loss of profit) does not befall the business? Would the executive be any less guilty?

“Not one jot. When any action is once done. it is right or wrong, forever; no accidental failure of its good or evil fruits can possibly alter that. The man would not have been innocent, he would only have been not found out. The question of right or wrong has to do with the origin of his belief, not the matter of it; not what it was, but how he got it; not whether it turned out to be true or false, but whether he had a right to believe on such evidence as was before him.”

Prior to Clifford, the established intelligentsia presumed that beliefs could never be examined in an ethical light. A gentleman could believe any damn thing he pleased.

Until recently, it seemed as if that presumption still held sway in many organisations (including HM Government). But today, William Clifford’s question comes back to haunt us. Yes, executives may truly believe that people are being as productive as possible – but do they have any right to believe it?

about the author

My name is Bob Marshall and I’ve been a specialist in the transformation of organisational performance – particularly in the software development and business technology arenas – for the past twenty years or more.

I became a “Rightshifter” in the first place because of the egregious waste of time, money, effort and – above all – human potential that I saw time and again in organisations trying to develop software-intensive systems and products. So many people have such a poor time at work, frustrated and unfulfilled every day, in the majority of left-shifted organisations out there.

And the main reason for all this misery and waste? A simple belief that things are OK. Or at least, not amenable to improvement. Such a belief seems widespread, particularly amongst senior executives. So, before I make the case for Rightshifting as an ethical and moral imperative, allow me to describe in a little more detail just what I mean by “Rightshifting”.

rightshifting

Nowadays, the profitability – even the very survival – of most organisations relies on the ability to consistently produce (or acquire) software-intensive technology at an economic cost, and then integrate that technology into their lines of business (LOB). Yet few organisations ever give much thought to building and growing their ability to do so.

The following chart shows the distribution of technology organisations, according to their relative effectiveness at producing useful software:

Note: Although this chart is essentially anecdotal in its representation of organisational effectiveness, there’s much empirical data from e.g. ISBGS showing a very similar curve for individual projects.

By “Rightshifting”, we’re talking about the process of moving organisations to the right along the horizontal axis of this chart.

Most people don’t expect organisational effectiveness to be so unevenly distributed – with such a disproportionately high number of relatively ineffective organisations.

 

This distribution suggests that most software personnel have never seen software development at its best (or even, good). Their unfamiliarity with effective practice gives rise to a natural scepticism about whether things are really any better anywhere. Even people who have worked in the software industry for twenty or thirty years might never have seen software development practices anywhere near their best.

Most people will have spent their entire careers working in organisations over on the left-hand side of the chart. But some lucky few have seen for themselves that the best organisations are indeed much better than the rest.

Thus, by “Rightshifting”, we’re talking about the process of moving organisations to the right along the horizontal axis of the above chart.

the ethical and moral imperative for rightshifting

How do you feel about people wasting their time? I’m talking here specifically about the waste of effort, time and resources during the working day. There’s the obvious economic cost, of course. If employees are wasting time, by definition that’s costing their employer money. In software development, both the waste – and the cost – are often significant, but rarely visible.

However, I’m not going to dwell on this aspect in this article. Instead I want to talk about the morality of waste. Or rather, the immorality of it all.

We’ve already seen how Clifford caused uproar amongst his peers by suggesting that belief is subject to ethical scrutiny. And I’ve suggested that most executives’ belief that things are OK within their software development shops fails that ethical test.

But I feel it goes further than that. Not only is executives’ naïve belief in the productivity of their workforce unethical in itself, but the consequences – for individuals, the business and wider society – are immoral too: waste, misery, stress, friction, conflict, disrespect, under- achievement, despondency, profligacy, demoralisation and frustration, to name but a few.

the ethical way forward

So what to do? First, even before looking at the reality of the situation, on the ground, in their own organisations, I would suggest that responsible executives need to take a look at themselves – and their own motivations and culpability. Have they “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

Have executives “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

If the latter, then I suggest executives are ethically bound to go look for themselves at the reality of the situation in their organisations. Some may feel uncomfortable doing this, lacking the necessary technical skills, or even simply the time. This should be no bar, however. Various specialist organisations exist to offer the necessary audit and review services. These organisations can conduct Clifford’s “patient investigations” and furnish the objective evidence.

Having the necessary evidence in mind, executives may then take pride that their beliefs pass the ethical test.

Of course, having real evidence to hand will likely show that the business has much work to do to by way of Rightshifting. So then let the journey commence!

And finally, executives with a new-found or renewed ethical sentiment may begin to examine their peers’ beliefs in an ethical light, too. Thus, ethical business, and a more ethical society at large, grows stronger. Or is that too much to hope for?

In closing, I leave you with the words of Bertrand Russell:

“What is wanted is not the will to believe, but the wish to find out, which is its exact opposite.“

– Bob

copyright ©2008 http://www.fallingblossoms.com 

The Familiar Credo

When starting Familiar, ten of us came together for a day to discuss the possibility of starting a company, explore and exchange our personal values, and take a look at our enthusiasm for working together on something radical. This is what we came up with:

Our Credo

We believe…

On People
  • People are capable of amazing things. With a just little support and encouragement, people can achieve just about anything. No limits.
On Purpose
  • We exist as a community solely to help as many people as possible come to better understand themselves and what’s important to themselves as individuals; and to help each of them (us) make those important things happen.
  • We must subordinate everything else, even our very existence, to this Purpose.
  • To continue to fulfil our Purpose we must meet the basic needs of the group: food, money, shelter, peer respect, etc. (c.f. Maslow’s hierarchy of needs).
  • Just as creatures need air to live but do not live for air, we regard these basics as necessary prerequisites to continue living, but in no way the purpose of life.
On Success
  • We must measure our success in terms of the degree to which we meet our Purpose.
  • We can only gauge our success when we agree what it is we’re trying to achieve.
  • Success, particularly in the Information Age, depends utterly on having the full commitment of well-informed people who really want to make a difference.
  • Commercial success counts for nothing if we lose sight of our deeper Purpose.
  • We must constantly guard against gauging our success in terms familiar to other businesses (such as growth, profitability, financial wealth, fame, etc.).
  • Our emphasis on our Purpose will bring far more material success (as an inevitable by-product) than would ever be possible if we tried to make material success the end in itself.
On Sustainability
  • We can sustain our ideas, ideals, values, understandings, improvements and the like only by identifying or inventing suitable mechanisms and implementing them as integral elements of our enterprise.
On Work
  • Work can be the most fulfilling, exciting and absorbing activity known to man.
  • We oppose the notion that work has to be mundane – Death to Greyness!
  • Work exists both to provide people with an environment to find out more about themselves and what motivates them as individuals, and as a valuable forum for social interaction and exchange.
  • People must demonstrate their suitability for particular assignments – no one has an automatic right to meaningful work; it’s not part of the contract, folks!
  • People should regard working through Falling Blossoms as a form of social contract. So long as and to the extent that it suits all parties, it may continue – when it ceases to suit any party it need not continue (and no hard feelings!).
  • Combining all the various facets of life often seen as separate and distinct, such as work, play, social, domestic, fun, earning a living, etc. are all but different facets of the holistic entity that is Life.
On Trust
  • To allow personal growth and learning, and as a matter of simple respect, we have no alternative but to trust intelligent people to make their own choices.
  • People cannot reasonably demand or expect trust, they have to earn it.
On Respect
  • People must expect to be treated no better and no worse than they themselves would treat others.
  • People cannot reasonably demand or expect respect, they have to earn it.
On BHAGs
  • Our operational objectives (Big Hairy Audacious Goals) must always underpin and strengthen our Purpose, rather than undermine or sideline it.
On Commitment
  • Having someone take responsibility for resolving an issue requires them to have gained a certain awareness of the need to resolve that issue.
  • Having someone’s commitment to resolving an issue always requires them to have personally and intimately accepted responsibility for the issue.
  • Commitment therefore comes from an informed view of what needs doing, along with a basic necessary willingness to pitch-in and make a difference.
  • Our job is therefore to help folks become aware of what’s needed, and then help them become aware of ways of meeting those needs.
On Process
  • Intelligent, committed, experienced people still perform better, accomplish more, and have more fun, when supported by established ways of doing things (accepted local best practice).
On Competition
  • Even if we’re not constantly getting better at meeting our Purpose (and all the things that go to help make that happen), we can be certain our ‘competitors’ are.
  • In line with our view of Familiar as primarily a ‘community of practice’, we do not compete so much with other businesses, but rather other forms of community experience.
  • If we fail to compete on these terms, we cannot expect to retain people’s interest, involvement and commitment (at least, none who share our particular Purpose).
On Growth of the Enterprise
  • Growth for its own sake has little merit.
  • We will look to grow when and only when that growth allows us to move closer to meeting our Purpose, or to bring our Purpose to a wider community.
– Bob

Kinky Agile Sex

Linkbait Apology

If you’ve arrived here expecting some kind of titillation or advice on athletic sexual technique, then, as Ackoff once observed, you may “feel like a pornographic movie being shown to people who’ve just engaged in sex… in short, anti-climax”.

Oh, and if you don’t enjoy ethical dilemmas, this post is probably not for you, either. Sorry.

The Lede

So, here it is. The ethical dilemma in question:

When do the noble aims and aspirations of Agile Coaching, Agile Software Development, etc., cross some invisible line and degenerate into “base and unworthy use” of folk’s talents and abilities?

My contention is that this happens all too often.

Why it Matters

I see and hear of a lot of folks that are unhappy or stressed-out by the uneasy tension that exists between many Agile people and teams, and the wider organisations that they serve. This makes me want to help. To the extent that talking about things helps, that’s what I’m doing with some of my blog posts, including this one.

Words, Words

I have to thank @pablopernot for guiding me to the roots of the word “coach”, including the insight that “En Normand, le terme coche désigne une prostituée ; le mot encore utilisé aujourd’hui dans toute la Normandie” [Translation: In Norman , the term coach designates a prostitute; the word is still used today all over Normandy].

You can see where this is going…

pros·ti·tu·tion

[pros-ti-too-shuhn, -tyoo-]  noun

2. base or unworthy use, as of talent or ability.

I know many Agile coaches, Scrum Masters, Agile Developers, and Agile folks in general. Many of these are highly talented, with many fine abilities – not Lemons. I feel for them in the situations in which they often find themselves – prostituting their talents and performing unnatural acts, against their natural inclinations and better judgements, for money. If that’s not kinky, then I don’t know what is.

kink·y

[king-kee]  adjective

3. (Slang) marked by unconventional preferences or behaviour, as fetishism, sadomasochism, or the like.

4. having to do with someone or something strange or weird.

In case you’re wondering about what I mean by “performing unnatural acts”, etc., here’s just a few things that some of my Agile friends have mentioned to me recently:

  • Coaches being asked to provide estimates for a project, even commit to them on behalf of their team
  • Scrum Masters being compelled to “open” the black box of the Scrum iteration and report on progress / status during a sprint.
  • Developers being moved from one team to another at the behest of management and without the consent of anyone involved.
  • Teams being “stuffed” with narrow specialists, with regard to neither flexibility nor social “fit”.
  • Teams compelled to conform to corporate “standards” with regard to development tools, practices.
  • Teams precluded from implementing improvements because they “deviate from the Book“.
  • Restricted (or no) access to business domain experts.
  • First deployment into production deferred until six months after project start.
  • Scrum Masters whose time is divided between a number of teams, to the detriment of all.
  • Being asked to do things that will likely undermine the trust, commitment and cohesion of the team.
(If you have any other examples, I’d love to add them to this list).

Historical Parallels and Ironies

I spent some months working in Munich, Germany in the mid-90’s. One of the strangest things this repressed Anglo-Saxon discovered was that German brothels were legal and state-licensed. The parallels between my status in Munich as a IT contractor and the girls working in the brothels seemed ironic.
Deeper ironic asides:
  • Although foreign IT workers and sex workers at that time were both required to register with the Police, foreign IT workers were not required to be regularly “tested”.
  • The charging for licences seems strangely analogous to the Certification scams long foisted on the Scrum community (and, indirectly, its clients) : “Pay us for even the very opportunity to be exploited.”

Moolah

It’s all about the dollar, baby.
“Most [sex workers] actually become numb to it. They begin to view sex as a very emotionless thing. Most prostitutes will do anything but kiss on the mouth.”
Of course, I’m not trying for one moment to equate the travails of sex prostitution with the much more cosy and comfortable prostitution of Agile Coaching, Scrum Mastering, Agile Consulting, Agile Development, etc.. But when the practices and/or outcomes are so doubtful (or even distasteful), why else do it, except for the money? And yes, I know the justifications trotted-out in defence of this sorry situation:
  • Everyone has to make a living, somehow.
  • Some of the ‘Johns’ (like the development team members) do enjoy the experience, at least in the short-term.
  • Most jobs are some form of prostitution.
  • Even folks who are not paid money for their work, or who are unemployed, prostitute themselves in other ways.
These all seem like pretty thin excuses, to me.

Kinky Clients

When money is the primary motivation, then is it also true that anything goes? If the client asks for “strange or weird” things – that is, strange and weird (not to mention distasteful) from the Agile perspective – should we accede graciously, cavil but comply, or refuse altogether? Where to draw the line? Can we even draw any kind of line, when it’s all about the dollar, baby?

Exploitation or Symbiosis?

Some folks say that sex prostitution exploits women (the workers). Some say it exploits men (the clients). Most regard it as regrettable. Many regard it (for example, the Germans) as necessary. Nearly everyone chooses not to talk or think about it much, if at all. You’re probably quietly cursing me for even mentioning it. Again, where’s the line between exploitation and symbiosis?

What’s Wrong with Prostitution, Anyway?

My back-of-a-fag-packet definition of prostitution is “any activity that would not normally be undertaken in circumstance of choice, free will and mutual consent.” How many Agile Coaches, Consultant, Scrum Masters, etc, can honestly say they would be servicing their current clients were it not for the money? There are some, I know. And fair (e.g. consensual) exchange is no robbery, after all.

This post lays out the whole thorny question quite well, I think.

Maybe one distinction in the case of things Agile is the nature of the (implicit) contract underpinning the exchange: The Agilist will serve the client, including their kinky requirements, in exchange for money – and, more importantly, for the opportunity to make a positive difference (e.g. to folks’ lives). When the latter element is removed, or fails to materialise, or turns out to be an empty promise, then the implicit contract degenerates into a simpler time-for-money equation, which may negate the fairness from the perspective on one – or even, both – parties. Put another way, when do the noble aims and aspirations of things Agile cross some invisible line and degenerate into “base and unworthy use”? My contention is that this happens all too often.

Pimps

Whether or not we each choose to regard Agile Coaching, Scrum Mastering, Consulting and Development as prostitution, or as something else, a special place in Hell is reserved for the pimps. You know who I mean. The unsavoury, coercive, sociopathic types that find the clients for their (own – and owned) workers, and take their – generally, considerable – cut. As long as the money’s coming in, as long as the clients are not complaining to the police, as long as the workers keep grinding away, and as long as society continues to look the other way, they’re in clover.

Further Reading

The Ethics of Prostitution

– Bob