Monthly Archives: August 2014

The Antimatter Pattern


Some fifteen years ago now, patterns seemed like they might become a widely adopted way of capturing and sharing knowledge and know-how. It also seems like they never really caught on in the software development field.

Personally, I still find them useful for organising and recording my own thoughts, and, occasionally, for sharing those thoughts with others. This post presents the StartingTheWheelOfChange pattern, which proposes the Antimatter Principle as a solution to one of businesses’ most widespread and seemingly intractable of problems:

Problem: How to create a climate, context, or situation in which folks will want to change their behaviours to the benefit of all.

What Is A Pattern?

A pattern is the formalization of a problem/solution pair, potentially useful in making design decisions. The purpose of a pattern is to codify existing design knowledge/experience so that folks can avoid constantly re-inventing the wheel. Also, by naming such patterns, people can more easily reference and share them. The term pattern was first popularised by the architect Christopher Alexander working in the fields of e.g. building design and town planning.

Some folks refer to collections of patterns – relating to a common domain or discipline – as Pattern Languages. My interest these days is primarily in Pattern Languages for business management and organisational improvement.

My Pattern Form

Most of the patterns I’ve written over the years have shared a common form. You can see an example of this form in the StartingTheWheelOfChange pattern which is the subject of this post. Briefly, this form starts with a header, and then has the following various sections below that:

  • Context: The context(s) in which the pattern might be relevant.
  • Problem: The problem this pattern purport to solve.
  • Forces: The forces at play in the problem domain described by the problem and context sections. Sometimes also known as the trade-offs.
  • Solution: The solution which proposes to solve the stated problem, in the stated context, and resolving the stated forces.
  • Examples: One or more practical examples taken from the author(s)’ personal experience in applying the solution to real-world instances of the stated problem.

Starting The Wheel of Change

The StartingTheWheelOfChange pattern suggests a solution to the question of “How to encourage widespread learning and improvement in a community such as a for-profit organisation. The full pattern is presented as a pdf.

– Bob

No Projects

The idea of “projects” in software and product development is a glaring anachronism, traceable back to the days when organisations saw each new project as “the last one we’re ever likely to run”. Absent the expectation of ever running another project, why bother moving to a more continuous, flow-based (non-project) set-up?

And of course, the idea of breaking things down into parts, and managing those parts separately, is another glaring anachronism, and one still grasped so tightly by those of the Analytic mindset.

But even the briefest of reflections about the nature of development work in organisations reveals a simple truth: just about every organisation today has a more or less continual flow of work – of new ideas transforming into products, of concepts becoming cash revenue generators.

I won’t dwell further here on the case for #NoProjects – Grant made the case quite well in his piece “What’s Wrong With the Project Approach?”. Maybe you’d like to consider the relative (dis)merits of “projects” – compared to what?

May I just invite you to consider whether there may be other, maybe better ways of getting folks’ – and organisations’ – needs met?

And, by the by, offer up FlowChain as a simple – and complete – example of what I’m talking about in terms of one such better way.

– Bob

Five Ways Agile Governance Can Help You Have More Fun

“Governance” is a scary word isn’t it? Few people could tell you what it means. And “Agile Governance” sounds, well, just wrong. A classic oxymoron.


Governance” in its broadest sense means “to steer” (from the Greek: kubernáo).

Corporate Governance” generally refers to the set of processes, customs, policies, laws and institutions through which people direct, administer, control and “steer” a corporation.

Information Technology (IT) Governance” generally refers to the connections between business focus and IT management. The espoused purpose of IT Governance is to assure the business’s investment in IT generates business value and to mitigate the risks that are associated with IT projects.

Agile Governance“, then, on the surface at least, means assuring the business’s investment in IT generates business value, and mitigating the risks that are commonly associated with Agile ways of working.

A Slam Dunk

So that’s a lot of what Agile’s about anyways, isn’t it? Making sure projects generate business value, especially early and often, and mitigating the risks associated with e.g. software development? So if we do Agile “properly” (I mean, in accordance with its principles, rather than just “by the book”), we’re pretty much home and dry, aren’t we?

Five Ways

Home and dry? Pretty much.

Agile Governance might sound like a lemon – but as the old saying goes

“When life gives you lemons, make lemonade.”

~ Elbert Hubbard

There are some things we can choose to focus on which makes our “Agile Governance” more fun – and more effective, too:

  1. Focus on value.
    I see many developers and teams get a kick out of delivering things to customers – things that those customers really prize. Making their lives easier, taking aways some pain, saving some time or effort, reducing mistakes. That kind of thing. Even better, focus on needs. Then we don’t have to guess what “valuable” things actually meet folks’ needs. Less wasted effort – a.k.a. doing what’s actually needed – can be a source of fun, too – at least in a less-daily-crap kind of way. Using hypotheses in lieu of “requirements” can also help here.

  2. Share in the common purpose.
    It’d be nice even to know what the business sees as the purpose of the company. Better yet – and fun for some – is being involved in elaborating and evolving that common purpose. Folks like a say in WHY they’re doing something.

  3. Be in charge of the way your own work works.
    Nobody enjoys being micro-managed. Who knows better just how to do some specific task than the person – or people – doing it? That’s much more fun than being told. Explain to those who would rule over you how being able to do it your way makes for more fun all round. And more productivity too, by-the-by.

  4. Get good at stuff.
    Doing stuff gets to be less and less fun after you’ve done the same stuff a couple of times. But getting better at doing stuff, learning more about how to do stuff and improving one’s own capabilities, skills and know-how. That’s fun for most people. Find ways to build time into the schedule to practices, learn and reflect – both individually, and with others.

  5. Get to make a difference.
    Developers and the like can get an unimaginable (to others) amount of satisfaction (a.k.a. joy, fun) out of feeling that they’re making a real difference. Having folks recognise this difference-making on a regular basis – maybe via celebrations, ceremonies, cake, or even a regular simple expression of thanks – can be incredibly uplifting.

Governance being fun? That seems an oxymoron in itself. But apply these five ways, and you’ll find it’s much more fun than you might have thought.

– Bob

What’s A Manager To Do?


Following on from my previous post, Six FAQs from managers in knowledge-work organisations, I thought I’d explore some options managers do have for making work work better.

The Number One Rule

We can’t change people, and trying to do so will only ever have negative outcomes.

The Number Two Rule

We can’t change people, but we can change things such that people’s behaviours may change.

The Number Three Rule

Folks see through all attempts to change things simply to manipulate them and their behaviours.


So where does that leave us, when we see behaviours we regard as unhelpful, dysfunctional or otherwise undesirable? Stand by and let the human dynamics play out? Or find some viable options which don’t involve trying to change other people?

Here’s some options I’ve found useful over the years, and which you might like to consider:

Change Yourself: We can’t ever change other people; we can only change how we respond to them. By changing our responses, we can model the kinds of behaviours we’d like to see in others. “Be the change you want to see in the world”. Some folks will pick up on this, particularly in the typical hierarchical organisation, where folks watch the behaviours of their higher-ups intently and constantly for behavioural cues.

Change the way the work works: Change the way the work works (the system) and behaviour change comes for free. Mindful of the Number Three Rule, you might like to consider the consequences of involving people (i.e. the workforce) in deciding how the work works, what to change and what to change to.

Change the environment: Change the physical environment (office layout, office spaces, furniture, seating arrangements, etc.). Change the places work is done. Change the hours. Change the nature of the social – and employment – contract. Change the tools. Again mindful of the Number Three Rule, you might like to consider the consequences of involving people in deciding how they’d like their environment(s) – in the broadest sense, as describe here – to be.

Explore folks’ theories of change: Everyone has different assumptions about how change happens, what’s possible, what works and what doesn’t, how people respond to change, how to effect change, and so on. Most times, these assumptions go unexplored and untested. Consequently, finding a consensus on how to change, a consensus which folks can share and buy into, rarely happens.

Change the facts: No, not a plea for fake news – but you can gather data where none existed before. Share data. Make things visible. Give people information – and support them in collecting their own –  where there has been little or none before. Choose which facts to focus on.

Make refusable requests: Explain how you’re feeling, the needs you have driving those feeling, and simply ask people to behave differently – in specific ways. This can, of course, be difficult in relationships with an imbalance of power, where requests, however enlightened and refusable, can be taken as coercion.

Suspend Judgement: Refrain from moralistically judging people and thereby wishing they would behave differently. Yes, maybe things would be better for all concerned if a certain person behaved differently in certain situations, but that doesn’t make that certain person a bad person.

Change the nature of your relationships: Do you use e.g. Fear, Obligation, Guilt and Shame to coerce or otherwise attempt to control people into behaving in ways you regard as “appropriate”? Maybe if you found other ways of relating to people, things might be different?

Even though you can’t change people, these and other options do exist, and can help bring about the changes you seek. Are you willing to be open and honest about those – both with others and with yourself?

– Bob

Further Reading

Culture Change Is Free ~ John Seddon
Tiny Wisdom: The Relationships We Wish Would Improve ~ Lori Deschene
What You Can Change And What You Cannot ~ Leland R. Beaumont
You Can’t Change Others: Letting People Be ~ Lauren Suval


Six FAQs

Questions I’m frequently asked about software and product development organisations.

Q1: How can we motivate our workers?

A1: You can’t. Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

Q2: How can we change the organisation’s culture?

A2: You can’t. Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that.

Q3: How can we change the mindset of managers?

A3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

Q4: How can we get teams to take responsibility?

A4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

Q5: How can we get managers to trust their teams?

A5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

Q6: How can we develop people’s competencies?

A6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

In a nutshell, the direct answer to all the above questions is: you can’t. But you can do one thing to make progress on all these questions: consider the Antimatter Principle.

Are you willing to be that radical? For that is what it boils down to.

“We can’t solve problems by using the same kind of thinking we used when we created them.”

~ Albert Einstein

– Bob

Further Reading

The Art And Science of Changing People Who Don’t Want to Change ~ Reut Schwartz-Hebron

A Faster Workstation


Like many things, the Antimatter Principle appears easy to understand, and, to me, even easier to misunderstand.

What could be easier as a coherent and comprehensive set of guiding principles than “attend to folks’ needs”, right?

And as a starting point, seeing folks actively engaged in attending to folks’ needs, any needs, makes my happy.

Digging Deeper

One of my needs is to help folks realise more and more of their innate potential – to use the old cliche “to become all that they can be”. And so I’m happy when seeing folks getting progressively more and more out of the Antimatter Principle.

As an example, consider this scenario:

Scenario 1a

A developer says “I need a faster workstation”. Sounds very straightforward. In many cases this might trigger defensiveness and/or analysis on behalf of the person who has to write and/or sign the purchase order. Setting aside this can of worms for the moment, let’s suppose we can get past this and the developer gets their new, faster workstation. Joy! Of a sort.

Let’s run through this scenario again. But this time we’ll take just a little more time and effort in the hope of maybe uncovering some deeper needs.

Scenario 1b

A developer says “I need a faster workstation”. Someone hearing this – at least, someone who is tuned-in to attending to folks’ needs – might respond with a question like “I guess you’re feeling stressed about not getting stuff done?” (NB Empathising).

Let’s follow a possible evolution of this dialogue:

“Sure am”.

“How’s your workstation for speed at the moment?”

“Well, I’m working on a Clojure module and the REPL startup times are interrupting my train of thought.” (Observation)

“I could get much more done if my workstation was faster.”

“So, how do you feel about that?”

“Quite frustrated, actually. I know folks are waiting on this module, and I feel like I’m letting them down.” (Feelings)

“Sounds like you have a need that’s not getting met?

“Yes. I guess I have a need to be seen as reliable and diligent and competent, and sharing in the customer-focus values of my team.” (Needs)

“So, needs for appreciation and belonging?”

“Yes. Sounds plausible.”

“I’ll go and ask Leslie about getting a new workstation and see what’s possible.” (Refusable request)

Let’s assume the basic outcome remains the same – our developer gets their new, faster workstation.

In this case, they’re still likely to find joy in being able to work faster, or more productively, or whatever. But it’s also possible that they might find much more joy in the situation, realising via the earlier dialogue that their needs for appreciation and belonging are what’s really better in their life. Not to mention the joy accruing to the person who helped them through the dialogue.

How do you feel about this? Does the explanation meet any of your needs?

– Bob

Further Reading

Words That Work In Business ~ Ike K. Lasater

Antimatter Workshops

No, this post is not about workshops on the topic of the Antimatter Principle – although I’m happy to discuss with you the possibility of conducting one with your team, group, or company.

And it’s definitely not about workshops on the topic of Antimatter.

This post is about using the Antimatter Principle to create better workshops – on any topic.

I’ve been to more than my fair share of workshops and the like over the years, and I’ve never been to one that was worth even the time it required to attend, let alone the cost in terms of hard cash. No, wait. Let me restate. I’ve never been to a workshop that was worth the time for the learnings it provided. I have been to many workshops where the social dimension – getting to meet people, doing things in concert, sharing a common interest, etc. – has been wonderful.

I don’t think it’s just me, either.

Aside: This post is about workshops, that is, events where groups of people come together, bounded by time, space and subject matter, ostensibly to learn together by doing. I contrast this with “training”, where the doing element is mostly conspicuous by its absence. I have no enthusiasm at all for the idea of training per se.

Workshops, at least, I feel may be redeemable as learning events, albeit with some major overhaul of the basic framework.

Here’s some of the problems I have with workshops as they currently exist:

  • The expert
    Most workshops get led by a subject matter or domain expert, eager to share their knowledge and experience.
  • The agenda
    Most workshops follow an agenda laid down by the “facilitating” expert. This (detailed) agenda is derived from the broader agenda of the sponsor. For in-house workshops this generally means a senior manager. For public workshops this generally means the expert, or the organisation for which he or she is working.
  • Passive engagement (i.e. little to no engagement)
    Many folks attend workshops with little interest in the subject and little enthusiasm for being there. The reasons for this are various but can include being told to attend, having spare training or professional development budget, and wanting to accrue CPD credits.

All the above lead to workshops having a low correlation between the needs of the participants and the content of the workshop. And to outcomes which fall short of expectations, and way short of what might be possible, given a different approach.

What is a Better Workshop?

For me, as a facilitator, a better kind of workshop would be one where folks had a real opportunity to meet their own individual and collective needs, be that for learning, for social interaction, or for other things.

And for me as an attendee, much the same criteria seem relevant too.

Applying the Antimatter Principle

So, to the application of the principle:

“Attend to folks’ needs.”


Firstly, do the prospective attendees have needs which correlate with the headline subject matter / topic? If not, maybe it’s better those folks don’t attend.

Then, there the agenda itself: Does it include a list of expected “learning outcomes”? Maybe it’s better not to do that. At least, unless the prospective attendees have created the list themselves prior to the event. And in those cases where this prior work is problematic, maybe it’s better to defer creation of the list until the event itself.

Yes, I suspect many people would prefer to have someone else set the agenda, structure the workshop, list the outcomes. And yes, it’s harder to sell workshops absent an outline, agenda or list of expected outcomes.

I do wonder if better workshops that no one gets to attend are any kind of improvement over what we have already. Maybe you’d be willing to share to view on this dilemma?

– Bob

Further Reading

Conferences That Work ~ Adrian Segar
Training From the Back of the Room! ~ Sharon L. Bowman


Seven Changes To Improve Flow In Your Software Development Process

Many folks drinking the Lean coolade seem to believe that removing waste is at the heart of the Lean approach. I beg to differ. I’d say that improving flow is the heart of Lean.

Here’s seven ways in which your team or, preferably, your organisation as a whole, might go about improving flow:

  1. Adopt a small thing as the universal unit of work. And by universal, I mean some unit of work that everyone across the whole organisation can recognise and adopt. This could be Use Cases, User Stories, or something else. Just keep the “small thing” small (never more than a couple of days work for a couple of people). cf Heijunka, FlowChain.
  2. Make flow visible. In particular, make e.g. queues, queuing times, and end-to-end cycles times visible for all to see.
  3. Know your WIP (work in progress) and work to reduce (limit) it. Cf. Little’s Law.
  4. Use demand to “pull” units of work through the system (as opposed to “pushing” work through).
  5. Eliminate – or at least minimise – hand-offs. That is, having work pass from one specialist to another. Each hand-off typically introduces another queue, with the inevitable costs and delays. One way to do this involves multi-disciplinary teams, or better still, up-skilling individuals so each person can competently take on a variety of specialist tasks.
  6. Identify the goal; understand demand (by various means – for example follow individual “demands” through the system, end-to-end;) identify the constraint; and apply the Five Focussing Steps (repeatedly). Cf. Theory of Constraints
  7. Experiment continually: trial possible improvements to flow, one by one, to assess their actual efficacy, in isolation from one another. Cf. PDCA a.k.a. the Shewhart Cycle.

And of course, none of the above suggestions will do much good, or even get acted on, unless and until the folks doing the work internalise a basic appreciation of the very notion of flow. And that’s unlikely to happen unless and until the work environment supports and nurtures folks’ curiosity and innate desire to do a good job.

Further Reading

The Principles of Product Development Flow ~ Donald G. Reinertsen
Seven Changes To Remove Waste From Your Software Development Process ~ Cecil Dijoux
Product Development Flow ~ FlowchainSensei
LondonCD Talk based on this post ~ Video
Getting People to Limit Their Work In Progress ~ Ben Linders

Antimatter Standup

Many aspirationally Agile teams adopt a daily ritual called the “standup”. At each such event, typically lasting some ten to fifteen minutes, each person in the team, in turn, gets to answer three basic questions:

  • “What did I accomplish yesterday?”
  • “What will I do today?”
  • “What obstacles are impeding my progress?”

Teams that make it past the aspirationally agile stage, sooner or later come to regard this ritual as trite, mechanical, and adding little value to their efforts.

As an example of how the Antimatter Principle can bring more joy – and thus, more effectiveness – into various aspects of software development practices, here’s an outline of applying the principle to the daily standup.


Each person might choose to begin their part by expressing empathy for someone in the standup, for themselves (very important, from time to time), for some other stakeholder not present, for the team itself, for the work, or for the outcome.


“I’d like Josh to know I’m here for him this week.”

“It’s a tough sprint, but I’m still all-in.”

The Basic Four Steps

Following on from empathy, each person then has the option to run through the four steps of Nonviolent Communication and call to mind, and answer, four questions:

“What did I hear, see yesterday that was of note?”
“How did I feel about that?”
“What needs (of mine, of others) were, are not getting met?”
“What refusable requests might I make of those here (including myself) right now?”


And maybe then reflect on context:

“What needs of mine, other folks were met yesterday?”
“What needs of mine, other folks will I be attending to today?”
“What do I need?”

There are several needs to which a daily stand-up meeting might choose to attend:

  • To help start the day on a positive note.
  • To align folks’ attention on the immediately most important stuff of the moment.
  • To bring folks’ needs to mind.
  • To attend to the needs of the team-as-a-collective-entity.
  • To communicate what is going on.

As a mnemonic device, think of PANTS:
Positive start, Alignment, Needs, Team, Status

Of course, if these are not the need of the folks, in the moment, then maybe a daily standup is not the most effective means by which to attend to them.

If you’re needing to find more joy in work, to have a more effective standup, or just want to experience the Antimatter Principle in action, would you be willing to conduct an experiment with this approach?

– Bob

Further Reading

The Empathy Exercise – New England NVC Group

Principles WTF

“Hey. Why don’t we write down some principles?”
“Why not. It might help.”
“Help who? With what?”
I regularly see folks, in what I assume is their eagerness to help and communicate, invest what can amount to considerable time and effort in discussing and, moreover, writing down sets of principles, manifestos, and the like.
This all without asking:
“Who needs us to write down some principles?”
“What do they need them for?”
“How will they actually get used?”
“How will we know if they’ve been of any use in e.g. meeting folks’ needs?”
“Could we spend the time and effort on doing something else more useful?”
– Bob
%d bloggers like this: