Monthly Archives: April 2014

The Future Of Work

[Tl;Dr: Most people, and in particular managers, have yet to realise the nature of work has fundamentally changed, and that the old ways are catastrophic for collaborative knowledge work.]

I love living in the future. Folks think differently there. I find I’ve spent my entire career some 5-20 years ahead of the mainstream. That can be frustrating, of course. But honestly, I’d have it no other way.

Aside from a bunch of technology and business ideas – some implemented, some not – I’ve seen hundreds of organisations close up and personal. For as long as I can remember, I’ve been interested in the question “why is software development so broken, just about everywhere?”. In my journeys through these organisations, I’ve looked for clues which might furnish some kind of answer.

My sleuthing to date has led me to the hypothesis that most folks are unaware of a couple of things:

Software development work is not like classical “work” – it’s something new, something different.
It’s not irredeemably broken. Some very few organisations are quite effective at it.
Our most widespread mental models of work are catastrophically incompatible with this “new work”.

“The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”
~ Peter F. Drucker

It’s clear to me that the future of work is what Drucker called “knowledge work”. More specifically, collaborative knowledge work.

“What differentiates knowledge work from other forms of work is its primary task of ‘non-routine’ problem-solving that requires a combination of convergent, divergent and creative thinking.”
~ Reinhardt et al., 2011.

And what differentiates collaborative knowledge work is the involvement of some number – greater than one – of agents (read: people) involved together in tackling any given task. We may cling to the image of the lone mad scientist, but today the nature of the challenges we face as a species demand groups or teams of people working together.

The Robots Are Coming

Why is collaborative knowledge work the future of work? Because other forms of work – manual labour; repetitive, routine tasks, etc. – will become more and more the domain of the robots. Sure, that may yet take some time to happen. But the writing’s on the wall. And writ larger every day. Maybe one day Artificial Intelligence will be able to out-perform people even in non-routine, highly variable and intuitive tasks, too. Maybe AI-driven robots will become at least as – if not more – “human” (read: humane) companions and social collaborators than people. But that day, if and when it comes, is much further off. And distant not least because most of the work in making it happen is collaborative knowledge work and we’re just not doing very well at that, as a species (yet).

Still Living in the Past

Most organisations, and the people working in them, have a mental model of work dating back to the late nineteenth century. A model predicated on the coordination and oversight of a largely illiterate and uneducated workforce. A workforce mostly engaged in repetitive, routine manual, manufacturing, clerical or administrative tasks. The modern workforce has changed out of all recognition. Organisations and their methods patently have not.

Trends

And not only has the nature of the workforce undergone a sea change. So have folks’ expectations. A basic “living” is becoming ever less attractive to people. Especially in the relatively privileged West. People are looking for more from a job. More meaning. More self-determination. More opportunities to “discover themselves” and become all they can be. And the role of organisations in our societies is ever more closely scrutinised and challenged. “Productivity” for its own sake – or simply for the sake of making the rich richer – is no longer something that folks regard as unequivocally desirable. These are all trends that are not going away.

Maybe, in time, the whole concept of a “job” or working for a living will find itself consigned to the trashcan of history. Switzerland is already exploring some of the implications of this possibility, such as a guaranteed basic income for all citizens.

But for the immediate future, we work. So it seems to me that finding ways to make that a more convivial experience for all, makes some kind of sense. Not that we humans are very rational animals.

The Future Is Bright

People can change. Organisations can change. Not yet perhaps in large numbers, and not each, overnight. But slowly, by degrees. Most organisations today are still woefully ineffective in their approach to collaborative knowledge work. Hamstrung by wholly unsuitable mental models of work from the past, they hobble along doing the best they can under their burden of their outmoded assumptions.

But there are some few organisations that have transcended this toxic inheritance, and found ways to be much more effective – and to be much nicer places to work, too:

Few, indeed. But a few more, every day. There’s no reason why organisations have to be as lame as they are today, excepting our human fallibilities and lack of imagination.

It’s All Hidden

One key reason this state of affairs has come to pass is the very opacity of collaborative knowledge work. Observers (e.g. managers) not directly involved in the work have little visibility into what’s actually going on. And the ubiquity of collaborative knowledge work, like the situation of the metaphorical frog in slowly heated water, has come about barely imperceptibly, over many decades. Long enough that most folks have not (yet) noticed that the very nature of work has fundamentally changed.

“In the knowledge society the most probable assumption – and certainly the assumption on which all organisations have to conduct their affairs – is that they need the knowledge worker far more than the knowledge worker needs them.”
~ Peter F. Drucker

What We Might Learn

To paraphrase Betrand Russell:

“Most organisations would die sooner than understand knowledge work – in fact they do so.”

Is this wilful ignorance? I don’t see it that way. Rather, I see it as folks trying to get their needs met, through strategies familiar to them, without an awareness of – and confidence in – other strategies which could get those same needs met much more effectively. Their current strategies, predicated as they so often are on outmoded and inherited assumptions, are what leads to ineffective behaviours and disappointing outcomes.

The competition between Theory X and Theory Y (McGregor) is just one example of two strategies that different folks choose to get their needs met.

For those who are willing to consider alternative strategies for getting their needs met, and e.g. learn about collaborative knowledge work – what it is, the climate in which it thrives, etc. – what might they find? Here’s my list:

Cognitive function is a fragile thing, yet central to effective knowledge work (cf. Flow – Mihaly Csikszentmihalyi)
Skilful social interactions – and especially dialogue – are central to collaborative knowledge work (cf. Idea Flow – Pentland)
Power structures by their very nature are toxic to collaborative knowledge work
People like to work, are creative, seek responsibility and can self-direct and self-coordinate (cf. Theory Y – McGregor)
Mutual joy is the strongest – and naturally occurring – form of human motivation (cf. Nonviolence – Rosenberg)
Free play brings profound benefits (cf. Psychology – Scott G. Eberle, Stuart Brown, et al.)
Environment matters. Both the physical working environment and the “collaborative climate”. (Cf. Peopleware – DeMarco & Lister)
Intrinsic motivation is all – extrinsic, a non-starter (cf. Drive – Dan Pink)
95% of folks’ relative contribution is a function of the way the work works (cf. Deming)
Even the best, most engaged and talented workers can be defeated by “the way the work works”.

“Extrinsic reward systems have seven deadly flaws. They can undermine performance, creativity, good behaviour and intrinsic motivation, as well as encouraging short termism, unethical behaviour and become addictive.”
~ Dan Pink

Lots of people ask me “I’m not a senior manager or exec – what can I possibly do to contribute in some way to changing things for the better?”. Maybe one way forward is to empathise with how senior managers are, like everyone else, trying to get their needs met, but with outdated and unsuited strategies – and offer to introduce them to some new ideas.

– Bob

Flow, Shmo

April 29, 2014

Antimatter principle, General, Rightshifting

1 Comment

Flow, Shmo

We hear a lot from certain quarters about the benefits of flow – i.e. of value, through eg a value chain, or network, of suppliers to eg customers. I myself have written about it on occasion. And I even had the job title of Head of Product Development Flow, last year.

As a guideline for the initiated, this can work. See: the Lean Decision Filter.

But, as I wrote more recently, the Antimatter Decision Filter illustrates how flow, and even value, comes some way down the list of what matters to most people.

And all this finagling around flow (or value, or even needs, for that matter) is moot to the point of utter batshit irrelevance to most folks out there in businessland and beyond.

So what does matter to people? Don’t ask me. Why not ask them?

– Bob

Eight Ways Customer Value is Killing Your Business

April 28, 2014

Antimatter principle, Organisational effectiveness, Rightshifting

10 Comments

Eight Ways Customer Value is Killing Your Business

Tl;Dr – A blind faith in the idea of “customer value” can cause many more problems than it solves.

Some folks seem to believe in “customer value” like it was the New Church.

The idea appears to have transcended logical enquiry and consideration, and become some kind of sacred cow. So be it. I do not subscribe. I guess that makes me an apostate.

My view? I see organisations that focus on customer value putting their business in jeopardy. Of course, there are numerous other ways to do that, too. But this particular path seems deeply ironic, given the number of self-styled experts who hail “customer value” as the salvation of business.

So, here are eight ways in which an incautious and credulous emphasis on “customer value” can undermine business success:

If you don’t mean it
What about everyone else?
Narrow definition of “Customer” and “Value”
Confusion of Value Disciplines
Unintended Consequences
Choosing the Wrong Kind of Value
Conflating means with ends
Strangles Innovation

1. If You Don’t Mean It

Is your organisation just striking a pose with regard to caring about delivering value to its customers? If so, they will find you out soon enough, and quickly spread word of your duplicity far and wide. Poor service and/or product quality is the norm in most businesses today, but pretend that you’re different when you’re not, and the backlash increases dramatically. More than the effect on disaffected customers, consider the effect on staff, too. How long can they go on living a lie? How will their chagrin affect their attitude to customers?

Aside: Becoming really customer-focused demands fundamental changes in organisations – in their collective mindsets, in their structures and in their daily actions. I’d go so far as to say that it’s a challenge far beyond the capacity of the Analytic mindset.

2. What About Everyone Else?

When a business truly places its customers on a pedestal, other stakeholders typically suffer. Employees and their issues get short-changed, managers are overworked or trapped in continual fire-fighting, and other stakeholders similarly lose out. Disaffection in key stakeholder groups, especially front-line employees, leads to a poorer customer experience, too. How about considering the value of balance, rather than unilateralism? How about attending to everyone’s needs?

3. Narrow Definition of “Customer” and “Value”

Who do you regard as your customer? How do you decide what is of value to them? Do you define customers as (just) those folks that sign the cheques? And do you define value in terms of simple hard cash? If so, what about all those other folks who suffer your goods and services without a voice? And what about their (non-cash) experiences?

4. Confusion of Value Disciplines

Michael Treacy and Fred Wiersma describe three generic value disciplines: operational excellence, customer intimacy and product leadership in their book The Discipline of Market Leaders (1997). They go on to make the case that any given business can and must focus on just one out of these three disciplines. Many organisations have yet to realise this.

5. Unintended Consequences

In his book “Obliquity”, Alan Kay makes the case for approaching one’s goals obliquely. Rushing headlong at “customer value” can often result in many unintended consequences. A more indirect approach, such as providing value to customers by building an organisation or workforce with the capability to do so “baked-in”, and evolving continuously, can avoid many of these unintended consequences.

6. Choosing the Wrong Kind of Value

There’s a story about Frank WIlliams and his Williams Formula One team. When any of his engineers came up with a modification to the car he would ask “does it make the car go faster?” Some folks cite this as an example of excellence of focus, and a great heuristic or metric (how much faster will the car go). But in Formula One, having a faster car is not necessarily the optimal strategy, all things considered. Better questions might be “will we win more races?”, “will we take the Championship?”, or even “will we get more sponsorship?”. If you give folks a goal, they’ll strive to meet it, even when it’s the “wrong” goal. Even when it destroys the company. And how likely is it that, even if senior managers do choose the “right” kind of customer value, folks across the organisation will understand and deliver on that?

7. Conflating Means With Ends

In his book The Goal, Eliyahu Goldratt asks the fundamental question “Why are you in business? What’s your goal?” Having happy customers is a means to a commercial organisations’ goal, not an end in itself. Yes, even a necessary means (see: Necessary But Not Sufficient). But not sufficient.

8. Strangles Innovation

Focusing blindly on customer value can drive short-termism in the organisation, because the connection between longer-term investment in e.g. innovation and the customer value of such proposed innovations is often hard to see.

I hope this piece has provided you with some food for thought. Maybe even… some value?

– Bob

Acknowledgements

My special thanks to @drunkcod for his valuable contributions to this post.

Can We Imagine?

April 20, 2014

Fellowship, Management, Organisational effectiveness, Rightshifting

5 Comments

Can We Imagine?

Can we imagine alternatives to conventional management? Different ways of coordinating organisations, large and small?

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

Of course there are constraints on what we can do right now to improve the fundamentals of how we coordinate and direct our organisations. But if we can’t even imagine other ways, better ways, then what does that say about our imaginations?

As a starter for ten, here’s a comparison of just three alternatives for coordinating our organisations:

Different Forms of Organisational Coordination
Conventional Management	Vs.	Lean Management	Vs.	Fellowship
Authority	Vs.	Responsibility	Vs.	Mutuality
Results	Vs.	Process	Vs.	Relationships
Give answers	Vs.	Ask questions	Vs.	Make refusable requests
Plans	Vs.	Experiments	Vs.	Conversations
Formal education	Vs.	Gemba learning	Vs.	Mutual exploration
Specialists own improvement	Vs.	Line manager and teams own improvement	Vs.	Those doing the work own improvement
Data-based decisions made remotely	Vs.	Facts-based decisons made at the gemba	Vs.	Decisions made together
Standardisation by specialists	Vs.	Standardisation by manager and team	Vs.	Standardisation by team
Go fast to go slow	Vs.	Go slow to go fast	Vs.	Play
Vertical focus	Vs.	Horizontal focus	Vs.	People-as-individuals focus
Fixed mindset (cf Dweck)	Vs.	Growth mindset	Vs.	Mutuality mindset
Extrinsic motivations	Vs.	Intrinsic motivations	Vs.	Mutual joyfulness
Violence	Vs.	Respect	Vs.	Nonviolence
Imposed or opaque purpose	Vs.	Shared (static) purpose	Vs.	Mutually-evolving purpose
Key decisions made by a few	Vs.	Key decisions made by a few	Vs.	Key decisions made by consensus of all
Economics of Cost	Vs.	Economics of Flow	Vs.	Economics of Joy

What other forms can you imagine?

– Bob

Objectives, Proclaimed vs Practised

April 18, 2014

Agile, Engineering, Leadership, Organisational effectiveness, Product development, Rightshifting, Software development

3 Comments

Objectives, Proclaimed vs Practised

Tl; Dr: Most organisations do software development not for the outputs, but to satisfy the members of the core group, whose needs are pretty much entirely disconnected from both software quality and the evolution of an effective development organisation.

Mistaken Beliefs

“Discrepancies between objective proclaimed and objective practiced can be observed in most organizations. For example, one could mistakenly believe that the principal objective of universities is to educate students. What a myth! The principal objective of a university is to provide job security and increase the standard of living and quality of life of those members of the faculty and administration who make the critical decisions. Teaching is a price faculty members must pay to share in the benefits provided. Like any price, they try to minimize it. Note that the more senior and politically powerful teaching members of the faculty are, the less teaching they do.”
~ Russell L. Ackoff

So To Software Development

One could mistakenly believe that the principle objective of e.g. software houses and other software-producing organisations is “working software”. What a myth! The principle objective of such businesses is to provide job security and increase the standard of living, positive self-image and quality of life of those in the core group of these organisations, and provide sufficient (read: minimum) income, entertainment and other such “attractions” necessary to retain the continued attendance of the rest of the workforce. “Frontline” work such as coding, testing, designing, decision-making, etc. is a price core group members must occasionally pay to share in the benefits provided. Like any price, they try to minimise it. Note that the more senior and politically powerful the core group member, the less frontline work they do.

The Core Reason For Lameness

Here we have one answer to the question “Why are software products generally so lame?”. Note: we could also phrase this as “why does the practice of software development generally result in outputs (software, products) with such limited positive impacts (outcomes) for anyone but members of the core group?”. Or more bluntly: “Why does no one ever seem to care that we’re just continually churning out crap?”.

Just like universities, where the positive outcomes for students are more or less limited to a handy, albeit increasingly expensive qualification, in software development positive outcomes for customers and workers are more or less in the lap of the Gods (or the members of the core group, which we may choose to regards as synonymous).

– Bob

Can You Use A Scrum Master?

April 16, 2014

Agile, Coaching, Management, Organisational effectiveness, Rightshifting, Software development

9 Comments

Can You Use A Scrum Master?

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

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

Fools Rush In…

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

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

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

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

“What flavour of Agile?”

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

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

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

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

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

Scrum is a Thing

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

Scrum Can be Mandated

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

The Scrum Master is a Management Appointee

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

The Scrum Master Is a Trainer

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

Change is Bounded to the Dev Teams

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

The Problems are Known Beforehand

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

Hire and Forget

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

All Scrum Masters Are Much of Muchness

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

The Individual Can Trump the System

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

The Scrum Master is an Interim Hire

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

The Scrum Master is a Management Patsy, Stooge or Dupe

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

Scrum Masters Are Selfless

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

Summary

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

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

Good luck!

– Bob

Code Refactoring

April 15, 2014

Agile, Antimatter principle, Software development

7 Comments

Code Refactoring

Don’t ask me why I’m writing this post. It’s bound to get me into trouble.

Anyways…

What Is Refactoring?

Code refactoring (according to me) is taking a piece of code, code that is already working, and revising it – typically in small steps – to make it more readable, more efficient in execution, or otherwise “better” in one or more ways. Folks expect that such pieces of code will exhibit the same (unchanged) behaviour before and after refactoring.

Aside: This “invariant behaviour” itself seems arguable, as in practice many refactorings leave the code with different “-ilities” (non-functional characteristics – for example, execution efficiency). I suggest claims for such equivalence (of behaviour) are, in general, bogus. “Passes the same tests” is not a great yardstick – how many teams have a suite of tests checking all “-ilities”?

Refactoring is Waste

Given that the piece of code in question is already working, then doing more work on it could be construed as waste (i.e. not adding any value). But hang on. There’s more to it than this.

Firstly, “working” is a relative term. In the Antimatter Principle vernacular, “working” means “meeting some folks’ needs, to some extent”. We can always meet folks’ needs better. So the question then becomes, “when to stop?”. When is any piece of code “good enough”? We can really only answer this question when we have some general understanding of what “good enough” means, for each and every person involved.

Aside: How does your team go about soliciting and sharing information on what “good enough” means?

Why Not Make It Right First Time?

Well, there are some valid reasons. Cognitive load perhaps being the most relevant. Many coders just can’t always get their head around every aspect of the code they’re writing, all at the same time. Many find it necessary, at least sometimes, to defer some considerations – such as performance or readability – until they’re got something roughly “working”.

And then there’s the question of coders’ competence, and intellect, as well as the working environment and coders’ states of mind, from moment to moment.

So, for many coders, right-first-time is just beyond their present capability-in-the-moment.

All this doesn’t change the basic fact that refactoring is waste (muda, in japanese). It does beg the question, though, as to whether it is type I or type II muda:

Type I muda: Non-value-added tasks which seem to be nevertheless necessary.
Type II muda: Non-value-added tasks which can be eliminated immediately

Why Bother with This? Isn’t it a Storm in a Teacup?

My ha’penn’orth: If we choose to regard refactoring as muda, then we have our eyes open to reducing it, to writing better code on our first attempt, learning and finding other, less wasteful means to meeting folks’ needs, and getting progressively better at our craft. If we choose to see refactoring as part of our regular toolkit of practices, we may be less inclined to search for better ways, and more inclined to just live with it.

And, honestly, the whole “what is waste” question from the Leanheads seems contrived and mostly arbitrary when it comes to drawing a waste/no-waste line. IMO there’s not so much a clean line as a broad and fuzzy overlap between what is and what isn’t value-adding, especially when one considers the needs of all stakeholders, and not just the needs of the “customer”. See also “What is value”.

