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]

Aside:

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.

Violence

“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

A New Hope

“Hope is the only thing stronger than fear.”

I have hopes, and I have fears. Most days my hopes win out over my fears. As far as this blog goes, I have long had hopes it might give others some hope, too. Hope that by finding new, more effective strategies for getting folks’ needs met, we can nurture workplaces where dignity and human endeavour flourish.

“Hope is the fuel of progress and fear is the prison in which you put yourself”

~ Tony Benn

I’m Not Happy

I’ve become ever more convinced that trying to change others is a poor strategy for bringing about such change. That we can’t solve other people’s problems – or meet their needs. That, fundamentally, only they can do that. Bitter pill.

I’ve now written a little over four hundred posts on this blog. I started posting to share stuff I had learned over the years as an imaginal cell in the caterpillar of work. Recently, I have become increasingly dissatisfied with the notion that telling people things has much effect excepting perhaps some marginal entertainment value. Put another way, I see no evidence that folks ever act upon the ideas that I share.

So, I’m persuaded that if we want to change the world, starting with ourself is a better place to start.

“If we could change ourselves, the tendencies in the world would also change. As a man changes his own nature, so does the attitude of the world change towards him. … We need not wait to see what others do.”

~ Mahatma Gandhi

Looking Forward

So, I’m resolved to stop blogging to change others, and start blogging about how my own perspective, assumptions, beliefs have changed, and continue to change, over time. In other words, how I have, intentionally and unintentionally, changed myself.

I’m fearful this might make my posts seem more egocentric and less helpful, but I’m hopeful that with your feedback, this new direction might, eventually, prove useful.

- Bob

Why Familiar Was Europe’s First 100% Agile Software House

Familiar was a software house based just outside London, which I started and led, with some ex-Sun Microsystems colleagues, circa 1996-2000.

This post is about why we decided on Agile as our general approach to getting things done. It’s not so much about why we were the first.

One Hundred Percent Agile

This refers to the fact that all our work – both client-facing and internal – was conducted in an “agile” manner. Which is to say, something like Scrum nowadays – e.g. with two week iterations, emergent “requirements’ and regular deliver of working things into production.

Of course, this was some years before the label “agile” was to be coined by the Snowbird folks and thence began to be applied in this kind of context.

You could also say we were 100% agile because (what came to be identified as) agile principles informed our approach to work across the whole organisation, and not just in the software development work we did.

Why

We didn’t call what we did “agile”. We weren’t trying to replicate someone else’s approach or ways of working. We weren’t trying to be agile, we were intent on being great! And for us, great meant “highly efffective”.

We adopted our own approach to work – primarily but not exclusively software and product development work – because we wanted to better meet the needs of our customers, of ourselves and of our company. And incidentally, the needs of our suppliers, our loved-ones, our shareholders – mostly the folks working for the company – and our channel partners, too. We continuously evolved our approach – which we then called Jerid, now Javelin – both to adapt to changing contexts, and to more effectively meet folks’ needs, as we learned more about what they were and how to do that.

Let me say that again, we chose to work the way we did because we wanted to better meet folks’ needs. I wouldn’t have uses this form of words back then, but with the benefit of hindsight this is what we were intent on doing.

We had all seen enough of the IT/software industry to know that the industry norm was far from meeting anyone’s needs effectively. We knew we could do much better. And we knew the basic of how. We were determined to continue to advance our knowledge in that regard.

Success

We succeeded, I believe, because the whole organisation was geared to the agile approach, and there was no discontinuities, such as we see in many organisations trying to “go agile” today. By which I mean, for example, the discontinuities between the “agile” software teams and the rest or the containing organisation, with its raft of decidedly non-agile – even anti-agile – beliefs, principles, processes, policies, procedures and organisational structures.

Put another way, our way of working met folks needs, not because of any specific characteristics – NOT because it was, or we were “agile”, but because we wanted to be great at what we did, and took time and effort to understand how we could achieve at least some of that aspiration.

We were building an environment in which folk could come together, work well together, find and grown intrinsic motivation, and excel.

– Bob

 

 

 

What Is Agile Software Development?

The term “agile” now signifies whatever folks want it to. It’s a term that has achieved widespread recognition within the software development field, and with that recognition, dilution to the point of near meaninglessness.

Agile was (circa 2001) a reaction by a bunch of experienced, senior developers to both the conventional “heavyweight” and widespread “cowboy coding” approaches to writing software prevailing at the time.

Forget about talk of incremental, iterative approaches. Forget about “inspect and adapt”. Forget about “embracing change”. Forget about “quicker development of higher quality software”. Forget about “earlier realisation of investment”. Forget about methods or frameworks like Scrum, Kanban, DSDM, XP, etc.. And forget about practices like sprints, wall-boards, and the whole practices nine yards.

These are all post-hoc rationalisations of one basic truth: The Snowbird folks and their fans – then and now – were fed up with wasting their lives on failed and “challenged” software projects, on make-do-and-mend development, and wanted to do something about the quality of their lives at work. Theirs, and their peers. They felt a need to make more of a difference to the world than then-current software development approaches allowed.

Meeting Their Own Needs

Put another way, their championing of the agile cause was a means for developers everywhere to – rather unilaterally – attend to their own needs, including more closely living their (Theory-Y) values.

Sadly, lacking a whole-system, all-stakeholder, organisational-dynamics perspective, the result was a somewhat parochial thing. A thing that failed to recognise that software and its development rarely exists in isolation, and much more often happens in a context largely outside the control of those folks directly engaged in writing the software.

Now, some fifteen years on, we can see that the insanity – and tragedy – of agile – lies in the Sisyphean task of trying to build effective teams – and ways of working- inside ineffective organisations.

– Bob

Follow

Get every new post delivered to your Inbox.

Join 11,810 other followers

%d bloggers like this: