Monthly Archives: February 2015

Antimatter Stories

That’s User Stories, in case you were wondering.

The widely accepted format for User Stories (a form of requirements capture) goes something like:

As an X
I want to Y
So that Z

Outwith the real purpose of User Stories being as placeholders for future conversations, folks do tend to obsess over the written results. Both their format and their content.

So, the written form of User Stories attempts to capture the who (X), the what (Y) and the why (Z).

Needs Trump Value

We may alternatively choose to write our User Stories with the value stated first, thereby emphasising that the purpose of each User Story, when implemented, is to deliver some value, e.g.:

So that Z
As an X
I want to Y

Setting aside the issue of the widespread misunderstanding and misuse of the User Story concept, the idea that value is paramount seems almost universal.

But, from a human psychology perspective, needs trump value every time.

So might it not make more sense, if we choose to continue using the User Story, to capture folks’ needs, so we can attend to those need?

Something like:

As X (individual, human being)
When I hear/see Y
I feel F1, F2, F3…
Because I have a need for Z1, Z2, Z3…

Possibly augmented by a refusable request, and enclosed in an “Empathy envelope”. And with a separate story, or a separate aspect of the one story, for each and every person affected by it? Cf Covalence.

Some examples:

As Peter Smythe, in my role as IT Security Engineer
When I see someone attempting to access the system
I feel anxious
Because I need to keep my job – and that depends on preventing unauthorised access
[So would you be willing to ensure the system validates each access attempt via e.g. a logon screen to ensure only authorises people can have access]

As Helen Arbuthnot, in my role as sales assistant
When someone chooses to buy a can of beans
I feel happy our shop will make a sale
Because I need to have this job and get paid, and to help people
[So would you be willing to ensure that payment is taken, and the sale is accounted for]


I accept the relative lameness of these contrived examples. Would you be willing to provide more useful examples?

– Bob

Antimatter Recruiting

The Antimatter Principle applies not just to software development and teams, but across the whole spectrum of business. One key area that could benefit is that of search and selection, a.k.a. Talent Management a.k.a. recruitment a.k.a. hiring.


“Classifying and judging people promotes violence.”

~ Marshall Rosenberg, Nonviolent Communication

“So what?” you might say. So, I ask – is violence the first and greatest thing you want your new hires to associate with the relationship they’re building with your organisation – and you with them?

Let’s face it, the traditional recruiting process is nothing if not a prime example of classifying and judging people. Is there any way we can get away from that?

The Default Pattern

Traditional recruiting almost always gets a new-hire relationship off on the wrong foot. By the time the selected candidate has been through the process and starts their new job, the pattern for disengagement has pretty much been set.

How might we approach recruiting such that new hires might feel more engaged when they start work, rather than less?

Would you be prepared to consider the application of the Antimatter Principle to this process?

The Traditional Focus

Traditionally, recruitment is all about the needs of the hiring organisation, and what the candidates can do to meet those needs. The candidate’s needs barely get a look-in, excepting the tacit belief that compensation (salary) is all that needs be offered by way of attending to the candidate’s needs.

How It Could Work

How might it be if recruiters, hirers, etc., focused instead on the needs of the candidate? Not to the exclusion of the needs of the organisation you understand. But putting the needs of the candidate at least on a par with those of the organisation. And helping the candidates – who will have little in the way of information on how accepting the job might help them attend to their own needs – understand how taking the job might help them get their needs met?

This alternate focus would bring a number of benefits:

  • The candidates would all feel more positive about the hiring organisation. Those who were not offered the position may well speak about their experience positively to friends and colleagues, and candidates and their contacts may feel more inclined to pursue other opportunities with the organisation in the future.
  • More engaged new hires, from the get-go.
  • An organisation with more connections, joy and humanity.

– Bob

Further Reading

Stop the Machine. Engagement is Human ~ Simon Terry
The War With Talent ~ Dr. Charles Handler

Raising The Bar

Most days I have at least ten different ideas for blogs posts. Some I reject because they don’t fit the kind of posts I want to publish here on Think Different. That’s what marketers call “positioning”.

FWIW I’m considered the merits of having a number of different blogs to help with this. For example, my (presently) rather low-activity Humane Solutions blog, and now my latest, “Digital Business Transformation“.

But for the past couple of months, I’ve been applying a new filter to my ideas for posts: How likely is it that folks will ACT on the post? If I deem it unlikely to promote action, I’ll not write the post. For the moment this means I’m writing and posting much less. And that’s OK for me.

– Bob


Managers Don’t Hate Agile

Whilst I get my head into gear regarding my New Hope, here’s a brief post on the typical reaction to Agile from managers.

Managers don’t hate Agile. At least, before they come into contact with it in their organisations. Before contact, they mostly have no opinion on it. The few who have taken the trouble to read about it generally perceive it as a somewhat desirable thing. A WIBNI. It seems marginally attractive and benign, not least because there are so few articles, stories, etc. describing the pitfalls.

So, most managers who adopt Agile, or have to adopt it via edicts from higher up, are woefully ill-prepared for the consequences. Sooner or later, it starts to dawn that to do agile “properly” has far-reaching implications, both for the organisation outside the development teams, and for themselves personally. The lion’s share of these implications are not attractive.

Consequently, the precepts of agile, unknown at the outset, but becoming clearer as news begins to come in, get watered down to point where they become non-threatening. And in the process, become non-viable, too. The baby is discarded with the bathwater, lip-service is paid to “being Agile”, and things return to the status quo.

Of course, this sticks in the craw of any who want Agile to succeed – developers and testers, mainly. Being far from the gemba (a.k.a. the coalface, where the work is happening), those who first stipulated the Agile adoption have little alternative but to believe that:

  • The Agile adoption is going well (until it becomes obvious it is not).
  • The fault for ultimate failure lies with Agile itself, rather than the managers’ undermining of it.
  • The departure of disillusioned talent – developers and testers, mainly – is just “natural wastage”.

So, managers don’t hate Agile. Most are utterly indifferent to it. Many just come to ignore it, once its nature becomes understood. And a very, very few come to embrace it as a good thing.

– Bob

%d bloggers like this: