Archive

Monthly Archives: March 2012

Kinky Agile Sex

March 31, 2012
Agile, Coaching, Ethics
10 Comments

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

How to Spot a Lemon Consultant

March 31, 2012
Agile, Lemons, Organisational effectiveness
10 Comments

How to Spot a Lemon Consultant

A Lorra, Lorra Lemons

In my time I have seen a lot of lemons. And I have seen a lot of companies hire or engage with lemons – almost always unwittingly. Actually, I can’t believe how ineffective some of these folks and suppliers have been. And let’s face it, there’s a lorra, lorra lemons out there.

Following on from my recent “Better Customers” post, I thought it might offer some value to share some tips on how to spot these lemons.

The Lemon Consultant

Description

The Lemon Consultant is most often a pinstripe- or blue-suited individual – through its colouration and demeanour attempting to appear native amongst the local dominant fauna.

The Lemon Consultant strides purposefully from place to place, exuding faux-charm and confidence in an effort to attract its prey. Juveniles are similar to adults except the suits are cheaper and the veneer of confidence thinner, with a tinge of bluster.

Lemon Consultants prefer to congregate in flocks, for security and mutual support, although solitary individuals are also sometimes seen in the wild.

Range and Habitat

Lemon Consultants prefer surrounding of glass, steel and laminate, and favour smaller, private spaces over the open savannah. They are common in urban and suburban areas especially where large budgets are predominant.

Throughout the summer Lemon Consultants can be found in most of the major conurbations across the Northern Hemisphere. In North America: from southern Canada, down through the United States to the Mexican border. There are small pockets of Lemon Consultants as far west as Washington State. In Europe: preferring temperate climes, they are fewer in Scandinavia and Mediterranean  countries, with a significant population in the British Isles.

They are partially migratory with some migrating and others not. Some Lemon Consultants migrate quarterly, but always preferring to stay in one place for as long as their food source remains plentiful.

Nesting Habits

Like Mourning Doves, Lemon Consultants often take over other’s nests, at least temporarily. Failing that, and like the Black-headed Grosbeak, Lemon Consultants are known to steal parts and pieces of others’ nests to construct their own. In settled (non-migratory) situations, Lemon Consultant prefer a burrow or other cosy corner where they can keep out of sight whilst preening.

Feeding and Watering

Whilst Lemon Consultants are omnivorous, they prefer hard cash up front. When such pickings are scarce, they often settle for an hourly rate. They have been known to travel incredible distances from their breeding grounds to their preferred feeding sites. Avaricious and self-serving, the Lemon Consultant concerns itself predominantly with feeding.

Lemon Consultants do a wonderful job of regurgitating ideas from other sources, although generally poisoning the seeds and causing the resulting crop of ideas to be stunted and malodorous.

Song

The Lemon Consultant is a very vocal bird. It often has a strident, even whining note, although some few have a lilting, musical overtone. They make a number of different calls including its distinctive “deliver-cost-urgency”. It growls when it’s irritated, and chatters when it’s not. The Lemon Consultants has whistles and gurgling sounds in its repertoire as well.

Behaviour

The Lemon Consultant is often both aggressive and territorial. Group of Lemon Consultants will attack intruders and other Consultants that move into their territory, although they take great pains to avoid overt conflicts, preferring stealth and subversion to direct assaults.

If the weather is mild and the food plentiful, Lemon Consultants may winter over in their breeding grounds. But when they do migrate, they form loose flocks of around 3 to 12 traveling only during hours of darkness.

Sub-species

The lesser-known Lemon Agile Consultant can be distinguished from its more common brethren by its naivety, good-naturedness, and a fondness for making grandiose claims about the benefits of Agile software development whilst making no mention of the risks, costs, or the scale of changes required throughout adopting organisations.

The Lemon Agile Consultant is also very fond of Powerpoint presentations featuring cutesy child-like artwork and banal, empty platitudes; specious and tiresome “games”; often carries copious amounts of Lego; and repeats words like “fun”, “fairies” and “the power of stories” ad-nauseam.

Their song varies subtly from their common cousins, their most distinctive calls including “fun-clap-fun”, “more-value-less-waste” and “time-to-market”. Listen to the song of the Lemon Agile Consultant: Sound Bites: Lemon Agile Consultant, National Twat Service

Lemon Agile Consultants frequently borrow ideas from primary sources, but often out of context, and having grasped the wrong end of the stick. Their attribution of sources is rare to non-existant.

The Lemon Agile Consultant enjoys playing, and wants to play in your sandpit, with your money and your resources. Their gregarious nature means they love to rope-in as many of your people as possible, regardless of the distraction and disruption this causes. Outcomes rarely hold their interest for long, if at all.

Recognition

Recognising Lemon Agile Consultants amongst the general fauna is relatively simple. Ask direct questions like:

  • What’s most likely to happen when we roll agile out across the whole development group?
  • How will adopting Agile impact on other groups within the organisation?
  • What will we have to do to realise the promised benefits of Agile over the longer term (i.e. beyond 9-15 months)?
  • What are the key elements for ensuring our investment in Agile is sustainable and does not dissipate when e.g. early sponsors and champions leave the organisation?
  • How have Agile adoptions turned-out in other organisations? Well? Badly? What’s the typical success rate, longer-term? What are the likely pitfalls?
  • Is Agile suited here? Are there approaches other than Agile that can meet our needs as well or better?
Note: The nature of the answers are less important than having answers. The typical Lemon Agile Consultant will struggle, both with understanding the very questions, and in finding convincing answers.

Further Resources

Summary

Avoiding Lemon Consultants may seem like a difficult challenge, and for the uninitiated it can be. But with just a little awareness, a little patience to pass them by, and a few simple rules of thumb, it gets much easier.  And if life throws you one or more of these Lemon Consultants? Don’t bother even trying to made lemonade. Lemon squash, maybe.

– Bob

Better Customers

March 30, 2012
Organisational effectiveness
4 Comments

Better Customers

To do better, we need better customers, better clients. More demanding discerning. Less gullible.

Customers that demand value for money, not billable hours.

Customers that see the value in meeting the needs of all the Folks That Matter.

Customers that refuse to pay for crap.

Customers that reject specious claims and vacuous promises.

Customers that disrupt the cosy hegemony of the technical experts.

Customers that push back against complex and expensive non-solutions.

Customers that push through the embarrassment of failure to call suppliers to account.

Customers that understand THEIR customers, and look for partners that want to help them in that.

Customers who see the value in both trust and evidence, whilst rejecting faith-based arguments.

Customers that buy on criteria other than lowest (ticket) price.

Customers that embrace the human element in the world of business.

Customers that understand their own strengths – and their weaknesses, and act accordingly.

Customers that share the laurels of success, and share responsibility for failure too.

There are so many folks that WANT to do better, but desperately need the support of their customers to do so. Without better customers, the reforms and improvements we long for will indeed take a long time in coming.

– Bob

P.S. What are you doing each day to be a better customer – both as part of your organisation, and as an individual – to your suppliers?

Agile Blogging

March 29, 2012
Agile, Dialogue
6 Comments

Agile Blogging

This’ll be a short but sweet post to explain my current approach to blogging.

Subscribers and other regular readers will have noticed that, for some blog posts, I have taken to publishing early drafts well before the post is in any kind of “finished” state.

I’m trialling this approach with the following hopes:

  • I hope this will encourage me to get started on topics which I feel will take some extended writing effort (this in itself a limbering-up for even more extended writing effort in the form of a book). In the past I have parked such posts and rarely got round to completing and publishing them.
  • I hope that early publication will encourage readers to comment and feel they can influence the direction of the “finished” post – so far this has been a mixed bag.
  • I hope it exemplifies the Agile ethos of “deliver early, deliver often”, “provide early value for customers” and “get a Minimum Viable Product” out into the market, and garnering feedback on e.g. demand, as soon as possible.
  • It reflects my need for meaningful connection with people, in that maybe readers will be more likely to engage with the topic whilst the post remains incomplete and open for mutual learning and evolution of its content.
I’l be delighted to hear if you think this approach has merits (or not).
– Bob

Better Business

March 27, 2012
Agile, Organisational effectiveness, Rightshifting, Software development
3 Comments

Better Business

I have for many years held the view (as formalised in my Rightshifting work)  that most businesses operate at a small fraction of their potential. Or put another way, they are wasting a great deal (on average circa 80%) of their time, effort, ingenuity, etc., on doing the “wrong things”. By which I mean things that add no value from the customer’s point of view.

This is particularly the case for knowledge-work businesses, a relatively new class of business and one in which common management assumptions, practices and principles – what Ackoff calls “the Analytic mindset” – actively encourage and perpetuate significant dysfunctions. There is much evidence, both anecdotal and formal, to validate this view.

Rather than rant about the present sorry state of affairs, I thought I’d make a constructive suggestion about a different perspective on business – one more congruent with effective, high-performing knowledge-work organisations, and a perspective – what Buckminster-Fuller calls “the Synergistic mindset” – with which I myself have had some experience.

Business

What is a business? Wikipedia has a fairly prosaic definition, and not one which I have much time for. Art Kleiner in his book “Who Really Matters – The Core Group Theory of Power, Privilege and Success” has a definition much closer to my own view:

According to Art Kleiner, “The customer comes first” is one of the three great lies of the modern corporation. The other two being: “We make our decisions on behalf of the shareholders” and “Employees are our most important asset”.

“What comes first in every organization is keeping the Core Group (normally, most of the top executives) satisfied. Note, Core Groups are not inherently bad or dysfunctional, but rather, necessary – and even the best hope we have for ennobling humanity, since organisations are natural amplifiers of human capability.”

Even more broadly than this, I believe businesses serve a social need, and are an essential part of the fabric of our societies, influencing and influenced by society in equal measure, and serving folks’ need for safety, love/belonging, esteem, and other aspects that Maslow refers to in his “Hierarchy of Needs” (plus the need for social connections, which some folks pedantically argue that Maslow missed out on):

Aside: This is also very congruent with Deming’s First Theorem:

“Nobody gives a hoot about profit.”

 

The Problem

The Analytic Mindset is very poorly suited to knowledge-work and the knowledge-work business. Why is this so?

In knowledge-work, by definition, people work with their brains, learning, exploring and converting knowledge – often new knowledge – into things of value (i.e. goods, services and the experiences implicit in these things).

Given we are talking about groups of people, and learning, then collaboration and state-of-mind (e.g. engagement, enthusiasm, passion, etc.) count for much more than in other, more traditional kinds of business. (I could make  a case for these things mattering much more than generally appreciated in these other kinds of business too, but I’ll stick with knowledge-work businesses for the purposes of this post).

The Analytic mindset, with its tendency to break things down into parts, and the concomitant creation of functional silos within organisations, has a naturally deleterious effect on collaboration. And the traditional Analytic Management scenario, with managers directing the work and workers actually doing it, has a naturally deleterious effect on folks’ morale, engagement and enthusiasm in their work.

Knowledge-work thrives in the presence of intrinsic motivation. The Analytic perspective, however, prefers the extrinsic motivation best suited to task of manual labour and physical toil. Many studies have shown that attempting to encourage innovation, learning, and creative thinking through extrinsic motivation is not only unproductive, but actually anti-productive, demotivating and misdirected.

As Dan Pink points out in his book “Drive”, effective knowledge-work rests on three principles; Autonomy, Mastery and Purpose – three principles largely discounted, suppressed or entirely eliminated by the Analytic world-view.

Aside: Some folks have pointed out that Dan Pink’s work best relates to individuals and individual motivation, and that some different dynamics come to play in team-work and collaboration environments. There’s an interesting discussion on this in this blog post.

So, to sum up, most knowledge-work businesses are (unwittingly) using a default, inherited model of organisation and direction ill-suited to the kind of work they find themselves doing today – and, incidentally, ill-suited to getting the best out of the kinds of people best-equipped for knowledge-work (i.e. creatives, innovators, and the like).

A Solution

The obvious solution is to find a new model of organisation and direction better suited to the dynamics of knowledge-work and the knowledge-workers. In other word, a new mindset, replacing the ill-fitting Analytic mindset. Various businesses have reported their experiences in this journey of exploration and transition, including:

Aside: If you have any examples you have come across yourself, preferably documented as e.g. case studies or some such, please share.
 

What Might Such a “New Model” Look Like?

I call this model the “Synergistic mindset”, inspired by the term “Synergy” meaning “two or more things functioning together to produce a result not independently obtainable”, and by R Buckminster Fuller and his popularisation of the term. Specifically in the case of an organisation, Synergism suggests that two or more people, groups, or teams, working together cans produce results not obtainable by them working independently, and not predictable by the behaviour of them taken separately:

The term synergy was refined by R. Buckminster Fuller, who analyzed some of its implications more fully and coined the term Synergetics.

  • A dynamic state in which combined action is favored over the difference of individual component actions.
  • Behaviour of whole systems unpredicted by the behavior of their parts taken separately, known as emergent behaviour.
  • The cooperative action of two or more stimuli (or drugs), resulting in a different or greater response than that of the individual stimuli.
 

[Remainder of this section is work in progress]

Fundamental characteristics of this new model include:

  • Customer-orientation
    • Looking outward rather than inwards
    • Understanding demand and the value propositions that attract customers
    • Including stakeholders other than just customers (covalence)
  • Early and repeated releases of working products and services
  • Short feedback cycles / cycle times
  • Use of human-friendly “systems” to reinforce these characteristics…
  • Slack is good
    • cf Reinertsen, Queueing theory 101, Little’s Law, etc.
    • Contributes to sustainable pace
  • Deming’s 95%
  • Pull not push (in all things)
  • Self-organisation and self management (against demand)
    • Not coercive, imposed management aka the Management Factory
  • Evolution and emergence
    • Both in the design of products and service, andI in the way those products get designed and built
    • The way the work works is in a continual state of evolution, emerging through the interaction of the folks doing the work and the demands from customers and other stakeholders.
    • Simple rules / attractors can lead to (desirable) complex emergent behaviours
  • Ownership
    • The folks doing the work own how their work works, as contrasted with e.g.
  • Absence of “managers”
    • The traditional manager role give way to something more like servant leadership or better yet host leadership.
  • Intrinsic motivation
  • Shared Purpose
  • Multi-disciplinary teams, and generalising specialists (a.k.a. “cthulhu-shaped people”)
  • Collaboration, rooted in face-to-face conversations and purposeful dialogue
  • YAGNI
  • Continuous and mutual (joint) learning (self-managed, pull-based, facilitated)
  • Self-discipline (per-individual and per-group)
    • Initiative over permission-seeking
  • Evidence-based
    • Preference for decisions taken on the basis of data, research and practical evidence
  • Collegialism (shared decision-making, mutual support,
    • Harvey (1995a) terms the radical collegialist perspective ‘new collegialism’ and characterises it as involving networking, teamwork, responsiveness, innovation, empowerment, readiness to change, the facilitation of active learning by students and explicit quality criteria. Harvey, 1995a, ‘The new collegialism’, Tertiary Education and Management, 1, pp. 153-60.
  • Ba
  • End-to-end perspective e.g. “concept to cash”, value streams, flow (of value), etc.
  • Systems thinking cf Ackoff
  • Continuous (in-band) improvement
  • Engineering ethos:
    • Love of (appropriate) quality
    • Its implication for both economics and morale
    • How to systematise it

The Agile Connection

Many folks in the Agile community argue that if we apply Agile principles to business as a whole, things would get better. Given that Agile principles, as appear under the Agile Manifesto, are a subset of the above-listed characteristics:

  • How many folks think that the twelve Agile principles are sufficient?
  • What characteristics appear in the above list that are missing from the twelve Agile principles?
  • How critical are these missing characteristics to making better businesses?

Challenges

The key challenge to better knowledge-work business is the current collective mindset that prevails in the majority of organisations in the world, compounded by the same mindset as manifest in society globally. Given its ubiquity and longevity both, swapping it out for something more relevant and useful will likely take much time, and require progress on a broad front.

However, progressive organisations that can insulate themselves from the deleterious influences of wider society, and build and cultivate a view of the world of work more suited to knowledge-work can get to it right now. Some indeed are already some way down the road in this “journey to Radicalsville“.

Of course, the more folks that make the journey, the less radical Radicalsville will look.

What do you think?

– Bob

Further Reading

Reinventing Organizations ~ Frederic Laloux

Better Conferences

March 26, 2012
Coaching, Dialogue, Rightshifting
12 Comments

Better Conferences

I’m becoming increasingly dissatisfied with conferences, both as a speaker and as an attendee. Rather than rant about their present format (be that speaker-led, open-space, or what-have-you), I thought I’d make a constructive suggestion about a different format for conferences, a format that I myself would prefer.

Conferral

Seems to me that the very idea of “Conference” has become detached from its roots:

con·fer

[kuhn-fur]  verb, -ferred, -fer·ring.

verb (used without object)

  1. to consult together; compare opinions; carry on a discussion or deliberation.

[C16: from Latin conferre  to gather together, compare; from com- together + ferre to bring]

The Problem

Let me start out by describing the problems I have with existing conference formats.

  • Push – Most often, know-how is “pushed” at the participants by people with that know-how, albeit with the best of intentions. Many times these good intentions go awry and create waste:
    • Wasted time for speakers sharing know-how that few if any folks find valuable
    • Wasted time for participants hearing about stuff that lacks relevance for them personally
    • Presentations / lectures being the classic form of “push”
    • This all seems contrary to what we in the Agile and Lean communities have learned about the benefits of “pull”.
  • Not purposeful – Folks generally drift in and out of sessions with little purpose and little idea in advance as to whether a particular session is going to serve their needs  (“fit”). Further, few folks I have met at conferences come with any kind of specific “learning agenda”.
  • Unconscious incompetence – how do folks get to find out what they don’t know, that might be valuable to them in their current situation, or their future? [My thanks to @papachrismatts for this suggestion.]
  • Structure set at the outset – Particularly an issue with open space, where, even though the agenda is co-created at the outset, there is little  or no flexibility in time slots, nor much evolution of the agenda or timing structure after the start.
  • No adjustment to the process/structure during the event. Even within a one-day conference, participants are learning about the format and how it suits them. I would favour a means to encourage and incorporate that learning through ongoing evolution “in flight”.

Purpose

As I see it, folks participate in conferences to the following ends:

  • To learn (from acquiring a basic awareness of things unknown, through to detailed and specific know-how)
  • To socialise
  • To share (e.g. mutual learning)
  • To proselytise (e.g. to promote ideas)
  • To promote (the profile of oneself or one’s organisation for e.g.commercial purposes)
(And let’s not overlook the organisers’ purpose: whether it’s about community, or more commercial ends).

A Solution

My solution to the above collection of problems and requirements would be to have conferences where:

  • Attendees each have their own “ignorance backlog“, drawn-up in advance, and evolving throughout the conference. For those for whom this might prove a challenge, the conference could and should provide some guidance, in the form of e.g. coaching, in the construction and evolution of this backlog. I for one would be delighted to volunteer for this duty.
  • Knowledge is pulled, on demand, by the attendees, from the pool of available “subject-matter experts”, and in accordance with their “ignorance backlogs”. Given the likely ratio of learners to subject-matter experts, this pulling may necessarily happen in groups, rather than on a one-to-one basis. Although, this format does afford the delicious possibility of allowing anyone (attendees included) to play the part of subject-matter expert in at least some subjects. As Ackoff and others have said, “in the classroom, the teachers is always the one that learns most”. So I posit it would be for the best to encourage non-subject-matter-experts to do as much of the “teaching” as possible.
  • Sessions are organised on-the-fly, with duration, location and participants “pulled” according to availability and priority.
  • The core of the conference organisation task would involve:
    1. Delineating the topic landscape (scope).
    2. Finding the venue, sponsors, etc
    3. Encouraging folks to participate
    4. Cataloguing the expertise present on the day,
    5. Providing the “ba” (spaces where mutual meaning can emerge)
    6. Facilitating the scheduling (times, durations, locations) of the “ba”.
    7. Consolidating the experience via follow-up activities (photos, slides, videos, blogs, etc).

Risks

Risks I can envisage include:

  • Folks with knowledge may be reluctant to spend their own coin to particiapte, given that “speakers” often get their expenses reimbursed (and sometimes fees, as well) as part of the “deal” (i.e. in token exchange for sharing their know-how and experiences). I do have some tentative – i.e. not yet well-formed – ideas on how to address this.
  • Folks looking to proselytise or promote their ideas, company or personal brand/celebrity may be unwilling to participate fearing a dilution of their profile. I am less concerned by this, as personally I  dislike being sold to, favouring rather co-learning with like-minded others.
  • Organisations sponsoring their employees to attend conferences in this kind of format may wonder if they’re getting value for money, and may baulk at the unconventional nature of the format. Given the likely much improved outcomes (in terms of participants’ learning, experiences) I suggest this might be an initial hurdle but less of a longer-term issue.
  • Participants coming unprepared/unbriefed for such a format may not get as much out of the conference as they would if skilled in this particular approach.

Sponsors

Let’s not overlook the key role of sponsors and sponsorship in reducing the financial risks inherent in organising conferences, and in making conferences financially viable. I for one understand less than I’d like to about the motivations of sponsors and how – or even if –  their needs can be met by this format.

Names

I’m not going to name this new format. As Ohno said: “Don’t codify method”. Maybe you might consider the advantages of so refraining, also?

Given my proposal of this kind of format as a means for mutual learning (or co-exploration of a topic/topic-set) it might be more suitable to refer to everyone as “participants”, “co-learners” or even “conferrers”, rather than split people up to different categories such as attendees, speakers, etc.

Early Trials

We have trialled some aspects of the proposed format at the various Rightshifting conferences of the past two years. I’d love for folks who attended those events to share their experiences of the format, here.

– Bob

This Shitty Agile Compremise

March 22, 2012
Agile, Organisational effectiveness, Rightshifting, Software development
1 Comment

This Shitty Agile Compremise

I think we all feel uneasy about compromise. And yet, so many folks make compromises so often, it also feels like it’s inevitable. Shakespeare noted how distressed folks can become when forced to consider compromise:

Bastard:
O inglorious league!
Shall we, upon the footing of our land,
Send fair-play orders and make compremise,
Insinuation, parley, and base truce
To arms invasive?

~ Will Shakespeare, King John Act 5, scene 1, 65–69

Goldratt, father of Theory of Constraints, is uncompromising in his excoriation of compromise:

The common way to manage conflicts is to struggle with compromise. Yet all contradictions can be resolved without compromise – it’s our level of understanding and our assumptions that hold the contradiction in place. A compromise is not usually a win-win solution.”

~ Eliyahu M Goldratt

Goldratt goes on to describe “Evaporating Clouds” – his method for obviating compromise:

“The Evaporating Clouds method does not strive to reach a compromise solution, rather it concentrates on invalidating the problem itself. The method involves verbalizing the assumptions underlying the problem, and challenging them to find the invalid assumptions.”

Agile Compromise

The Agile Compremise (compromise) of which I write, here, are in fact several:

  1. There’s the  tacit compromise made by business folks who don’t want to understand Agile,  but neither want to demotivate their software folks so much that those folks stop making an effort, or quit entirely.
  2. Then there’s the compromise that developers make in adopting Agile within their own teams, without dealing with the conflicts and dysfunctions arising from their upstream and downstream partners not also adopting agile.
  3. And thirdly, there’s the compromise that whole organisations make in “adopting Agile” but not consequently changing their mindset regarding the world of work – a change that is essential if adopting organisations are to actually reap – sustainably – the promised benefits (e.g. x2, x4, x8 productivity uplift) of the Agile development approach.
I have drawn the Evaporating Clouds for the above three situations, showing the underlying (conflicting) assumptions and some challenges to those assumptions:

Compromise #1: Management Allows But Does Not Embrace

Arrow 1a: In order to have A, we must have B.
Assumption 1a1: People are (more) productive when they have a say in the way the work works.
Challenge: Will our developer productivity decline or fail to improve if we (they, the developers) don’t have a say in the way the work works?
Assumption 1a2: The existence and increasing adoption of Agile across many organisations means our developers have changed their expectations re: the “working contract”.
Challenge: Will our developer productivity decline – or fail to improve – if we (the organisation) fail to accommodate our developers’ changed expectations?
Arrow 1b: In order to have A, we must have C.
Assumption 1b1: Management oversight and control contributes positively to developer productivity.
Challenge: Does management control over the way the work works really contribute positively to developers being productive?
Arrow 1c: In order to fulfil B, we must accept D.
Assumption 1c1: Adopting Agile is the only way to give developers a say in how the work works.
Challenge: Is Agile the only way to provide our developers with a say in the way the work works?
Arrow 1d: In order to fulfil C, we must accept D’.
Assumption 1d1: Management control over the way the work works is fundamentally incompatible with Agile software development.
Challenge: Is this really true? Could we adopt Agile and yet retain management control?

Compromise #2: Agile Remains a Ghetto

I leave this diagram and its assumptions as an exercise for the reader.

Compromise #3: Failure to Realise Any Significant Benefits

I leave this diagram and its assumptions as an exercise for the reader.

Lose-Lose

Like so many scenarios for compromise, the Agile world is compromising on its goals, ideals and principles, and in doing so is complicit in a lose-lose situation – for itself and for the thousands of organisations it is ostensibly committed to helping.

I posit that we in the Agile community have the responsibility to recognise our complicity in this lose-lose situation. And, given we have more awareness about the situation and its issues than the business folks, it behoves us to reach out and involve them in evaporating the clouds of invalid assumptions that underly these ugly compromises.

– Bob

Why Directors Should Give a Damn About Culture

March 21, 2012
Leadership, Organisational effectiveness, Rightshifting, Snippet
2 Comments

Why Directors Should Give a Damn About Culture

In this short opinion piece, John Bell, ex-CEO of Jacobs Suchard, echoes my own opinion on the role of culture in business performance:

“Culture is one of the most important determinants of business performance.”

~ John Bell

In my own vernacular, and as a (much humbler) ex-CEO myself, this translates one-for-one to:

“Organisational mindset is one of [if not the] most important determinants of organisational effectiveness.”

~ Bob Marshall

– Bob

Society and the Analytic Mindset

March 19, 2012
Leadership, Organisational effectiveness, Rightshifting, Software development
13 Comments

Society and the Analytic Mindset

As you may know by now, I assert that effectiveness of knowledge-work organisations is a function of their several “collective organisational mindsets”. In other words:

Effectiveness = f(mindset)

The collective mindset of any organisation is profoundly yet imperceptibly influenced by the collective mindset of the wider society within which it operates.

All Things are Connected

In “Wholeness and the Implicate Order”, David Bohm talks about cosmology and the nature of reality. I’m not going into that today, but I mention it just to illustrate that the idea that all things are connected is a recurring theme across many disciplines. It is a common idea in Eastern philosophies, such as Zen, with the Buddhist concept of “dependent origination” (Pratītyasamutpāda). That all things are connected is an idea profoundly at odds with the reductionism inherent in the Analytic Mindset.

The Analytic Mindset does not exist in isolation, in the minds of individuals or even groups. Rather, the Analytic mindset exists as part of the fabric of all our lives, and of organisations and society both.

Let’s take a look at how that came about.

Roots

Ackoff defines the Analytic Mindset as:

“Breaking things down into parts, on the assumption that understanding the parts individually allows understanding of the whole.”

~ Russell L. Ackoff

For centuries, indeed millennia, this point of view has been at the heart of the Scientific Method.

“In the analytic tradition of Aristotle there are all the logicians and a large part of the physicists of today. Galilei, Copernicus, Newton and Einstein are thinkers of the analytic tradition. A large part of Western culture and technology is founded in this [way of thinking].

~ Carlos Cirne-Lima

Ever since Sir Isaac Newton (some may say, ever since Aristotle), society has come to believe that the Analytic way of thinking is the best way, indeed many might say the only way, of looking at our problems.

“Regrettably, most of us still cling to the truths of 17th century science, fostered primarily by the teachings of Sir Isaac Newton. Although very helpful in catalysing industrial and technological advances, this worldview has severely constrained many aspects of our humanity and impoverished our life experiences.”

 ~ Mel Schwartz

Yet modern science – and traditions other than Western reductionism – offer us alternative ways of thinking and seeing the world and its challenges.

The Three Steps of Analytical Thinking:

  1. Take “it” apart
  2. Understand what the parts do
  3. Assemble the understanding of the parts into an understanding of the whole
Relying on these three steps (as much of the whole world has learned, explicitly or implicitly, to do) will not help us answer many of the important questions about systems. It’s time to learn to see things differently.

Science Has Moved On

In her excellent book “Leadership and the New Science” Margaret Wheatley writes:

“In science, the beginning of the twentieth century heralded the end of the hegemony of Newtonian [analytic] thinking.”

~ Margaret Wheatley

She then goes on to talk about what she calls “Newtonian despair” – the feelings of fatigue and impatience brought about by trying to tackle interrelated, inter-twined (“wicked”) problems as though they were separate, and amenable to independent resolution.

I see this “Newtonian despair” everywhere I look, from the issues facing individual software developers and teams, all the way to the wicked problems facing governments and societies, globally.

Education

Much of society’s collective mindset is shaped by folks’ formative experiences within the education system.

“The current system of education was designed and conceived for a different age.”

~ Sir Ken Robinson

Education, since the inception of compulsory public education for all some one hundred and forty years ago (UK), has prepared pupils as either smart, intellectual “executive” scholars and academics,  or for a productive (and compliant) role as cogs in the machines of the industrial revolution. (See e.g. Sir Ken Robinson’s animated RSA presentation).

Into the Workforce

“The system of education is modelled on the interests of industrialism and in the image of it.”

~ Sir Ken Robinson

By the time folks finish education, they have learned through experience – and osmosis – many of the fundamental assumptions integral to the Analytic mindset. They then join the workforce, where these same assumptions have “flourished” and compounded since the very dawn of the industrial age.

The Analytic mindset has a near monopoly in the corporations and government bureaucracies of our “modern” world. And like the monkeys with the banana, folks working in these organisation have little or no knowledge of the original conditions that led to the rules and procedures to which, and by which, they find themselves bound.

Some psychotherapists attribute “the epidemic of anxiety, depression and general disconnectedness that engulfs us [society]” to the “analytic, reductive and mechanistic” worldview.

Organisations

“There is no objective “organisation”. The “reality” we experience does not exist “out there”… it is co-created through our acts of observation, what we choose to notice and worry about.”

~ Karl Weick

The Analytic mindset is so ubiquitous, pervasive and common-place in society, and thus in our organisations, that folks rarely if ever even notice it, let alone question it.

Organisations do not operate in a vacuum. They recruit people from society at large, thus importing a bias towards the Analytic mindset with every new hire. Some organisations, like Zappos, recognise this explicitly and take great pains to try to offset this bias. These new hires may have been in the workforce for some time – having absorbed the Analytic view of work from their previous work experiences (most organisations see the world of work through an Analytic lens). Or they may be new to the world of work, yet still steeped in the Analytic mindset via their experiences at school, and through popular culture (films, TV, books, newspapers, conversations, etc.). In any case, with each new hire into a Synergistic-minded organisation, the synergistic view can be diluted, eventually reaching a tipping point where the organisation reverts to an Analytic perspective. I’m sure you can think of high-profile examples where this has happened.

Rarely do the folks caught in these regressions (a.k.a. reverse transitions) recognise what is happening to them and their organisation. In most cases, the progressive, effective folks bemoan the loss of the “soul” of their organisation, and sooner or later quit for pastures new. (Before quitting, these folks’ engagement and commitment generally tail off precipitously).

And every day, popular culture and the pontifications of vested interests and self-promoting analytic thinkers, executives, consultants, authors, etc. serve to reinforce the Analytic world view, and confound other mindsets, in thousands of organisations across all domains of business. charity, the military, the Church, etc..

Swimming Against the Tide

For organisations making serious efforts to better themselves and improve their effectiveness, the Analytic mindset is like a continuous ebb tide, slowing down their progress towards a different, more conducive view of the world of work, and continuously dragging them back towards the mean (sic) Analytic mindset.

Summary

In all fields of organised endeavour, the subtle, imperceptible bias of the Analytic mindset, simply by virtue of its near-ubiquity, causes a continual “reversion to mediocrity“. Without recognising this phenomenon, organisations of every stripe risk erosion or collapse of their hard-won right-shifts of effectiveness and mindset.

– Bob

Resources

The Analytic-synthetic Distinction (Philosophy)
The Tragedy of the Social Epistemology Commons (Blog post on LessWrong)
The Analytic-Synergistic Transition (Earlier Think Different blog post)

On the Morality of Dissent

March 17, 2012
Dialogue, Organisational effectiveness, Rightshifting
12 Comments

On the Morality of Dissent

 “I want you to get MAD. You’ve got to say ‘I’m a human being goddamit! My life has meaning!’

…I’m as mad as hell, and I’m not going to take this anymore!”

~ Howard Beale

[See the video clip]

Conflicted

A long, long time ago, Shakespeare wrote:

“Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?”

A question with which I struggle on an almost daily basis.

As I have mentioned before, I am driven by the inordinate waste of human potential in typical “knowledge-work” businesses – waste, in large part, due to what Rightshifting calls the “Analytic Mindset“.

“I don’t know who discovered water,
but I’m pretty sure it wasn’t a fish.”

~ Marshall McLuhan (1911-1980),
media critic & writer

The Analytic mindset is so ubiquitous, pervasive and common-place that, to paraphrase Marshall McLuhan, I don’t know who discovered the Analytic Mindset, but I’m pretty sure it wasn’t an Analytic thinker (which is most of the planet’s population).

Planting Trees

“The true meaning of life is to plant trees, under whose shade you do not expect to sit.” ~ Nelson Henderson

I wish to see things change, and I do what I can to plant seedlings under which, in time, folks may take some shade. In working towards common goals alongside other folks, conflict is inevitable, particularly when world-views collide. And like Patrick Lencioni I believe that positive conflict is essential in making progress.

I do not enjoy conflict, hence I am conflicted. One might fairly call that cognitive dissonance. :}

The truth is never pure and rarely simple – Oscar Wilde

Nevertheless, I take heart from the story of Martin Luther King, Jr., and in particular:

The ultimate measure of a person is not where they stand in moments of comfort and convenience, but where they stand in times of challenge and controversy. ~ Martin Luther King, Jr.

I also try to keep in mind the principles of tolerance, equanimity and mutual learning implicit in Norm Kerth’s Retrospective Prime Directive, which I have reinterpreted more generally as:
Regardless of what is said, I understand and truly believe that everyone is doing the best they can, given what they know, how they see the world, the handicaps of their experiences, and the situation at hand.

If You See Buddha On the Road, Kill Him

Given the oft-repeated suggestion that

“Folks should think for themselves, in context”

then dissent seems not only inevitable, but

’tis a consummation
Devoutly to be wished.

I for one applaud folks who stick their necks out and share the way they see the world, however differently that might be, just so long as it doesn’t get personal.

In summary, I believe we all have a duty to dissent. Compliance and conformation merely lends support to the status quo.

What do you think?

– Bob

See Also

Dare to Disagree (blog post)

Time For the Agile Old Guard to Retire

March 16, 2012
Agile, Leadership, Organisational effectiveness, Software development
4 Comments

Time For the Agile Old Guard to Retire

That was then, this is now.

I wrote in my recent post “Agile Coaching is Evil” that :

The issues noted and addressed by the [Agile] manifesto and its signatories have turned out not to be the core issues affecting software development.

Yet, the Agile Old Guard (with very few exceptions, like the lovely Kent Beck) have not moved with the times. They’re still thinking in terms of code quality, designs, testing, architectures, processes, and so on.

The young Turks meanwhile have uncovered deeper, more fundamental blockers to effective software (and product) development. And they continue to push the envelope with fresh insights and novel combinations of knowledge from other fields. And thus, new solutions, too.

It’s come to the point where the Old Guard are now a serious brake on progress.

Let’s salute them for what they achieved, and then move on.

– Bob

The Agile Train is Heading for Radicalsville

March 15, 2012
Agile, Leadership, Organisational effectiveness, Rightshifting, Software development
2 Comments

An Open Letter to the Management Suite

Hi there,

So you’ve heard about this Agile thing, and want some of it?

Quicker delivery, better quality software, more engaged developers, lower costs, increased flexibility to respond to changes in e.g. customer demand or strategic company priorities. What’s not to like?

And  many organisations have already jumped on the Agile train. More get on board every day. But it’s not the smooth ride many expect. Nor is the train’s destination where you think – or where the headboards advertise.

The Agile Train is Heading for Radicalsville

Do you want to go there? If so, all well and good. Let me describe Radicalsville to you, just in case you’ve not been there before:

In Radicalsville, there’s no Sheriff. No Mayor. No Judge. No Parent Teacher Associations. No Police Department. People are mature enough to care about their town and look after it, together. Folks get together to talk about trade, quality of life, making the town a nicer, fairer, more humane place to live. Justice is restorative, not punitive. People make their own laws. Democracy is direct, not representative. Everyone has fun. Everyone plays a lot. Things get done. The sense of community is palpable. The relations between folks are as important, and receive at least as much attention, as the individuals themselves. Problems, accidents, etc. get picked up by anyone in the right place at the right time, assuming they’re capable of handling it. If not, there’s always other folks with time to pitch in (no one in Radicalsville is so busy as to not have spare time). The town shares a common purpose, and works as a whole to enact that purpose, every day.

Still want to get on that train? If so, no problems.

But not sure so much, now? Could you get the benefits by getting on a different train? Not really. You see, Radicalsville is where all this good stuff is happening. Other places may have their own attractions – some folks like the calm, sterile, well-policed streets and leafy gridded boulevards of CMMI City. And there’s always the wild frontier. Although you’d have to eschew the train and go buy some horses, instead.

Of course, you’re not going to listen to me. The attractions of Agile sound too fabulous, don’t they? And as humans we’re pre-wired to see the positives and discount the negatives.

Look out for the snakes!

– Bob

Agile Coaching is Evil

March 14, 2012
Agile, Coaching, Organisational effectiveness, Rightshifting
50 Comments

Agile Coaching is Evil

And Scrum Mastering is the work of the Devil.

[Update: 15 March 2012]

It’s nice to see this post has generated some discussion both on Twitter and in the comments below.

It seems clear that some folks object to the term “evil”, which surprised me a bit, as the dictionary entry says

e·vil [ee-vuhl]

adjective

  1. morally wrong or bad; immoral; wicked: evil deeds; an evil life.
  2. harmful; injurious: evil laws.
  3. characterized or accompanied by misfortune or suffering;unfortunate; disastrous: to be fallen on evil days.

So I’d like to explain why I (carefully) chose this particular word, despite the risk of being accused of click-baiting. Please note I am particularly focusing on definition 2), above, although I’ll touch on 1) and 3) a bit, too.

Why Agile Coaching is Evil

I have done much Agile Coaching myself over the years, and know a whole bunch of excellent, sincere, and lovely people who put their heart and soul into trying to help others through Agile Coaching.

But Agile Coaching make implicit promises. Promises about collaboration, treating people better, giving people more say in the way the work works, self-organisation, and a whole host of other ideas – which I’d collect together under the label “synergistic thinking”. The organisations who commission Agile Coaching rarely, if ever, appreciate that these promises are part of the package. And these organisations are rarely, if ever, prepared to deliver on the promises being made on their behalfs. In fact, it’s the raising of these hopes and expectations in the players, and the wider organisation’s ignorance, indifference or downright opposition, that contributes to much tension, stress and frustration (i.e. misfortune and suffering) all round, only a little while down the line.

Is wasting people’s time, good intentions, hopes and dreams evil?

I’d have to say “yes”.

And as a local optimisation, even if the Agile Coaching itself goes well, as Ackoff taught us:

“Optimising one part of a system ALWAYS leads to sub-optimisation of the system as a whole.”

Is burning through clients’ money whilst delivering little real value-for-money and few bottom line benefits (or even net dis-benefits) evil?

Again, I’d have to say “yes”.

Does this mean I think Agile Coaches are evil? Certainly not. As Gandhi said:

“Hate the sin, love the sinner”.

They Know Not the Evil that They Do

The saddest part in all this, for me, is that few Agile Coaches seem to be aware of these issues. Or, for those who are aware of them, they seem to regard them as inevitable, intractable, insoluble, or irrelevant. In their genuine keenness to help people, to spread the “Agile goodness”, they wrap themselves up in the minutiae of daily coaching practise, and sooner or later become inured to the dysfunctions imposed by the wider system – dysfunctions outside their remit or influence.

As William Kingdon Clifford (1845-1879) said:

“it is wrong always, everywhere, and for anyone, to believe anything upon insufficient evidence.”

I hold that is is wrong (unethical, immoral, and, yes, evil) for us all to continue believing (or is it pretending?) that:

  • Agile Coaching generally has much impact on the bottom line of business.
  • Agile Coaching, as a local optimisation, does not contribute to the sub-optimisation of the whole organisation.
  • Agile Coaching does not falsely raise players’ hopes, over the longer term.
  • Agile Coaching does not make implicit promises the organisation cannot or will not keep.
  • Agile Coaching does not make players less employable (see my Magralls11 video for more on that argument).

With the lights of Ohno, Deming, Ackoff, Senge, et al to guide us as to the crucial role of “the system”, we know better, now. Is ignoring that knowledge evil?

I’d have to say, “yes”.

So, It seems clear to me that Agile Coaching, in its common form is a largely irrelevant local optimisation that is, on balance, harmful or injurious to both the client and the individual players (team members being coached), and that ignoring this is morally wrong. That’s the evil.

[End of 15 March 2012 update]

The Agile Manifesto

That was then, this is now.

“No plan of operations extends with any certainty beyond the first contact with the enemy’s main body.” ~ Von Moltke

For its day, the Agile manifesto was a landmark in bringing some sanity to the world of software development. But things have not gone according to plan. The issues noted and addressed by the manifesto and its signatories have turned out not to be the core issues affecting software development. There is merit in the argument that we could only have discovered this by addressing what we imagined those issues to be – to learn whether our hypotheses were relevant.

Indeed, some of those hypotheses were, and remain, marginally relevant. But newer, much more relevant hypotheses have now come into sharp focus.

Unfortunately, we appear to have become rather too wedded to the “plan” (hypotheses) of 10+ years ago. We have discovered that the enemy’s main body was not where we thought, but we continue to conduct the battle as if it were. Are we just paying lip-service to the value of learning, and that it’s OK to fail, so long as we learn from our failures? Or can we truly embrace that idea, and learn from the failure of the Agile Manifesto and all its works?

Agile Coaching

Agile Coaching is a case in point. With the very best of intentions, Agile coaching has climbed into bed with the enemy, and is now comfortably(?) making it breakfast every morning. And just like any loveless marriage, no one is really happy, but having a roof over one’s head and a modicum of social standing, on the one hand, and daily breakfast in bed, on the other, often outweighs matters of principle. Agile coaching is thus now clearly evil.

Scrum Mastering

Similarly, Scrum Mastering is the work of the Devil, bending its considerable efforts to accommodating the status quo and deliver more-or-less irrelevant local optimisations (and that’s in those rare cases when it’s working “well”).

A New Plan

We need a new plan. One that recognises present intelligence (sic) on the disposition of the enemy. And to draw up a new plan, I suggest we might also do well to pay attention to Clausewitz and Von Moltke (among others) and:

  1. Very clearly articulate our “commander’s intent”.
  2. Listen intently to the junior officers and serve their need for information (and the necessary resources).
  3. Get the hell out of the way and let the folks on the front line make it happen.

– Bob

Further Reading

Product Aikido ~ FlowchainSensei

Agile! Huuuh. What is it Good For?

March 13, 2012
Agile, Organisational effectiveness, Rightshifting, Software development
Leave a comment

Agile! Huuuh. What is it Good For?

(Props to Frankie Goes to Hollywood’s War!)

Intro

The logic of Agile seems to be that if a team can code, they will code.
That managers will not surrender until surrender is academic.
How is a business leader to explain the sacrifice of so much for nothing?
Well, relax.
I can explain.
I don’t want to work pointlessly.

Song

Agile. What is it good for?
Absolutely Nothing, say it again.
Agile. What is it good for?
Absolutely Nothing.
Agile – I despise
‘Cos it means disillusion
For innocent lives
Agile means tears
To thousands of mothers how
When their sons go off to work
And lose their hopes
(Agile) I said, “Agile. Good God, y’all, what is it good for?”
Absolutely nothing, say it again.
Agile, Oh Lord, what is it good for?
Absolutely nothing, listen to me.
(Agile) It ain’t nothing but a heartbreaker
(Agile) Friend only to the tool vendor
(Agile) It’s an enemy to all Mankind
The point of Agile blows through a man
Agile has caused unrest
Among the younger generation
Induction then disillusion
Who wants to be unemployable?
Agile – huuuh
What is it good for?
Absolutely nothing
Say it again
Agile – huuuh
What is it good for?
Absolutely nothing
Say it, say it
No point to Agile.
Agile has shattered

Many young men’s dreams

We’ve got no place for it today
They say we must code to keep our freedom
But Lord knows there’s got to be a better way
Agile – Good God, now
Now
Give it to me one time now
Now now
What is it good for?
Say it again
Oh no – oh
There’s got to be a better way
Oh no
There’s got to be a better way. Yeah.
Agile – what is it good for?

What Makes a Mindset?

March 10, 2012
Organisational effectiveness, Perspectives, Psychology, Rightshifting
7 Comments

What Makes a Mindset?

[See also more recent posts: Perspectives on Rightshifting and What is a Mindset?

I was recently lecturing at Cass Business School, for City University’s Masters in Information Leadership course. I learned a great deal – and confirmed, in passing, Ackoff’s observations that the folks who learn most in a classroom are the teachers. :}

One of the things I learned was that it’s difficult for folks new to the Marshall Model to locate their own organisations on the “effectiveness” axis, or even to judge which mindset might be the prevailing one in their organisation.

So I’ll be writing some posts explaining the idea of Mindset, hopefully in a way that folks might find helpful in classifying their own organisations’ collective mindset.

What Do We Mean by “Mindset”?

For the purposes of the Marshall Model, at least, I define a Mindset to mean “a self-consistent set of assumptions concerning the way work should be organised, arranged, conducted and controlled”. And I should also mention the role of the collective organisational mindset – the assumption here being that everyone in a given organisation tends to act as if they share a common mindset (over the longer term). Generally, anyone (or any group) seen as a “deviant” with respect to this common mindset causes some degree of cognitive dissonance – both in the deviants and the rest of the organisation. This dissonance, over the longer term – typically nine to eighteen months – almost always resolves itself, one way or another. And often not in a good way.

Questionnaire

Drawing on this AuthorStream presentation, the following questionnaire offers a simple way of getting started with categorising you own organisation’s mindset, in terms of the Marshall Model. Simply identify which statement in each group sounds most like your organisation (as a whole), and keep a running total of the points associated with each selection. At the end, divide the total by <number_of_questions_answered * 10> to give you an approximate location on the RIghtshifting horizontal (effectiveness) axis, and thus identify the likely prevailing collective organisational mindset.

[Please note: this is the first draft of this post, and not all questions are complete as yet.]

1) Waste

How much of everyone’s working week, for folks across the organisation, is eaten up doing stuff that doesn’t add real value – i.e. anything that customers would never want to pay for – or make much difference to the value perceived by your customers (things like meetings, rework, finding defects, dealing with customer complaints, etc.)?

  • a)  Around 90%. (4 points)
  • b)  Something like two-thirds to three quarters of folk’s time seems wasted. (12 points)
  • c)  In the region of half the working week. (25 points)
  • d)  20% or less of the working week is eaten up by stuff that doesn’t make much difference. (42 points)

2) Product Development Life Cycle

How are new products (including services, and new products for internal use) developed?

  • a) Things are generally thrown together with a lot of design loopbacks (where problems in the design are found during e.g. implementation, and thus require the development folks to go back and change the design, invalidating some of their post-design work). (4 points)
  • b) Most new products, etc. are planned in some detail up front, and then built more or less according to that master plan, over a period of several months or years. (12 points)
  • c) Most new products evolve during their progress from concept to deployment, steered by a guiding vision, but with the design and implementation details emerging as the product progresses. (25 points)
  • d) New products are deployed very early, as very minimal versions, and those that find some traction in the marketplace get more funding to evolve into more sophisticated and fully-features versions, whereas those that fail to find a market are culled quickly and ruthlessly. (42 points)

3) Flow Mode

How do product ideas “flow” through the organisation and into the market? I.E. What is the “chunk” size of work in the organisation?

  • a) Mostly at random – there is no consistent way in which new products flow through the organisation. (4 points)
  • b) In large batches, with groups of related “product features”, often for a whole product, batched together and passed from queue to queue (for example, using a phase-gate approach). Such “feature-sets” get released (in the form of product iterations) with releases at least 3-4 months apart, or with the first or only release of the “product” months or years from its conception. (12 points)
  • c) In small batches, groups of related “product features” batched together and passed from queue to queue (for example, using a iterative, time-boxed approach). Such “mini-feature-sets” get released (in the form of product iterations) with releases as little as 2-4 weeks apart. (25 points)
  • d) In single features, with each individual new “product feature ” being released as soon as it is ready to deploy, often every 2-3 days , or maybe more frequently than that. (42 points)

4) Feedback Delays

How long is it, typically, before the market’s (or customers’) reaction to a new product feature can be incorporated into a subsequent product release?

  • a) We have no way of knowing – but I’d guess that any market feedback we do notice rarely affects subsequent releases at all, directly. (4 points)
  • b) Something in the order of 3-18 months. (12 points)
  • c) Something around two to six weeks. (25 points)
  • d) Less than a week. (42 points)

5) Administrative Project Management

How much emphasis does the organisation place on administering projects “properly”?

  • a) We don’t have projects as such. We just work each day on stuff that looks like it might be useful. (4 points)
  • b) Our organisation is very diligent about projects. Most if not all projects within the organisation have a dedicated project manager. The organisation also has a proper project management process (PRINCE2, CMMI, etc), Quality Manager or department, Programme Office, and so on. Most or all projects report their status via RAG reporting or some such on a regular basis. Much of what we need to do every day is diligently written in our process manuals and work standards documents. (12 points)
  • c) Work teams manage their own work, acquiring and managing team resources as necessary and themselves organising their interfaces with other parts of the organisation. (25 points)
  • d) The organisation used to have projects but has discovered the disadvantages outweigh the benefits so no longer uses the “project” as a means to organise work. (42 points)

6) Fun

How much fun and enjoyment do people have at work each day?

  • a) The organisation is a great place to work most days, apart from when things go wrong and people have to slip into ‘firefighting’ mode (which is rather too often). People (mostly) treat each like human beings. (4 points)
  • b) The organisation treats people like drones, and there is a pervading atmosphere of gloom. People are not meant to have fun at work, are they? Fun is not professional. (12 points)
  • c) The joy of working in the organisation comes from knowing what to do, having the resources and support to do it, and knowing that together the people across the organisation are making a sustained, positive difference to the world. Everyone feels well-respected, both as human beings and for the contributions they make. i(25 points)
  • d) Every day its different. People get a buzz from knowing what’s going on in the World (outside the business), especially in the world of customers and markets, and from coming up with new ways every day to meet emerging needs and trends. Everyone feels well-respected, both as human beings and for the contributions they make. (42 points)

7) Wasted Potential

People like it when they get to do more good, meaningful work. Organisations benefit from workers being more engaged with their work. How much of everyone’s innate potential gets used on a daily basis?

  • a) People spend a lot of time fighting fires and fixing up things that unexpectedly go wrong. (4 points)
  • b) Even getting the simplest things done takes much coordination, meetings, discussions, referrals “up the chain of command” for decisions, etc. Red tape is the normal state of affairs. People’s skills and special talents are not well-recognised nor often used to the advantage of themselves and the organisation. (12 points)
  • c) People can get on with what they know needs doing, coordinating with others when and wherever necessary. (25 points)
  • d) The organisation has automatic, systemic means to flag new opportunities and high-priority things that need folks’ attention. People then coalesce around these priority items and get them done straight away. (42 points)
[Note: Questions below here are not yet complete]

8) Respect for the individual

Autonomy, mastery, purpose.

  • a)
  • b)
  • c) People have the leeway to make their own decisions about what they do, how much time they spend on things, how busy they are, where they work, and so on. Everyone feels well-respected, both as human beings and for the contributions they make.
  • d) People hold each other to account.

9) Heroism

  • a) The organisation values the contribution of individuals, and encourages folks to work long hours
  • b)
  • c)
  • d)

10) Metrics

Some organisations subscribe to Lord Kelvin’s view that “If you can not measure it, you can not improve it”, others to Deming’s view that “the most important figures that one needs for management are unknown and unknowable”.

  • a)
  • b)
  • c)
  • d)

11) Principles (theory)  vs Practices

  • a)
  • b)
  • c)
  • d)

12) Toolheads

  • a)
  • b)
  • c)
  • d)

13) Testing

  • a)
  • b)
  • c)
  • d)

14) Defects Seen By Customers

  • a)
  • b)
  • c)
  • d)

15) Development Focus

  • a)
  • b)
  • c)
  • d)

16) CMMI

  • a)
  • b)
  • c)
  • d)

17) Risk Awareness

  • a)
  • b)
  • c)
  • d)

18)  Systematic Learning

  • a)
  • b)
  • c)
  • d)

19) Due Date Performance

How many product releases happen on the dates originally scheduled for them, i.e. at the inception of the product?

1) 10% or less. (4 points)

2) CIrca 25%. (12 points)

3) 40% or more. (24 points)

4) At least 75%. (42 points)

20) Use of Third Parties

How much of the budget of each new product is allocated to using the experience of third-party specialists (not e.g. individual temporary or contract staff, but people or organisations with highly-relevant specialist skills or know-how)?

  • a) Less than 10%. (4 points)
  • b) More than 20%. (12 points)
  • c) More than 40%. (24 points)
  • d) Our products have such leading-edge technology that we can’t find enough specialist help at any price. (42 points)

21) Post-Deployment Problems

  • a)
  • b)
  • c)
  • d)

22) Variation in Product Success

  • a)
  • b)
  • c)
  • d)

23) Attribution of Causes of Variation in Product Success

  • a) Individuals
  • b) Unsure
  • c) The system

24) Organisational Metaphor In Use

  • a) Office
  • b) Factory
  • c) Design Studio / Lab
  • d) Value Streams

25) Who “Does” the Change

  • a) Anyone that find themselves “stuck” with doing it. (4 points)
  • b) Management (and/or external consultants). (12 points)
  • c) The workers, collectively, supported by extra resources etc provided on demand by management. (24 points)
  • d) The system. (42 points)

Note: Further drafts will add more answers to the above questions, and maybe more questions, too. Please let me know how helpful you find this post in coming to terms with understanding “Mindset”? And let me know how your organisation scores? Thanks!

– Bob

Agile – Circa 1997

March 9, 2012
Agile, Familiar, Software development
Leave a comment

Agile – Circa 1997

The Story of INControl

This is the (short) story of an Agile project delivered by Familiar Limited, circa 1997.

Note: There’s a document on my website that describes the approach we used to deliver our projects at that time, then called “Jerid” and subsequently evolved into “Javelin”. Of course, in 1997 the term “Agile software development” had not yet been invented.

“One of the most successful extranet application development projects in CWC history” – Project Sponsor

INControl was CWC’s major extranet application, which enabled all its corporate clients to manage their telephone call routing through the CWC Intelligent Network via a plain old web browser. This replaced their previous service which had involved long and error-prone telephone conversations, plus exchanges of faxes, between customers and CWC’s specialist call centre staff.

The INControl project had spent a long, long time in the Fuzzy Front End. The client – Cable & Wireless Communications –  agonised over both the idea and the proposed technologies (WebLogic, Java, J2EE, Swing, etc.). Sun Microsystems had sponsored a number of technology demonstrators in order to close the deal and sell the necessary tin and string.

Finally the client gave the go-ahead to commit development engineering resources to the project, so we called in the folks we had already lined up to do the engineering, architecting, designing, testing and sys admin-ing, and launched the first two-week time-box – or “cycle”, as we then called it.

We already had some information on the basic features of the project, and the client’s particular priorities. Internally selling the idea across CWC was important to the project sponsor, so we focussed the first cycle on producing a working model of the GUI, selecting a few key event types to implement first. We also took the opportunity to make a start on prioritising user stories and elaborating the first (highest-priority) ones, and scheduled the first of the monthly Risk Workshops.

Being the first cycle of the project we also knew, even before the Risk Workshop, that deliverables of the cycle would include some of the basic ‘contextual’ information – a name for the project, a Statement of Purpose, a Project Charter, a Case For Action and a Vision.

Each cycle, in what turned out to be a thirteen-cycle (i.e. 26-week) engagement, followed the same iterative Plan-Do-Check-Act pattern: Cycle planning on the morning of the first Monday, working according to the plan for the next ten days, and a cycle review (internal process retrospective) on the second Friday.

Each Monday morning the team would get together and plan out the deliverables, and interim work products, for the upcoming two weeks. The project sponsor provided input in terms of which user stories should take priority, and what he and the other CWC stakeholders wanted to see during the cycle, and at the end of the cycle.

The evolving Risk Parade (the main deliverable from each Risk Workshop) highlighted to us those areas where we should take special care, or schedule mitigating work items, and the results of the previous cycle’s Cycle Review (a.k.a. retrospective) reminded us of where we needed to act to improve the development process itself.

The core of each cycle planning session involved the team members identifying what work items were going to be needed to:

  • deliver the chosen stories
  • manage the risks
  • improve the development process

and the team members also estimated how long they each would allocate to working on each of the consequent work items.

Delivery Rhythm

The  results of the first cycle were very well received by both the project sponsor and the various stakeholder constituencies within CWC, so much so in fact that a number of people within the client’s organisation volunteered to work closely with the development engineering team on elaborating the requirements (iteratively) for the project as we moved forward. We would have promoted this first ‘release’ into production, but were waiting for the delivery and commissioning of the necessary server hardware and infrastructure (a joint Sun-CWC responsibility and outside the remit of the development engineering team).

In cycle 4 we booked the Madjeski Stadium Directors Box to present the first fully-functioning end-to-end release of the application to an audience of all the major stakeholders. The day was a great success, with senior CWC management pushing for a live system as soon as possible. Again, we could have released the system into production there and then, had the necessary infrastructure and client release / acceptance test procedures permitted.

Further cycles added further event types and lesser routing options, along with documentation and some minor performance tweaks.

Improving Along the Way

Some of the process improvements we introduced through the course of the project included:

  • a mini feature-schedule to help coordinate the work of the various engineers within a given cycle
  • a daily stand-up to help coordination further
  • work items being specified by their down-stream consumers (as opposed to how we started out, with the producer of a work item outlining the specification)
  • a collection of patterns to encapsulate and share common working practises – such as “FiveLinesOfCode”, “ConstantStateOfShip”, “CommonFrameOfReference”, “QualityGates” and so on.

Into Production – Better Late Than Never

Finally, with the commissioning of the production infrastructure in sight at last, the focus of our final couple of cycles shifted to getting ready to deploy the product into live production.

Some three months after the end of the first thirteen cycles, the client’s customers had received the new service so well that CWC commissioned another couple of cycles to add some more features into the product, and we were able to assess the quality of the system in production. The system had run live and uninterrupted 18×7 for over three months, with only three minor defects reported in that time.

As CWC themselves said of this feat:

“this was one of the most successful extranet application development projects we have ever seen”.

Ironically, one lesson we learned was that it could have been even more successful had we had responsibility for the commissioning of the production infrastructure too.

C’est la vie!

– Bob

Project Charters and Social Contracts

March 9, 2012
Dialogue, Familiar, Software development
Leave a comment

Project Charters and Social Contracts

On just about every project I’ve been involved with over the past twenty years, I have promoted the idea of a “Project Charter” (or better-yet, a “Social Contract” for the project).

I have reproduced the basic template for a vanilla Charter, below.

Aside: These days, I myself would avoid working within the structure of a “project” wherever and whenever possible, the “project” concept being a zero-sum game, at best. But I recognise many folks have not reached that happy place, as yet. Accordingly I’m open to the accusation of helping folks “do the wrong thing righter” with this post. Folks still mired in the project swamp may find it useful, nevertheless.

The Project Charter

The strength of having a charter (a.k.a. Article of Understanding) lies in helping stakeholders – dev team members, sponsors, customers and others – understand the social context and mutual responsibilities involved in working together. When it works well, everyone is more or less “on the same page” with regard to expectations, etc.

Sample

Article of Understanding

In line with meeting the needs of the project’s stakeholders as quickly as possible, the project team wishes to keep the amount of detail in the requirements for this project to a prudent minimum. The following Article of Understanding attempts to set a certain level of expectation amongst all concerned regarding the likely consequences of that wish:

“Project [Project name – TBD] will try to capture every important requirement in its functional- and non-functional- requirements models, but gaps and ambiguities will inevitably occur. To resolve these the project team will need to invent details on their own. On a typical project, hundreds of such gaps can exist, which makes it impractical for stakeholders and the project team to confer about each one. The project team typically resolve the vast majority of these gaps without the stakeholders ever becoming aware that an ambiguity existed.

In some cases, a stakeholder will have a strong feeling about how the project team has resolved a particular ambiguity and will require a different resolution. This happens to a greater or lesser extent on virtually every project. To the extent that a stakeholder clarifies such ambiguities later in the project to mean something different from the project team’s earlier assumption, there will probably be negative impacts on costs or schedules, or both. The project team will try from the outset to structure the deliverables to minimise these negative impacts, but we all know from long experience the inevitability of this unfortunate feature of development. We will all try to remember this.

The project team undertakes to try to be responsive to the stakeholders’ needs and create solutions that satisfy those evolving needs with minimum disruption to costs and schedules.

The stakeholders undertake to remember that the project team tries its best when interpreting gaps in the requirements.”

The key weakness of a project Charter, is the unilateral or one-sided nature of the document. Typically drawn up by the dev team, a Charter rarely affords the opportunity for buy-in and commitment from all stakeholding parties. In many cases, stakeholders do not see the value in spending time understanding and committing to such a charter. Indeed, quite often some stakeholders will fear the loss of control and increased accountability that such a multi-lateral agreement notionally brings.

A project Contract, on the other hand, demands more work and more understanding from all the signatories, which can take much time and effort to negotiate and discuss. Many organisations are not prepared (sic) to commit the level of effort required to make this happen.

– Bob

Postscript

I do not intend for the reference to “requirements” in the above sample to imply e.g. a Big Design Up Front approach to requirements gathering. If you feel the word may seduce your readers into this assumption, feel free to make more explicit the iterative nature of requirements gathering – assuming that’s how you run your projects, of course.

Mutual Learning

March 6, 2012
Coaching, Leadership, Organisational effectiveness
2 Comments

Mutual Learning

I have an admission to make. (I have others, but I’ll stick to just the one for now).

I’m not very good at mutual learning.

I mean, I’d like to be. And on those rare occasions when it has happened, I can admit to feeling a sense of well-being and connectedness that’s hard to describe.

I can espouse all the values of mutual learning. But living them (putting them into action) is another matter. I guess the nature of one’s role naturally constrains the opportunities for mutual learning. However, that said, I am resolved to experiment with increasing the mutual learning opportunities in any future roles I may have.

Mutual Learning and The Coach

I suspect that, as a coach, I have a bias in action away from mutual learning. When actively coaching, I’m most interested in what the player is learning about their chosen topic/field/subject/issue, and I’m also interested in what I’m learning about coaching more effectively. But I couldn’t call that very mutual. It’s not like we’re co-exploring the same landscape together. And that makes me feel like we’re both missing out on something. Ditto for team coaching, only on a larger scale.

If you’re a coach, or have coached in the past, have you experienced this too? How do you feel about that?

I’d love to explore the possibility of more mutual learning in coaching assignments and I’m wondering how that could work. I suspect that if there is a way to make it happen, it could have some useful benefits, including:

  • Quicker learning for all parties
  • Increased retention of things learned (more scope for putting the learning into action)
  • Higher commitment to coaching sessions (on both sides) and to the idea of coaching, in general
  • Improved working relationships (and not just between coach and player)
  • Greater personal satisfaction all round

I am resolved to experiment with increasing the mutual learning content in future coaching sessions.

Mutual Learning and the Scrum Master

The role of Scrum Master has much in common with coaching, but differs in that folks typically expect the Scrum Master to be a subject-matter expert too. Whether these two aspects are compatible is another issue (see a previous blog post on this).

As a (some time) Scrum Master, I have noted more opportunities for mutual learning than in a pure-play coaching role. Upon reflection, I believe this is one of the main reasons I enjoy Scrum Mastering. I suspect not all Scrum Masters have the luxury (or wish?) of being able to indulge in mutual learning, at least openly, preferring or being obliged to appear omniscient.

Mutual Learning and the Consultant

Not many consultants I have met seem interested in mutual learning, except discretely and at the expense of the client and or co-learners. Not to say that consultants avoid learning, rather the opposite, just that the nature of the relationship is too often one of exploitation rather than partnership.

I am resolved to experiment with increasing the mutual learning content in future consulting engagements.

Mutual Learning and the Manager

In “The Great Game of Business”, Jack Stack tells a number of stories of managers who stepped outside their comfort zones, deciding to stop pretending the had all the answers, and embrace mutual learning alongside their employees. In the book, at least, this turns out well, variously delivering some or all of the various benefits promised by the mutual learning approach. In my own sojourns under the management hat, barring or perhaps because of the failures of my early attempts, I have always tried to join with others to find stuff out together.

Nevertheless, I am resolved to experiment with increasing further the mutual learning content in future management roles.

Mutual Learning and the Leader

Finally, we come to leadership. On the home page of my website, you will find this paragraph:

“you’ll never guess what I’ve found”

Effective transformational leaders engage people with the idea that meaningful change is possible. Specifically, by encouraging people to look with them at how the work works (understanding the business as a system), effective transformational leaders build engagement, enthusiasm for improvement, and an infectious sense of urgency and shared purpose. This approach requires strength, resolve and, perhaps above all, the courage to be different.

(Note: This was not intended to imply that a leader is “above” others in some hierarchical sense, more that anyone can adopt this role when they discover something curious and potentially significant).

I am resolved to experiment with increasing the mutuality of the leadership role and the mutual learning this implies.

Finally

In the spirit of mutual learning, please let me ask: “What has been your experience?”

– Bob

What Makes a Great Software Developer

March 6, 2012
Agile, Coaching, Leadership, Organisational effectiveness, Software development
Leave a comment

What Makes a Great Software Developer

Most pundits who attempt this question focus on the personal characteristics of the developer as an individual. Accordingly, some say it’s about technical skills, some about abstract reasoning, some about the ability to work in a team, some about an improvement attitude, some about hard-working dedication, some about systems thinking… yadda yadda.

I have a different take.

Dr. Deming has taught us that circa 95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and just 5% are attributable to the individual. If we accept this (and I certainly do), then all the discussion about attributes of the individual becomes essentially moot.

If we extract an outstanding developer from one system (e.g. the team, business, in which they “have performed well”) and place them into another system, their performance will depend almost entirely (95%) on the new system within which they are now working. And NOT on their own personal attributes, skills, talent, or whatever.

This realisation can be a bitter pill to swallow; not only for you, dear readers, but also for the developer in question.

Frederick Herzburg is famous for (among other things) saying “If you want people to do a good job, give them a good job to do.”

Many times, the effect of the system on the performance of an individual can be masked, or hidden entirely, by similarities in the “from” and “to” systems. This is quite common, given the preponderance of “Analytic” organisations, with consistently poor scope for effective working.

The one ray of light in all this? If a particular developer has skills related to changing the system, and can negotiate the minefield that is “changing how the work works”, then as the system changes, they – and many working with them – will “perform” that much better. And most likely feel much happier for it, too.

BTW All the above applies not only to developers, of course, but just as much to other job titles in an organisation, management included.

– Bob

Further Reading

The Great False Dichotomy – Pay for Performance ~ Tripp Babbit’s Blog
The 95/5 Rule ~ Tripp Babbit’s blog

Misconceptions of the Analytic Mindset

March 6, 2012
Organisational effectiveness
5 Comments

Misconceptions of the Analytic Mindset

One reason that organisations with a prevailing Analytic mindset are significantly less effective than their more “Rightshifted” peers lies in the misconceptions these organisations perpetuate, misconceptions that impact these organisations daily.

  1. Shareholder Value or EVA (Economic Value Added) is the ultimate reason for doing business. Fact is: EVA is not a reason. It is just a result and a necessary side effect of doing business.
  2. Companies must provide the financial markets with earnings guidance and will be rewarded for this. Fact is: Providing shareholders and analysts with predictions of future results results in a “fixed performance contract” which forces delivery of the promises made at all costs. Companies including UBS, Porsche, Google, Coca Cola, and Citigroup have abandoned this practice.
  3. Growth and profit are the most important measures of success. Growth can in some cases be a good indicator of superior value creation and competitiveness. Often, however, it is not.
  4. It is possible to measure the performance of individual employees. Fact is: It is not. Organizations are “living systems” in which performance always depends on interaction between different players.
  5. It is possible to measure performance objectively. Fact is: Measurement is never objective. It is always based on assumptions previously made either consciously or nconsciously, and is only an indication of actual performance.
  6. With the right indicators, a good manager can manage the organization. Fact is: Indicators can provide “indications” with regards to performance, but never answers. They are useful if they raise questions in teams and among employees, but can be highly dangerous if interpreted as “objective.
  7. Performance is over-proportionally influenced by top management Fact is: Heroic management is ineffective in dynamic and complex environments. No longer can those at the top of organisations  expect to take effective decisions in constantly changing and highly dynamic environments.
  8. The reasons for poor performance can be attributed to individual employees. Fact is: It is more important to ask what inhibits a person or team from performing well. We should focus on how changes in the system would enable folks to perform better.

My thanks go to www.betacodex.org for the above list.

– Bob