– Bob

Postscript

[29 March 2015]

What is “good enough”? Generally, when the stakeholders each say “that’s good enough for me”. And how might we get to such a point? By showing them stuff, allowing them to play with it, work with it, and seeing to what extent what we have given them, to date, meets their needs.

Given we may from time to time give them stuff they’re not so happy with, and choose to try again, I’m minded to ask “how can we minimise the effort and investment in each ‘candidate release’ whilst maximising the relevance of said release?”.

Core Practices for the Antimatter Principle

April 14, 2014

Antimatter principle, Community, Organisational Therapy

2 Comments

Core Practices for the Antimatter Principle

When presenting the Antimatter Principle, some folks have suggested that it might help meet their needs for me to also present some ideas on how to go about applying it. In other words, some core practices.

I guess it’s the curse of the expert that makes me wonder how this could be useful, given it’s so obvious to me how to apply it (not least, having done so for the past eighteen years or more). After all, what’s so difficult about asking folks what their needs are?

I do feel uneasy about giving people “advice” – in the form of recommended practices – too. I find folks have an enormous potential for coming up with their own ideas – ideas much better suited to their own needs and contexts – given half a chance.

“When it comes to giving advice, never do so unless you’ve first received a request in writing, signed by a lawyer.”
~ Marshall B. Rosenberg

And, of course, there’s a huge body of work in Marshall Rosenberg’s Nonviolent Communication which can help with having productive dialogue focussed on attending to folks’ needs.

Anyways, before I put some time into explaining some relevant practices, I’d like to ask you, dear readers, whether you have any practices you use that might serve the Antimatter Principle? Would you be willing to contribute by means of a comment, a post on your blog, or even a guest post here? I’d be happy to collaborate to help you do so. I make a special plea to the Rightshifting Community in this regard.

Aside: For one of my own core practices – about which I’ve already written – see the post “Nonviolent Project Management”, which includes an example of said practice: “Stakeholder and Their Needs”.

– Bob

Vital Conversations

April 11, 2014

Antimatter principle, Conferences, Dialogue, Psychology

5 Comments

Vital Conversations

I was keynoting on the Antimatter Principle at Agile Adria 2014 this week. As at all of the other conferences I have attended in the past year or so, I found myself feeling impatient with e.g. the hallway and dinner-table conversations, because I was feeling less connected with people than I would like. I also often feel that, amongst so many energised and experienced folks, we could be having great conversations of mutual exploration and import. Vital conversations – conversations full of energy, and life, and mutual joy. Yet we don’t seem to be able to make that happen.

At each conference, I’ve shared my feelings with one or two folks, without much in the way of ideas coming to mind.

This morning, I find an oh-so-simple idea has been staring me in the face, unrecognised, for months.

I’m speaking of this passage from an interview with Marshall Rosenberg:

SARAH: I was interested in an example you shared in one of your workshops about a group of teachers who were having a conversation that wasn’t feeding you spiritually.
MARSHALL: “Well, I was sitting around with a group of teachers who were all talking about what they did on vacation. Within ten minutes, my energy had dropped very low; I had no idea what people were feeling or wanting.
“In giraffe, we know it’s not being kind to the other person to smile and open your eyes wide to hide the fact that your head has gone dead. The person in front of you wants their words to enrich you, so when they aren’t, it’s helpful to be kind and stop them. Of course, in the jackal culture, this isn’t done.
“After listening awhile to the teachers, I screwed up my courage and said, “Excuse me, I’m impatient with the conversation because I’m not feeling as connected with you as I’d like to be. It would help me to know if you’re enjoying the conversation.” All nine people stopped talking and looked at me as if I had thrown a rat in the punch bowl.
“For about two minutes, I thought I’d die, but then I remembered to look at the feelings and needs being expressed through the silence. I said, “I guess you’re all angry with me, and you would have liked for me to have kept out of the conversation.”
“The moment I tumed my attention to what they were feeling and needing, I removed their power to demoralize me.
“However, the first person who spoke told me, “No, I’m not angry I was just thinking about what you were saying. I was bored with this conversation.” And he had been doing most of the talking! But this doesn’t surprise me. I have found that if I am bored, the person doing the talking is probably equally bored, which usually means we’re not talking from life; we’re acting out some socially-learned habits.
“Each one of the nine people then, expressed the same feelings I had – impatience, discouragement, lifelessness, inertia. Then one of the women asked, “Marshall, why do we do this? Why do we sit around and bore each other? We get together every week and do this!”
“I said, “Because we probably haven’t learned to take the risk that I just did, which is to pay attention to out vitality. Are we really getting what we want from life? Each moment is precious, so when our vitality is down, let’s do something about it and wake up.”

So, I now have a new avenue to pursue the next time I find myself feeling frustrated, impatient or disconnected. I’ll just have to remember to say something like:

“Excuse me, I’m impatient with this conversation because I’m not feeling as connected with you as I’d like to be. It would help me to know if you’re enjoying this conversation.”

Do you sometimes have the same feelings? How might this approach help you in similar circumstances? Could you find the courage to make such an interjection? How might you feel – and react – if someone else said something like this, to you?

– Bob

Dukkha

April 5, 2014

Antimatter principle, Organisational effectiveness, Rightshifting

1 Comment

Dukkha

“I have taught one thing and one thing only, dukkha and the cessation of dukkha.”
~ The Buddha

Buddhists regard The Truth of Dukkha as the first of the Four Noble Truths, and often explain it in terms of three categories:

The obvious physical and mental suffering associated with birth, growing old, illness and dying.
The anxiety or stress of trying to hold onto things that are constantly changing.
A basic unsatisfactoriness pervading all forms of existence, because all forms of life are changing, impermanent and without any inner core or substance. On this level, the term dukkha indicates a lack of satisfaction, a sense that things never do and never will entirely measure up to our expectations or standards.

In my journeys through organisations large and small, I have seen much dukkha. Many organisations ill-at-ease with themselves, and with their situations. I guess it’s part of the human condition, as expressed through life in organisations. In other words, dukkha is part of the fundamental nature of our phenomenal world, including our organisational “worlds”.

“Such is dukkha. It can be fully known. It has been fully known.
Such is craving. It can be let go of. It has been let go of.
Such is cessation. It can be experienced. It has been experienced.
Such is the path. It can be cultivated. It has been cultivated…
Only when my knowledge and vision was clear in all these ways did I claim to have had such an awakening.”
~ Gautama Buddha

We can read this presentation of the Four Noble Truths as a series of cause-effect relationships. By fully knowing dukkha, we can release craving. By releasing craving, we can experience the cessation of craving. And when we are no longer in the grip of craving, we have the freedom to cultivate the Path.

I might explain dukkha from the organisation’s perspective in terms of three categories also:

The obvious physical and mental suffering associated with start-ups, growth, crises, mergers, downsizings, and death (of the organisation).
The anxiety or stress that folks in the organisation collectively feel when trying to hold onto things that are constantly changing (a near-universal phenomenon in most organisations).
A basic unsatisfactoriness pervading “the organisation”, because everything is in some way always changing, impermanent and without any inner core or substance. People come and go. Product lines and products change. Methods and tools evolve. Priorities and markets change. And so on.

“Buddha Dharma does not teach that everything is suffering. What Buddhism does say is that life, by its nature, is difficult, flawed, and imperfect. From the Buddhist point of view, this is not a judgement of life’s joys and sorrows; this is a simple, down-to-earth, matter-of-fact observation.”
~ Surya Das

Maybe if you’re stressed at work, some consideration of the Truth of Dukkha, and the Buddhist approach to addressing dukkha, may offer some insights, and those, in turn, some comfort?

Aside: Not attending to one’s needs is also dukkha. As is attending to folks’ needs.

“What ordinary folk call happiness, the enlightened ones call dukkha.”
~ The Buddha

– Bob

What Are Values?

April 2, 2014

Agile, Antimatter principle, Psychology

5 Comments

What Are Values?

No, not “What Is Value?”. I already did that. 🙂

Rather, what are “values”. As in e.g.

“Agile is much more a set of values than a set of practices.”
~ Andrew Binstock

I guess different folks have many different conceptions of “values”. Before my Road to Damascus experience with Nonviolent Communication, I probably would have described “values” using terms like “moral values”, ethics, good-and-bad, right-and-wrong, and so on.

But now, having seen The Light, here’s how I’m using the term:

Values are what drives us to choose – often subconsciously – one particular strategy for getting our needs met from a range of possible strategies. We choose a particular strategy because of how we feel about it. If we feel more comfortable with a particular strategy, we’re more likely to choose it over other strategies with which we feel less comfortable.

Note that this has little to do with rational thought, such as a logical evaluation of the relative merits of the chosen strategy – whether it might work well for us, whether it might best serve us in getting our needs met.

We sorry humans often choose suboptimal strategies (understatement!). Suboptimal strategies which fail to get our needs met, or even actively work against us getting our needs met. We might choose to say that we do this because we are following our “values”. BTW Chris Argyris refers to this as our “theories in use”.

Agile Values

So when folks talk about “Agile values”, for me this implies a certain set of strategies for attending to the individual and collective needs of the folks in a team – as well as the needs of the higher-ups, customers, etc.. Often, these strategies are very different from those strategies more widespread in the team’s containing (parent) organisation. We might hear folks describe this in terms of different – and competing – “value-systems”.

FWIW I more often describe this as a clash of mindsets. I don’t see the differences in nomenclature – mindsets vs memeplexes vs value-systems – as being very material in this context.

Of course, “Agile values” are an attempt to share – and encourage the adoption of – strategies that some luminaries in the software development community believed (circa 2001) are more likely to get folks’ needs met than some other strategies – for example, those implicit in “traditional business value-system” a.k.a. the Analytic Mindset.

How does this all fit with your values?

– Bob

The Future Of Work

The Robots Are Coming

Still Living in the Past

Trends

The Future Is Bright

It’s All Hidden

What We Might Learn

Further Reading

Share the joy :)

Flow, Shmo

Further Reading

Share the joy :)

Eight Ways Customer Value is Killing Your Business

1. If You Don’t Mean It

2. What About Everyone Else?

3. Narrow Definition of “Customer” and “Value”

4. Confusion of Value Disciplines

5. Unintended Consequences

6. Choosing the Wrong Kind of Value

7. Conflating Means With Ends

8. Strangles Innovation

Acknowledgements

Further Reading

Share the joy :)

Can We Imagine?

Share the joy :)

Objectives, Proclaimed vs Practised

Mistaken Beliefs

So To Software Development

The Core Reason For Lameness

Further Reading

Share the joy :)

Can You Use A Scrum Master?

Fools Rush In…

Scrum is a Thing

Scrum Can be Mandated

The Scrum Master is a Management Appointee

The Scrum Master Is a Trainer

Change is Bounded to the Dev Teams

The Problems are Known Beforehand

Hire and Forget

All Scrum Masters Are Much of Muchness

The Individual Can Trump the System

The Scrum Master is an Interim Hire

The Scrum Master is a Management Patsy, Stooge or Dupe

Scrum Masters Are Selfless

Summary

Further Reading

Share the joy :)

Code Refactoring

What Is Refactoring?

Refactoring is Waste

Why Not Make It Right First Time?

Why Bother with This? Isn’t it a Storm in a Teacup?

Postscript

Share the joy :)

Core Practices for the Antimatter Principle

Share the joy :)

Vital Conversations

Share the joy :)

Dukkha

Further Reading

Share the joy :)

What Are Values?

Agile Values

Further Reading

Share the joy :)