The Nature of The Problem

It’s my proposition that the “software crisis“, some 50 years old now and still going strong, is a consequence of a widespread failure to grasp – or agree on – the nature of the problem that is “software development”.

Many have guessed at the nature of the problem. Many have crated more or less convoluted solutions to the imagined problem. Many more have adopted these so-called solutions, having little idea themselves of the nature of the problem and thus little opportunity to evaluate the fitness of such solutions.

And no, I’m not saying that I have the answer to the nature of the problem. In fact, I’m not even going to pursue here what the nature of the problem is, or might be.

Meta-problem

This post is simply to ask: Have we, as an industry, understood the nature of the problem? Is the lack of such understanding, consensus, the real problem? Is there any mileage in building such shared understanding, such a consensus?

Or will we just go on each ploughing our own separate furrows? Each guessing at the nature of the problem, and each quixotically tilting at our various windmills, all the while taking money off of gullible folks who rely on us, to a greater or lesser extent, to identify the nature of the problem?

Is this the meta-problem? Our Gordian Knot?

– Bob

NeedsFlow

[Tl;Dr: The essence of software and product development is about continuously exploring and meeting folks’ needs. How about as in industry we stop shilly-shallying and place this reality at the core of our approach to development?]

The Essence Of Software And Product Development

Essentially, every approach to software and product development is about a flow of things whereby a development team, group or organisation attempts to satisfy some selection of folks’ unmet needs.

In batch-and-queue (e.g. Waterfall, etc.) approaches, needs are batched-up into large batches, and flow (not very effectively) through a sequence of queues. Each batch (in the pathological case, only one ) eventually gets dropped onto those assumed to have said needs, and that’s about it.

In iterative (e.g. Scrum, Kanban, etc.) approaches, needs are batched up into many, relatively smaller, batches, and flow (rather more effectively) through a sequence of queues (at its simplest, e.g. Backlog, Doing, Done). Each batch gets dropped onto the folks assumed to have said needs, and these folks get the chance to say if their needs have been met well enough, or not. When budgets and timescales allow, a later iteration can then have another go at better meeting the poorly-met needs, along with including any other priority needs that might have emerged along the way.

Different approaches differentiate themselves on e.g. batch sizes, selecting of the kinds of folks whose needs will be attended to, cadence and strategies.

Needs Trump Value

Why Needs flow? Why not just stick with the more common “value” flow? Well, for me there’s a whole bunch of issues around the notion of value. Including:

  • Value for whom?
  • Who gets to specify how any particular “value” is measured or quantified (most often folks ill-equippped to do so).
  • The whole notion of “value” (often overlooked, often misunderstood).
  • Valeu is too often though of in simple economic or financial terms. Human beings perceive value differently, and much more richly (e.g. emotionally).
  • How can we tell when we’ve delivered “value”?

So, I propose that needs trump value. And therefore, that when focussing on flow, it’s more useful – and effective – to focus on the flow of needs.

Diagram

The above diagram shows a system boundary – this could be the whole organisation, the development organisation, or just one development team. Bundles of external needs flow into the system, and merge with other bundles of needs coming from inside the system. These bundles pass though various stages (and queues) where “development” strategies are uses in moving the bundles from stage to stage, and from queue to queue. Ultimately, candidates (things we hope will meet the needs that entered the pipeline) flow back to external parties, and also to internal stakeholders, such as the developers themselves.

Impediments

This perspective allows for the simple integration of dealing with impediments. Things that are impeding e.g. flow or the outflow of effective candidates may themselves be needs. And may enter the pipeline much as any other needs. Of course, there may be some( or many) such impediments than no one has any need of dealing with. These may be filed or ignored.

Abstract FlowChain

Whilst FlowChain was conceived to be awesomely effective at handling bundles of e.g. User Stories, Use Cases, Improvement Stories, etc., it can very easily embrace the unit of flow being bundles of needs, or – in the single-piece-continuous-flow scenario – individual needs.

Limiting WIP, Making Things Visible

From the diagram, you may begin to see how we might simply make the flow of needs visible, should we so choose. And personally, I’d like to make visible the ultimate fate of the candidates too, with a little expansion of the scope of the diagram.

And the queues (particularly the first) can serve as a convenient means to limit Work In Progress (a.k.a. Needs in Progress).

No Projects

It may not be immediately obvious, but the NeedsFlow perspective implicitly removes the need for projects. NeedsFlow decouples development (flow) from products and product lines (each of which meet a more or less related collection of needs).

– Bob

Attending To The Needs Of Others

Picture of a giraffe's head

Following on from my previous post, some folks may be wondering just how to go about “attending to folks’ needs”. As the brevity of my previous post seemed to find favour, I’ll keep this one (kinda) brief, too.

Giraffe Listening

For me, it all starts with learning to listen with giraffe ears. “Listening to get in touch with what’s alive in a person” as Marshall Rosenberg puts it.

And there’s probably no better place to start learning to listen than with oneself. I mean, listening TO oneself. You can do it in secret, without anyone knowing, until you’ve found a little confidence in the practice of it. Confidence which may help in listening to others.

Empathy

Empathy is “the ability to be wholly present with someone”. It’s not what you say, and certainly not what you think. It’s the ability to just be present, non-judgmentally, with someone.

Again, I’d suggest practicing on yourself first. It’s particularly tricky to empathise with others if you haven’t quite found the knack of empathising with yourself.

Learn To See Your Own Needs

Even with listing to oneself and empathising with oneself, it can take some reflection and further practice to begin to understand one’s own needs. Nonviolent Communication suggests that our needs derive from our feelings about things we have observed. Things someone has said, or done.

Identifying these triggers, objectively (like a fly-on-the-ewall, without judgement) can lead us into exploring the feelings they trigger.

And thence to the needs that the trigger has met – or failed to meet.

And ultimately to making a refusable request of ourself – or another – in an attempt (experiment) to get those needs met.

Experiencing this four-step process for and with ourselves puts us in a better place to begin to do the same with others.

Moving On To Others’ Needs

When you’ve built up a little reservoir of confidence in listening to yourself and empathising with yourself, then it might be time to engage with others.

Ike Lasater suggests it can be helpful to negotiate an explicit agreement with each person you might want to engage with. At least, if they know you and your “habitual” ways of communicating with them. Adopting a new way of relating to people, with new words, can come across as weird or clumsy at first. Even with some self-practice under your belt. So to minimise freaking out your colleagues, and nearest and dearest, making a refusable request of them to allow you to try out you new moves can assuage early confusion and angst.

And a word of caution:

It’s sooo easy to “put yourself into someone else’s needs”. By which I mean, saying to yourself “I just know this person needs…[x]”.

It can be helpful to guess what they might be feeling (we can never know with any certainly) – and try that guess out on them to see if we guessed right:

“I guess your feeling [bewildered]?”

The other person is then free to confirm or deny that feeling. If they deny, we might choose to guess again. And if they confirm, then we might guess what need(s) they have (if they don’t volunteer this information) that are or are not getting met:

“I guess that’s because you need [some kind of consistency between people’s words and actions]?”

Again, the other person is free to confirm or deny your guess.

And we can even invtie them to make a refusable request:

“Would you be willing to ask something of me (or another) that might help in getting that need (of yours) met?

In summary, when you’ve got a handle on helping yourself identify your own needs (and making refusable requests of yourself, or others) then you’re in a position to begin doing the same with and for others. I take this to be what Marshall Rosenberg meant when he said:

“Empathy gives you the ability to enjoy another person’s pain.”

I find much joy – and enjoyment – in being able to empathise, and attend to others’ needs. Especially when they’re in some kind of pain. The Antimatter Principle is founded on the belief – and confirming science – that every human being does.

– Bob

Acknowledgements

My thanks to George Dinwiddie (@gdinwiddie) for suggesting the topic for this post.

Further Reading

Words That Work In Business ~ Ike Lasater
More Time To Think ~ Nancy Kline

The Nine Obsessions of the Extraordinary Software Development Manager

The key to successful management is to spot a few things that will make a difference in your organisation and then concentrate on doing them.

If you are looking for ways of fostering sustainable success within your role as a software development manager, whether in a small, medium or large organisation, this list might help provide some insights. Insights which might serve in the task of contributing to the emergence of improved health for your organisation.

  1. Attending to needs
    • Attending to the needs of the folks within the software development group.
    • Attending to the needs of other folks – within the business yet outside the software development group.
    • Attending to the needs of the business (as a proxy for the needs of e.g. customers, executives and shareholders).
  2. Emphasising service
    • Championing the role of the software development group in exploring, monitoring, understanding and serving the needs of the business and its constituent parts.
  3. Aligning to the bigger picture
    • Participating in modelling the business as a whole, and the part the software development function plays in that.
    • Understanding the software development capabilities the business needs now and in the future.
    • Working to evolve those capabilities in a timely fashion.
  4. Nurturing an environment where people find joy in working together and giving of their best
    • Understanding the nature of knowledge work and the fundamental differences this entails for “managing” – compared with e.g. “factory work”.
  5. Working with the grain of your organisation’s mindset
    • Working to minimise organisational cognitive dissonance.
    • Understanding the impact (risk) of specific change initiatives.
    • Preparing for organisational (mindset) transformations (e.g. Analytic to Synergistic) – where feasible.
  6. Getting out of the building
    • Understanding customers and their needs, and the relationship between your organisation and the wider world.
  7. Over-communicating
    • Building a shared mental model of the role of the software development group and its relationship with the purpose of the business as a whole.
  8. Making friends
    • “No man is an island”. Having friends makes the whole experience of being a dynamic software development manager more bearable.
  9. Being seen to be human
    • Nobody likes being treated like a cog in the machine, a drone, a fungible resource. Developers least of all. People have feelings, needs and aspirations. Being seen to be human is the gateway to improving relationships within and without the software development group.

For brevity, I’ve refrained from expanding this list with i.e. narrative explanations. Should you have any specific questions, I’d be happy to elaborate.

– Bob

Further Reading

How to Be a Great Software Development Manager ~ Bob Marshall
Four Obsessions Of An Extraordinary Executive ~ Patrick Lencioni

What’s A Good Job?

“If you want people to do a good job, give them a good job to do.”

~ Frederick Herzberg

But what, exactly, constitutes a “good job”?

Looking at this through the frame of the Antimatter Principle, we might choose to say that a good job is one which contributes to everyone’s needs getting met. Note, not just the needs of the person holding the job, but everyone’s needs, to a greater or lesser extent.

What do we mean by “needs”? Let’s not be superficial or utilitarian. I’m talking about core human needs, needs drawn from an emotional place. Employees are, after all, human, are they not?

Here’s a brief list of such needs, to help illustrate what I’m talking about:

CONNECTION

acceptance, affection, appreciation, belonging, cooperation, communication, closeness,
community, companionship, compassion, consideration, consistency, empathy, inclusion,
intimacy, love, mutuality, respect/self-respect, safety, security, stability, support,
to know and be known, to see and be seen, to understand and be understood, trust, warmth

PHYSICAL WELL-BEING

air, food, movement/exercise, rest/sleep, sexual expression, safety, shelter, touch, water

HONESTY

authenticity, integrity, presence

PLAY

joy, humor

PEACE

beauty, communion, ease, equality, harmony, inspiration, order

AUTONOMY

choice, freedom, independence, space, spontaneity

MEANING

awareness, celebration of life, challenge, clarity, competence, consciousness, contribution,
creativity, discovery, efficacy, effectiveness, growth, hope, learning, mourning, participation,
purpose, self-expression, stimulation, to matter, understanding

How About Your Job?

