&mdash; Think Different

Antimatter principle, Familiar

Fixing Product Development

Most organisations know their approach to developing new products, and evolving existing ones, is broken. Not in any explicit, obvious sense. More like a dull, nagging headache at the back of the corporate brain. Something seems wrong, but we can’t put out finger on it, or even be sure that something is indeed wrong.

And most organisations leave it at that. Absent an understanding of the root of the problem, so it goes, there’s not much to be done.

Ackoff would reject this. As would the positive psychology folks.

Ackoff would suggest Idealised Design as a way forward. Imagine your whole Product Development staff, know-how, processes, etc. had disappeared overnight. Actually, this is not too far from the status quo in many organisations, really. What would you go about building to replace it from scratch? Now. Today. And how could you get there, from where you are?

Well, if it were down to me, I’d probably focus on an approach to Product Development centred on meeting people’s needs. Customers, buyers, design and development people, operations folks, the whole covalent nine yards. And thence down the pyramid of Needs -> Emotions -> Value -> Flow.

You don’t see many Product Development approaches with this kind of focus on needs. Why not? I’m guessing it’s because you can’t get there from here. Even regular, nay continuous, improvement of present approaches will just end up on some very low local maximum (see chart).

For a radical, practical approach to Product Development, it’s necessary to take what we collectively know – NOT what any one company knows – and build a new golden opportunity to do it right. That is, of course, if Product Development is at all important to you.

Do you need it, sir? Do you? N-e-e-e-d it? Oh! Suits you, sir!

– Bob

Needs And Fulfilment

October 25, 2014

Needs And Fulfilment

When, nearly twenty years ago, I started Familiar it was with a very clear and declared purpose:

“To allow people to come together and discover what ‘fulfilment’ means for each of them as individuals.”

At the time, few working with us understood the import of that purpose. And those observing from the sidelines, even less so. In fact, most outside observers called it “madness” or “apple-pie land” or some such. Maybe it was an idea ahead of its time.

But now, wiser heads – such as Alain de Botton, Nilofer Merchant, Professor Gary Hamel, Simon Sinek, et al. – write about the need for a more humane workplace. And of course, W Edwards Deming and Peter Drucker were writing and teaching about this kind of thing half a century ago.

“One of the most Googled questions is: ‘What should I do with my life?’
There’s a fantasy that there’s actually an answer out there.”
~ Alain de Botton

De Botton believes there is a desperate need for more companies that are explicitly focused on working out what someone’s talents and inclinations are, identifying their potential, then guiding that person towards a place in the economy where this potential may be best applied and expressed.

I so believe, also. I suggest companies and organisations which lend support to their people in their search for meaning will reap the harvest in many beneficial ways.

And I have proposed the Antimatter Principle as a means to address this and make it happen.

What do you believe?

– Bob

This Rotten Edifice

October 24, 2014

Lamentation

This Rotten Edifice

I see the rotten edifice we have constructed, and I weep.

I see people labouring to buy things under the misapprehension it will make them happy. Things which then own them.

From top to bottom, I see people who have no faith, no joy in what they do. Yet feel obliged to act as if they did.

I see people worshipping at the temple of Mammon, knowing he is a false god.

I see people going through the motions, putting on a brave face, pretending that what they’re doing matters, that there’s some point to it all.

I see people in thrall to the delusion that if they just stick at it, things will be better one day.

I see people making themselves and everyone around them miserable because they’re bought into, bet their farm on, this rotten edifice.

I see people full of resentment, playing the game and hating it all at the same time.

I see people take refuge in friendships, family, pets, hobbies – unable or unwilling to address the core issues of being part of this rotten edifice.

I see people capable of so much more, resigned to settle for so little.

I see people, each suffering in silence, not talking about what matters to them, how they feel, what they need.

Such beauty in the world. Such a rotten edifice obscuring our view. Where’s the joy?

– Bob

Are You Stuck?

October 23, 2014

Coaching, Fellowship, Psychology

Antimatter principle, Dialogue, Organisational effectiveness, Organisational Therapy, Psychology

Are You Stuck?

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

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

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

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

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

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

“Getting unstuck is half the fun in life.”

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

– Bob

No Need To Learn

October 22, 2014

Antimatter principle, Organisational effectiveness, Psychology, Rightshifting

No Need To Learn

How much does it bug you, working with folks that don’t or won’t learn? Folks that keep banging the rocks together, churning out crap code or following old myths and status quo policies, rather than exploring, experimenting, and thinking for themselves?

If we accept, as I do, that people’s behaviour is always based on getting their needs met, then it’s easy to explain this kind of situation.

The fact that it bugs you means some of your needs are not getting met. And the fact that they’re not learning means they have no needs that might get met by them learning stuff.

Actually, that latter assertion is a little too brassy. If they’re not learning, it could mean that they have do some needs that are not getting met, that learning could help with, but they don’t see learning as a viable strategy in their context.

Predicament

Of course, if they don’t see learning as a viable strategy, then they’re pretty much unlikely to learn to see that learning could be a factor in a more effective strategy for getting their needs met. We might call this a predicament.

What To Do?

Is there anything we can do in this kind of situation?

A couple of things come to mind.

Empathy Earns The Right To Dialogue

Empathise with them and their predicament. Not in a snarky “I guess you’re feeling frustrated that you can’t learn anything” kind of way. Rather, something like “I guess you’re feeling frustrated that you can’t move forward.” Chance are, patient empathising along these lines might earn you the right to talk with them about your own needs, your needs which are not getting met. The ensuing dialogue may benefit both parties. And lead to both parties better getting their needs met. Maybe even some joy will come of it.

Experience Can Be A Great Teacher

Alternatively, see if you can create a situation where their learning something would help them better get one of their needs met. This experiential, or normative, learning may help them see – perhaps for the first time – the value of learning. This can be the gateway, with reinforcement, to their choosing to replace one or more of their existing strategies for getting their needs met, with strategies that involve learning.

No Perceived Need, No Change

Remember, many people see absolutely no need for learning stuff.

Unless they choose to connect learning with more effective strategies for meeting the needs they do have, learning will remain conspicuous by its absence. You’ll continue to be bugged by it. And nobody wants that.

– Bob

Why Rightshift?

October 21, 2014

Agile, Organisational effectiveness, Software development

Why Rightshift?

Thomas Lindqvist recently posed a question you might find interesting:

Or, in more common parlance, what motivates an organisation to put time and effort into improving its overall effectiveness? You might think this kind of improvement a common objective – but in my experience it’s very uncommon.

In response, I suggested that the motivation – when present – comes from the Core Group attempting to get their needs met. Manifest in what I refer to as “organising intent”. Absent the Core Group seeing improvement as a viable and effective strategy for getting met their particular needs of the moment, it’s unlikely that improvement – whether in-band or out-of-band, whether Kaizen or Kaikaku – will receive much attention or support.

Note that in this post I’m talking primarily about the motivation to tackle one of the three great transitions in the Marshall Model.

Incremental Improvements

I can go with Kotter’s explanation of motivation for incremental, out-of-band improvement: Urgency.

“Visible crises can be enormously helpful in catching people’s attention and pushing up urgency levels. Conducting business as usual is very difficult if the building seems to be on fire.”
~ John Kotter

Yet, this begs various questions:

To whom does a sense of urgency matter?
Why do they feel this sense of urgency? (Upon what information is their feeling based?)
What are their needs, needs that might be better met if a sense of urgency prevails?
How will the sense of urgency get expressed?
What will that expression lead to?

Transitions

I don’t believe organisations contemplate transitions (wholesale replacement of their collective mindset) when they find a crisis upon them. Urgency seems irrelevant. Transitions will seem like they just take too long to be an effective survival response to an impending catastrophe.

Rather than urgency, the question of whether to tackle a transition is more likely to arise when e.g. the Core Group come to believe that existing avenues – like kaizen, continuous improvement or just plain old business-as-usual – have run out of steam. That these avenues no longer afford the promise of further improvements. Or that the ROI on such avenues has become marginal.

Of course, for a transition to even become a option requires that e.g. the Core Group feels some dissatisfaction with current levels of performance, of effectiveness. That the organisation’s performance fails to meet their needs in some significant way. Absent this condition, it’s likely things will just bump along as always.

Summary

So, how do you gauge the organising intent of your organisation’s Core Group? Is it bent on improvement? Or does its focus lie elsewhere?

– Bob

Why Does Agile Fail?

October 20, 2014

3 Comments

Why Does Agile Fail?

It’s still not fashionable to talk about Agile failure. I guess those few of us who do win few friends by it.

Never mind. My motivations stem from trying to make the world of work – of knowledge work – a better place for the millions who suffer the consequences of ineffective organisations, day in, day out. I don’t expect much thanks for it, but there it is. Take it or leave it.

I’ve given up using deontological moral and ethical arguments in favour of utilitarian ones. Not that I expect any form of argument – be that rational or emotional – to have much effect. Normative (experiential) learning seems like the best – nay, the only – game in town these days.

Definition

For the sake of clarity, let’s define what I mean by “failure”. Failure, here, is simply the failure to realise the desired or expected results from adopting an Agile approach to e.g software development. People generally know – although not always explicitly – what outcomes or results they’re looking for.

Some Reasons

So, why does Agile fail? And fail it does, in at least 75% of cases. Maybe as high as 95% of cases. Reliable numbers are hard to come by. Especially with so many vested interests in the mix.

By design.
As a local optimisation – because Agile was conceived as such – even when the Agile adoption “succeeds”, it only addresses some 10% of the problems with software development. The 10% the development team can fix themselves. Some 90% of the problems remain inaccessible to the team. Only when the wider organisation gets involved can those other 90% receive some attention. And without this wider attention, the rest of the organisation will assume Agile has failed. It’s a matter of expectations, really.
By mindset.
Bringing a classical, command-and-control, analytic mindset to a software development effort is like bringing a knife to a gunfight. Without a collective mindset bent on enabling learning, discovery, innovation, self-organisation and cognitive function, results will remain poor irrespective of practices.
By time.
Even when an Agile adoption succeeds, and even when the other 90% of the problems outside the development team get attended to, it’s likely that the solutions are not long for this world. Unless the question of Organisational Cognitive Dissonance is also addressed – whether by luck or intention – any short-term gains are hostage to the vicissitudes of fortune.
By cargo-culting.
Many Agile adoptions consist of little more than adoption of a set of practices. Agile “by the book”. With little or no inspection and adaption, or understanding of the underlying principles. This can often happen when e.g. management see Agile as just another “software development method”.
By naivety.
Software development is not a simple endeavour. Control and predictability are not possible, however much we might naively wish for them. Or believe we need them. Software development is about the dance between organising intent and countervailing entropy. Attempting to run a software development effort like it was easy or simple or manageable is simply asking for failure.
By mistaking the nature of the work.
Software development is a kind of collaborative knowledge work. Mistaking it for something else – for administrative, repetitive or manual work – is another shortcut to the failure farm.
By bad luck.
So many random factors can impact an Agile adoption. Let’s acknowledge that even when all our ducks are lined up, often things can just go awry. Sponsors and champions can change post or leave. Key players in the delivery teams can quit. Upturns and downturns in the organisation’s markets can distract and detract. Technologies can suddenly change. Regulatory constraints shift. New fads can overtake our plans.

Honestly, so many things can undermine an Agile adoption, it’s a surprise to me that any attempts actually succeed. And it’s not even that a successful Agile adoption means a big uplift in organisational effectiveness. Better to invest our limited time, attention, and money in something with a much bigger potential payback, if you ask me. Which you probably didn’t.

– Bob

Changing Behaviours

October 19, 2014

Antimatter principle, Organisational effectiveness, Psychology

3 Comments

Changing Behaviours

[Tl;Dr: If your organisation is changing and needs its people to adopt different – maybe more productive – behaviours, the Antimatter Principle can help make that happen.]

It’s Not About Morality

I’m guessing that many people see the Antimatter Principle as some kind of moral crusade.

“Do the right thing!”

“Attend to folks’ needs!”

“Be a better human being!”

“Be kind to people!”

Nothing could be further from my intention. My position on the Antimatter Principle is (almost) entirely utilitarian. Which is to say, I invite you to consider the consequences of applying the principle, rather than judge it in a deontological moral or ethical context.

Let’s look at the problem it’s trying to address, and the nature of the solution.

The Problem

I have been for a long time interested in the thorny question of people and their behaviour. What drives people’s behaviours? Why do certain people behave in one way, and others in different ways, even in much the same situation?

More specifically, why do people doing various kinds of knowledge-work, such as software development, not adopt the most effective ideas in the field? With the advent of the internet such ideas are widely known and easily referenced, yet uptake is slow and patchy, to say the least.

I guess there are dozens, maybe hundreds of different reasons why people don’t adopt a new idea as soon as they find it. But I’ve been looking for some more general “rules” governing these situations.

Needs Drive Behaviours

I have come to the working hypothesis that, overall, folks’ needs drive their behaviours. That is, people do things to try to get their deeper, personal needs met. This interpretation of behaviour comes from e.g. Marshall Rosenberg’s work on Nonviolent Communication.

Strategies

Not explicitly mentioned by Rosenberg, but now receiving attention from neuroscience, is the question of why do different people go about getting their needs met in such wildly different ways?

For example, why would one “normal” human being attempt to “get things done” by diktat, when some other “normal” person might attempt to “get things done” through collaboration, dialogue, and fellowship?

Allow me to introduce the word “strategy’ here. In a given situation, attempting to get a similar need met, different folks may well employ demonstrably different strategies. These different strategies may span a broad spectrum – from highly ineffective through to highly effective. It’s difficult to imagine why people might continue using highly ineffective strategies when getting their needs met is the key driver, but even cursory observation tells us this happens all the time.

Indeed, this is central to the work of Chris Argyris, when he talks about espoused theories (the strategies people think they use, and believe would be effective) vs theories-in-action (the strategies people actually use, in reality – almost always less effective than their espoused strategies).

Where do our strategies come from? They come from experience. The strategies we each use in our day to day lives, we have acquired since birth.

The crucial challenge, then, for each of us, is not in acquiring strategies, but in replacing less effective strategies with more effective ones.

Aside: This is the de facto core of most kinds of therapy, counselling, coaching, and so on.

The Challenge

In a work setting, where e.g. managers are concerned – at least in principle – with finding ways to make people more productive, the challenge could be characterised as:

How to get the people to replace some or all of their less effective strategies with progressively more effective ones?
whilst
Not harming the longer-term cognitive function and goodwill of these same people.

Normative Learning Owns

In her maddeningly inconsistent book, “The Art and Science of Changing People Who Don’t Want to Change”, Reut Schwarz-Hebron suggests that normative learning is the only path to replacing less effective strategies with more effective ones. That is to say, only when a new strategy is tried in the crucible of action, and found superior to the existing strategy, will the new strategy win out, get adopted, replace the previous one, and stick.

Aside: This emphasis on normative learning is, of course, one of the foundations of John Seddon’s Vanguard Method.

Aside: Reut’s book says nothing, explicitly at least, about the matter of interlocking strategies (memes, if you will) and the challenges of replacing entire memeplexes of interlocking memes, wholesale. I’ll not delve further into that topic here, today, either.

Support

Reut Schwarz-Hebron also suggests that some 90% of people are unable to effect such replacement of their own strategies without some external support, such as from a manager, coach or therapist. Her book goes into more detail about the “system” she has invented to help e.g. managers provide this support.

Aside: Her “system” reads way too much like PR hokum for my liking. YMMV.

Needs

So, from a utilitarian perspective, adopting the Antimatter Principle – attending to folks’ needs – is, in itself, a strategy for getting a need met.

What, and whose, need? The need of the organisation, manifest through the needs of its managers and executives, to see its people replacing less effective behaviours with more effective ones.

And the path to getting that need met?

When people begin attending to folks’ needs, people start to become conscious of needs. In turn, people begin to become aware of the strategies they – and others – are using to get their individual – and collective – needs met.

Once the idea of strategies – and the very possibility of replacing them – takes hold, people can then – but only then – begin to consider the relative merits of their present strategies, and potential candidate replacements.

Back To The Neuroscience

Wrapping up, I come back to the neuroscience. My writing this post may provide you with some information about the Antimatter Principle and how it works to support changing behaviours. But that’s not going to do much to help you change your behaviour, adopt the idea, adopt it as a strategy. (See: The Problem, above).

For 90% of you, unless and until you apply it, your brain will find all kinds of ways to resist it and reject it, no matter how much more effective it might promise to be in practice. And for that 90%, it’s likely that you wont even get to applying it without some external support.

Where might you start looking for such support?

– Bob

Changing Others?

October 16, 2014

Management, Rightshifting

Organisational effectiveness, Prod•gnosis, Product development

Changing Others?

Here’s a fairly common scenario:

You’re a manager responsible for 100+ people, all involved in some kind of knowledge work. You’ve been asked, told – or maybe feel the need yourself – to do something about the productivity of your group. How would you proceed?

Aside: I’ve been in this situation myself some number of times, and seen or helped managers with such scenarios, too.

Beliefs

How a manager decides to proceed is most often a function of what they believe about the nature of work, and the nature of people.

I’ve seen managers issue diktats: “You will improve”.

Opt to get consultants in: “These guys will tell you how to improve”.

Or “coach” people: “I’ll show you the way to improve” (not my definition of coaching, btw).

I’ve rarely seen a manager say: “Let’s sort this out together”.

But if you accept the answers to these Six FAQs, then this latter option seems like the only viable, long term basis upon which to proceed.

And if that is so, then the key questions become:

“Can we all agree that we need something to be done?”
“If we can so agree, who’s going to be involved, and in what ways and degree will they be involved?”
“For those who are closely involved, how shall we make a start?”

The last of the above questions is something like the Theory of Constraints three questions:

“What to change?”
“What to change to?”
“How to effect the change?”

Or, maybe, just these two questions:

“What is the purpose of this work, from the paying customers’ (end-users’) point of view?”
“What measures will the workers choose and use to understand and improve their work?”

Do you concur, or would you choose a different way to proceed?

– Bob

Product Development 101

October 15, 2014

Product Development 101

“What is Product Development?”

I’m pretty convinced that few folks – even those with product development responsibilities, working in product development organisations – could easily answer this question.

The Wikipedia entry for “New Product Development” doesn’t seem to have a useful answer. Actually, I prefer the brevity of the entry for “Whole Product”.

Tom and Mary Poppendieck refer to the “Concept to Cash pipeline” e.g. the evolving of a vague idea into a revenue-earning product. Some more technically-minded folks like to describe product development as the creation of operational value streams.

But I’m not looking for a partial, complicated or technical answer. I’m looking for an answer that my grandma could relate to. Something like:

“The life blood of businesses everywhere is revenue they earn on the products and services they sell. As times change, existing products and services can begin to lose their appeal, and so both sales revenues and profit margins can begin to fall. To remain successful and profitable, businesses find themselves having to introduce new products and services, as well as upgrading or retiring their existing products and services. From an inkling of a new product, service, or upgrade, all the way through to having something ready for folks to buy – everything that a business does in this regard we call ‘Product Development’”.

I’ve been spending time with various product development organisations recently. Or, rather, with some folks who work for organisations in which the introduction, upgrading and retirement of products and services is central to their business model. (As opposed to organisations with one or more long-lived, more or less unchanging, cash cows).

Time and again, it seems to me that rather than product development being done all wrong, it’s more like it’s not being done at all. Or at least, not in any kind of intentional, deliberate, organised way.

I see lots of software development going on (the products in question being software-intensive in nature). But precious little, if any, product development.

The Product Development Organisation

For me, an essential aspect of Product Development is the organisational perspective. Most established organisations will be introducing, upgrading and retiring products – and services – on a more or less regular basis. So

“Product development is about developing products, not just a product.”

I see few organisations indeed that are set up to do this in anything but a purely ad-hoc way.

Does It Matter?

If we accept POSIWID (the purpose of a system is what is does) then it doesn’t matter much at all. Most organisations, most executives, most managers, and most staff seem happy with – or at least, resigned to – the current state of dysfunction in their product development efforts. I’m pretty sure they don’t know – and don’t, presently, much care – what it’s costing them, personally and collectively.

And until we begin to look at product development as a pipeline, a.k.a. value stream, through which ideas flow – from concepts to revenue streams – I guess things will just have to continue in that vein.

– Bob

A Prayer For Effective Discussions

October 14, 2014

Community, Dialogue, Fellowship, Organisational effectiveness, Organisational Therapy, Teambuilding

A Prayer For Effective Discussions

We all dread unproductive and ineffective conversations, discussions, and meetings. Stuck in a room, feeling one’s life force ebb away, frustrated beyond measure that we’re not accomplishing anything useful, and with a mountain of other more useful things we could be doing inexorably bearing down on us. We pray for it to end – and end swiftly – so we can get back to our lives.

But before feelings of angst and frustration set in, I often have high hopes. This prayer resonates:

“As we prepare to spend this time together, let us cherish and celebrate our shared humanness, our shared capacity for reason and compassion, our shared love for the people here to day, and for those who could not be here with us.
Grant us the wisdom, the patience and the skills to use our time here well, to find meaningful human connections, and to learn together, for the benefit of all.
In gratitude and in love, in reason and in compassion, let us work together for a better understanding, to know more, to find shared insights, and joy.”

Courage

When I was working with S.W.I.F.T. in Belgium some years ago, I came across Russ, a no-nonsense Australian. Amongst his many engaging attributes, I found his approach to meetings quite refreshing. If a meeting offered him nothing in the way of addressing his needs, he’d simply not attend. And if, during a meeting, it seemed unproductive or of little value, he’d get up and walk out. I often find myself wishing for the courage to do the same.

So, what do you do when you find yourself in a conversation, discussion, or meeting that’s fail to meet your needs? What actions do you take? Who do you blame?

Facilitation

As an organisational psychotherapist, I have a particular stance on group discussions. I choose to listen, to try to sense the group’s feelings, and to stand with the group in its discomfort and frustrations.

If, by some twist of fate, others expect me to facilitate their discussion, I state that I prefer to listen, rather than talk or direct. This can occasionally result in an impasse, for example where a group is unable or unwilling to “facilitate” its own discussions. This in itself can be a learning experience, albeit a disconcerting one.

Blame

Maybe the biggest source of folks’ frustration in e.g. unproductive discussions stems from our natural tendency to blame others for our own emotional responses, our responses to not getting our needs met. God knows, unsatisfactory discussions and meetings can be a huge trigger for negative emotional responses.

“One of the core milestones on the path of consciousness transformation is the moment when we can fully integrate the radical awareness that our emotional responses to the world and to things that happen to us are never caused by another person. This awareness stands in stark contrast to our habitual speech, which states that we feel what we feel because of what someone else did. Instead, we learn, if we apply ourselves deeply to this practice, that our emotions are only caused by the meaning we assign to what someone did, and that meaning is generated from within us, not by their actions.”
~ Miki Kashtan

Positive Emotional Responses

Discussions can serve to meet our needs, though. Maybe that’s why we find unsatisfactory meetings so frustrating. As social animals, our discussions and meetings, if done well, can provide us with deeper and more meaningful personal connections, better understanding, useful new knowledge, shared insights, and joy.

Amen to that.

– Bob

Dancing With Entropy

October 12, 2014

Agile, Doctrine, Product development

Dancing With Entropy

In a post last year, I wrote about the nature of product development, describing its essence thus:

“The essence of product development is an intense and ongoing struggle between organising intent and entropy. Organising intent is the will of the company, manifest in the actions of its product development people, bent on meeting the goals of the company through the creation and evolution of products and product features.
Product development is fundamentally an interactive social process. We might imagine a randori situation (freestyle Aikido training) with a uke (receiver) and nage (thrower), each attempting moves and countermoves to try to defeat the other. Product development is thus a process of continuous adaptation to events, of give and take, simultaneous synthesis and dissolution. While we try to express our organising intent in the product, entropy resists us and seeks to countervail our intent. Appreciating this dynamic interplay between organising intent and entropy is essential to understanding the fundamental nature of product development.”

I suspect some folks, reading this through a certain frame, might interpret “entropy” to mean complexity, chaos, or complicatedness. And therefore, interpret my description of product development as essentially being about reducing complexity, avoiding complicatedness, or otherwise attempting to impose some order upon chaos.

This was not my meaning. I chose the word entropy carefully, although not, perhaps, carefully enough.

“Entropy: A measure of disorder in the universe.”

My frame for this choice was e.g. “the heat death of the universe”, and the widely-known quote, re the Second Law of Thermodynamics:

“The entropy of the universe tends to a maximum.”
~ Rudolf Clausius

It’s been my experience that the entropy of a software-intensive product development effort also tends to a maximum. And our task, if we wish to actually deliver something useful, is to recognise this and to find an accommodation to this “Law”.

Anywho, let’s not get hung up on the term.

My intent was to convey the idea that, in product development as much as in war, Friktion and the Fog of War both serve to frustrate the best laid plans of organising intent. Indeed, Clausewitz invented the term Friktion to describe the “resistant medium” in which war – and business – must operate.

To paraphrase Clausewitz:

“Everything in product development is very simple, but the simplest thing is difficult. In product development more than anywhere else things do not turn out as we expect. Close up, things do not appear as they do from a distance.”

For me, Clausewitz’s Friktion is “the only concept that more or less corresponds to the factors that distinguish real product development from product development on paper.”

However, Clausewitz suggests we tackle – or offset – Friktion through acts of willpower. Some business books have referred to this as “Grit”.

I’m a Lover, Not a Fighter

Here, I beg to differ. I’m much more of the opinion that, as with Aikido’s uke and nage, we would do better to learn to accommodate ourselves to Friktion (a.k.a. entropy). To embrace it, to walk with it, care for it, engage with it, and ultimately to dance with it. To regards it an asset. And yes, to love it.

“When the wind of change blows, some build walls, others, windmills.”
~ Chinese proverb

There’s a point in the book “Ender’s Game” where Ender The Genocide, having eradicated humanity’s implacable foe (the Formic race), explains:

“In the moment when I truly understand my enemy, understand him well enough to defeat him, then in that very moment I also love him. I think it’s impossible to really understand somebody, what they want, what they believe, and not love them the way they love themselves. And then, in that very moment when I love them…. I destroy them.”
~ Orson Scott Card, Ender’s Game

I feel very much the same way about entropy. In the moment when I truly understand it, understand it well enough to defeat it, then in that moment I also come to love it. At that moment, I no longer wish to defeat it, but to dance with it. To build great products together, entropy and I.

– Bob

Them And Us

October 12, 2014

Agile, Management, Psychology, Teambuilding

Them And Us

The formation of ingroups (and, thus, outgroups) is a natural human phenomenon. In the world of organisations, ingroups and outgroups abound.

One particular partitioning I see regularly is the division between “management” and “workers”. Members of each group self-identify, and in even the smallest organisations, members of the management ingroup can hold views widely at variance with the views of those who see themselves as “workers”.

Kent Beck is reported to have stated at Snowbird in 2001 that one goal of the Agile Manifesto was

“…to heal the divide between development and business.”

Presumably, then, this divide has some more or less pernicious consequences. Fundamentally, I suspect the most significant consequence is the impact of such division on the levels of trust between members of these two groups. And, absent trust, the working relationships between members of these two groups are bound to be fraught, to say the least.

The Management Viewpoint

Here’s the default management viewpoint (I feel qualified to express this, having self-identified with this group from time to time).

I’ve got far more important things to worry about, and on which to spend my limited time and attention, than matters relating to software development.
Software development is always borked, so no one’s going to complain – and threaten my future career prospects – if it continues to be borked on my watch.
Development is “technical” and my peers will ridicule me – and thus put my future career prospects under threat – if I appear to know too much about it (cf. threat to ingroup solidarity),
Having someone being seen to be in charge is more important – both to me and to the success of the organisation – than any “mere details” regarding efficacy, value, customer satisfaction, etc.
Customers do matter, but the quality of our software, its ergonomics, etc. is a minuscule component of our overall customer satisfaction ratings, Net Promoter Scores, etc..
As managers, we have so much to do that we find it hard to give anything the undivided attention it might require.

The Development Viewpoint

Here’s the default development viewpoint (I feel qualified to express this, too, having self-identified with this group from time to time).

There’s nothing more important to the survival of this business than the software we produce, and the way we go about that. Why can’t managers see that?
Software development has always been borked. But we’re smart people and we can fix it. It drives me insane to have to continue working in borked ways.
Development is “technical” and managers can’t or won’t get down and dirty to understand key things that they need to understand to make good decisions. And they don’t trust us to make or even provide input on any key business decisions.
Managers seem to think that having someone “in charge” is more important than making good decisions.
Our software is a crucial element in the customers’ experience of our products, service, brands and business.
As developers, we have so much to do that we find it hard to divert our attention from the one thing we agree is most crucial at any given moment.

I guess there’s a whole passle of other aspects to these groups’ respective viewpoints, too.

It’s not been my intent with this post to judge which group has the more useful viewpoint. Rather, to illuminate the often diametrically opposed aspects of these two groups’ ways of seeing the world of work. And the beliefs held by, and a part of the self-identity of, each respective ingroup.

Maybe such illumination can help in some small way to bridge the ingroup/outgroup boundary (a.k.a. divide, rift, gulf) between them.

– Bob

Amanuensarian

October 10, 2014

Agile, Antimatter principle, Community, Fellowship, Organisational effectiveness, Software development, Teambuilding

Coaching, Product development

Amanuensarian

In my work I get to see a lot of teams. Or, more accurately, I get to see a lot of groups of people who think they’re teams, or who other folks choose to call “teams”.

Nothing speaks to me quite so loudly or clearly about the teaminess of a group as their willingness to go to bat for each other. To commit their own individual time and effort on helping their teammates with their issues, and on advancing the progress and interests of the team, at the expense of their own egos, and synergising the needs and interests of the team with their own individual needs and personal interests.

Given the rarity of this phenomenon, small wonder then that the Amanuensarian is a role rarely seen in the wild.

The Amanuensarian Role

In a recent blog post describing an effective group workshop, I introduced the term “Amanuensarian”. This is a portmanteau term derived from the conjunction of “Amanuensis” and Cybrarian“.

Amanuensis
noun (pl) -ses
A person employed to take dictation or to copy manuscripts
Origin: C17: from Latin āmanuensis, from the phrase servus ā manū slave at hand (that is, handwriting)

In this context, the amanuensis’ role is focused on writing down or otherwise recording stuff to which he, she, or the team, believe they might need to refer later.

Cybrarian
noun
A librarian who uses computers and the Internet for their work; any person who works doing online research and information retrieval, esp. one who answers reference questions online; also called data surfers, super searchers
Origin: cyber- ‘cybernetics’ + (li)brarian

In this context, the cybrarian role is focused on understanding the team’s needs for information, on finding that information, and on bringing it back and sharing with the team, possibly recording it for future reference, too.

Skills

Key skills for the amanuensarian role include:

Ability to understand and anticipate folks’ information, sharing and reference needs.
Ability to understand the goals of the groups and the information required to address those goals.
Facility with search, recording, and sharing tools and technologies.
Ability to invent new ways of searching, recording and sharing information, tailored to the people at hand.
Google-fu.
Ability to coordinate team-related information with other teams and groups across the whole organisation, and value network too.

Bellwether

I find the presence of the role of amanuensarian a great bellwether for the teaminess of a group of people. Teams sharing common goals, and working together towards these goals.

“The purpose of a team is not goal attainment but goal alignment.”
~ Tom DeMarco, Peopleware

The amanuensarian role is all about attending to the (information and time-binding) needs of both the team as a whole and the individuals therein, and downplaying their own ambitions for the good of the fellowship of the team.

Any group of knowledge-work people will have a pressing and ongoing need for information on a host of topics. Finding such information, and moreover sharing it effectively, is a skill – and a task – in itself. People can undertake the task for themselves, and build their skills as they go, or the amanuensarian role can smooth the path and allow the rest of the team to focus on their own matters of import.

For a mental image, I think of Gandalf, galloping halfway across Middle Earth to seek out information concerning the One Ring – information vital to Frodo and subsequently to the mission of the Fellowship as a whole.

And where would any team be, without folks who seek out and hold their lore?

– Bob

Write Your Own – Flow

October 9, 2014

3 Comments

Write Your Own – Flow

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

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

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

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

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

Here’s the outline:

Product Development Flow

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

– Bob

The Universal Scrum Master Failure

October 7, 2014

Agile, Management, Organisational effectiveness

9 Comments

The Universal Scrum Master Failure

Here’s a post for everybody thinking about adopting Scrum, hiring Scrum Masters, or finding a role as a Scrum Master.

Most every Scrum Master I have met and talked with has said little about what I regard as the (near) universal failing of the Scrum Master role. A failing which is so significant that it negates just about all the positive aspects of the role put together. But a failing which can be remedied, given some awareness and cooperation on the part of adopting organisations and Scrum Masters together, preferably from the very get-go.

The Purpose of Scrum

There’s been much written about the core purpose of Scrum. The most widespread explanation seems to be about exposing organisational dysfunction:

“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
~ From The Scrum Guide (Schwaber and Sutherland)

Blockers. Impediments. Obstructions.

“Scrum highlights organisational dysfunctions and challenges us in uncomfortable ways.”
~ Deborah Hartmann-Preuss

“Scrum is a framework for surfacing organizational dysfunction.”
~ Tobias Meyer

“The Scrum framework is designed to surface obstacles that get in the way of delivering value.”
~ Stacia Viscardi

“An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.
Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.”
~ Ken Schwaber

Whoa. Hold on right there. Organisational dysfunction? As in, things that impact the development team but (generally) lie outside its immediate control? How many Scrum Masters – or their teams – want to tackle “organisational dysfunction”? I don’t see this happening much, in practice. And I don’t see the people driving the adoption of Scrum in organisations showing much awareness of it, either. Herein lies the universal Scrum Master failure.

Organisational dysfunction. This gets talked about and written about a lot. Many fine words. But not many people seem to know about this core purpose. Or if they do know about it, few seem to take it to heart. Or to act on it.

“The Scrum Master’s role is to remove impediments to the team’s progress.”
~ From The Scrum Guide (Schwaber and Sutherland)

Personally, I’d quibble about this being in the Scrum Master’s exclusive purview, preferring to see is as something for everyone – Scrum Master, Team and Product Owner all – to get involved in. But let’s put that to one side for now.

Getting Real

Whoever is addressing impediments, let’s get real. Most – I’d say some 80% – of the impediments impacting the development team will originate from outside the team, and resolution of these impediments will mostly fall to folks outside the team, too. Most likely, to managers and senior managers across the organisation.

Simply tackling the impediments within the team seems myopic, to say the least. Although in keeping, perhaps, with Scrum’s own inherent dysfunction – as a purely local optimisation.

So, we get to it. For me, the absolutely key role for any Scrum Master is to establish and nurture channels from the team outwards into the diaspora of wider management. Nothing else is as important. And nothing gets so little time and attention.

In this post, I’ll not go into why this might be, nor what to do about it. I will return to these questions with some answers, in a future post, if there’s any interest.

– Bob

Under Pressure

October 6, 2014

Antimatter principle, Management, Psychology

Organisational effectiveness, Rightshifting, Software development

Under Pressure

I don’t suppose anyone sets out to micromanage others. Not as in “I’ve got to tell this person what to do and how to do it every minute of the working day.” Yet, I see it – or something quite like it – happening most places I go. Of course, non-technical managers have more of a challenge in telling technical staff how to do technical things. But senior tech leads and technical development managers seem quite adept at that.

But I can relate to folks who feel under some kind of pressure to get results. And some empathy for those who believe – however mistakenly – that micromanaging is a viable way to see those results realised.

I can relate, because when in similar managerial or supervisory roles, I too have felt the pressure. More specifically, the lurking, silent pressure to act and behave in certain ways towards others.

I’ve been in Adhoc organisations where the pressure to fight fires all day every day was palpable. Where the owner’s unspoken expectations were that preparation, thinking ahead, and discipline were not worth the candle, and that firefighting was a perfectly normal and rational response to things going awry.

I’ve been in Analytic organisations where there was a constant pressure to coerce staff, to been seen to be using tactics like fear, obligation, guilt and shame to achieve “results”. Where the deleterious effects of such tactics were unknown or ignored. But knowing better, myself, only led to more pressure, as peers hinted at their “disappointment” that I treated people humanely, that I involved staff in decisions, that I took an interest in them – as individuals with needs.

In other words, the prevailing mindset in an organisation, manifest in the expectations of others, can lead inexorably to being micromanaged oneself. It doesn’t have to be managers that micromanage people. The most pernicious micromanagement can come from the pressures imposed by the system, and the way the work works.

“I’m not in this world to live up to your expectations and you’re not in this world to live up to mine.”
~ Bruce Lee

– Bob

Are You Sitting Comfortably?

October 5, 2014

Antimatter principle, Psychology

Are You Sitting Comfortably?

One aspect of effective knowledge work – such as software development, for example – that I rarely get to discuss is the meme related to “what is knowledge work like?”

In “First, Break All The Rules” by Marcus Buckingham and Curt Coffman, the Gallup organisation suggests there is a set of just twelve questions we might use to gauge employee engagement (and, by association, the organisation’s effectiveness and thus its prevailing mindset).

The second of these twelve questions is:

“Have I the materials and equipment I need to do my job right?”

In ad-hoc organisations, and some early-stage analytic-minded organisations too, folks tend to regard knowledge-work as synonymous with office work. In this meme, work is by definition rote and repetitive, and has little need for invention or innovative thinking, little need for collaboration.

In the majority of analytic-minded organisations, the meme is different. Here, folks regard knowledge work as something akin to the “software factory”, where a set of rules, or processes, when followed, results in predictable outcomes and required levels of quality and functionality. Work is regulated and constrained and factory-like.

In synergistic organisations, the meme is different again. Here, the idea of knowledge work as some kind of Design Studio holds sway. Folks see the work as needing collaboration, inventiveness, discussions, and so on.

And finally, in some late-synergistic and chaordic organisations, the Design Studio meme gives way to the idea of work as a set of value streams. Although the physical environment may look much the same as with the Design Studio meme, at least to the untutored eye.

Chairs

So where do the chairs come in?

I’ve seen it enough times to be able to intuit the kind of prevailing meme, and thus some indication of the prevailing collective mindset, through a simple observation of the physical workspace in which folks are working on a daily basis. Yes. I’m talking about the furniture.

Developers and other knowledge workers spend a lot of their time thinking, discussing and, yes, typing (amongst other things). Do these folks have the materials and equipment they need to do their job right? Is the workplace expressly optimised to enable folks to think well, discuss well, and type well?

The office-work meme lends itself to typing well. Not much else. And not for the long periods typical of developers. Where’s the care for folks’ health and well-being in many such workspaces?

The software factory fails to support any of these things, as far as I can see. Although maybe the managers believe it’s supporting their needs (hint: it’s not – at least not effectively).

The design studio kind of workspace serves to enabling thinking and discussing (at a marginal detriment to typing). Of course, its bohemian overtones are often offensive to the more widespread Analytic mindset.

And the value stream viewpoint, maybe supports all three. Note: I’ll not get into the relatively fine distinction between the value-stream perspective and the design studio perspective, here.

More generally, the organisation’s prevailing attitude towards effectiveness is reflected in the selection of furniture, the layout of the workspace, and other aspects of the materials and equipment available to support the workforce in their work.

Chairs – seating, in the broader sense – being the most instantly identifiable of these shibboleths.

Cheap office-style chairs indicate the office-work mentality, where either through ignorance or lack of concern, the workers’ productivity and welfare are of little import.

More expensive chairs – Aerons or some such – speak to some nascent awareness of the nature of knowledge-work, and concern for folks’ well-being.

An eclectic mix of “seating” – top-end desk chairs, bean bags, couches, standing- and walking-desks, and so on – can betray the Design Studio meme. (Although keep an eye out for tokenism, such as whacky kinds of seating – like balls and cushions – which may look funky but are ill-suited to actually sitting on for more than a few seconds.)

And the value stream meme can suggest seating carefully selected, and located – by the workers – and closely tied to the nature of the work at hand, at any given moment.

How’s your seating? What does it tell you about the prevailing attitudes to work, where you work?

– Bob

Quandary

October 4, 2014