By this yardstick, how would you rate your job? And the jobs you create for others in your organisation? And what does that rating mean for folks’ engagement and motivation?

“We can provide conditions in wich employees are more likely to be motivated or demotivated, but is a conceit to believe that managers can motivate people.”

~ John Seddon, Freedom From Command & Control

– Bob

Further Reading

One More Time: How Do You Motivate Employees? ~ Frederick Herzberg

The Antimatter Proposition

“88% of Americans feel that they work for a company that does not care about them as a ‘person’.”

~ Raj Sisodia

Why does this even matter? After all, most organisations appear to operate under the assumption that people are simply fungible “resources”. Resources that need a job more than the organisation needs them.

“There is sufficient evidence to show that people can be exceptionally innovative under certain conditions. Working in a [uncaring] machine-like organization is not one of them.”

~ H Jarche

Is workplace democracy a solution? Whatever the solution, there’s an awful lot of money – and joy – being left on the table:

“When businesses successfully engaged their employees… they experienced a 240% BOOST in performance-related outcomes”

~ Gallup, State of the American Workplace Report 2013

 

Think Again?

Maybe recent trends and evidence tempt you to think again about the nature of the workplace you have created, and the state of mind, and morale, of the folks in that workplace?

If so, one question I’m regularly asked is:

“How on earth can we start addressing this issue? How can we even begin to turn things around and create workplaces where folks feel like they might want to become engaged?”

And my answer to this question is: the Antimatter Principle.

Are you sufficiently engaged with your organisation that you might want to explore how this helps?

– Bob

Further Reading

Leadership Yawns As Employees Check-Out ~ Bernie Nagle pp. Craig Daniels
State of the American Workplace ~ Gallup (Report)
Eleven Reasons Your Employees Are NOT Working For You ~ Jim Benson
The Antimatter Why ~ Bob Marshall

Who I am

This blog is named to honour Steve Jobs – and the other “crazy ones”. And to honour his take on what is means to be “in business”. I was reminded of his stance by this video, today. To remind myself, and inform some other folks, I thought I’d revisit an earlier post about what I believe.

Steve put it like this:

“We believe that people with passion can change the world for the better.”

~ Steve Jobs

and, more fundamentally, this:

“We believe that those people who are crazy enough to think they can change the world are the ones that actually do.”

~ Steve Jobs

And What I Stand For

For me, i subscribe to the latter sentiment absolutely. In my case, I have for the past twenty years at least, explicitly stood for people. Developers, yes – who are often the craziest ones. But also for all the other people, managers and bosses included. All those people toiling away in oppressive organisations everywhere. Organisations that suppress or ignore our potential and our humanity, and rob us of the joy of working together on changing the world for the better.

“I believe that a Rightshift of knowledge-work businesses brings improved health, wealth and wisdom for individuals, for the organisations in which they work, and for society at large.”

- Bob Marshall (FlowchainSensei)

So, to be clear, I stand for a world in which businesses serve society and people, and not, as all too often today, vice versa. In particular, I stand for Humane Solutions, in a world where the evil twins of Technology and Bureaucracy appear to have the whip hand – and people and their needs generally go by the board.

The massive irony, of course, is that businesses that truly take to heart the idea of serving society and people find they’re much more successful than those which do not.

Would you be willing to share what you stand for?

Daunted

I often feel daunted by the sheer scale of the challenge. I take comfort from things like the story of the starfish, and this Arthur Ashe quote:

“Start where you are. Use what you have. Do what you can.”

~ Arthur Ashe

How about you? Do you, as Steve Jobs invited us, “honour people that Think Different”?

Here’s to the crazy ones. I can identify.

- Bob

Further Reading

The Rightshifting Ethos ~ Bob Marshall
Who Is Bob Marshall? ~ Yves Hanouille
A Personal Charter ~ Bob Marshall
Greetings from Munich ~ Video interview

Follow

Get every new post delivered to your Inbox.

Join 11,932 other followers

%d bloggers like this: