The Needsscape

-scape

suffix forming nouns

  1. Indicating a scene or view of something, esp. a pictorial representation: seascape, cityscape, soundscape.

Word Origin: Abstracted from “landscape”.

The Essence of Business

Business is, in essence, about attending to folks’ needs. Here’s a quick list of typical needs, to illustrate:

  • The financial needs of the owners and shareholders, and of staff.
  • The particular needs of customers, which the business’s products and services attempt to address.
  • The needs of suppliers for revenues.
  • The needs of wider society for commerce, prosperity, growth of social cohesion and living standards, wealth distribution, and so on.
  • The emotional needs of owners, shareholders, executives, managers and staff (examples: status, self-worth, compassion for others, making a difference, safety, love, esteem, curiosity, joy, learning, accomplishment, contributing to society, etc.).

I use the term “needsscape” to refer to the ever-changing set of Folks That Matter, and their ever-changing sets of needs. (Not all the needs listed above might feature in a given business’s needsscape).

In particular, the term Needsscape, for me, evokes the idea of one or more visualisations of the ever-changing set of Folks That Matter, and their ever-changing sets of needs, including the evolution of those sets over time. And especially visualisations of the current and relevant future set of Folks That Matter, their various sets of current and relevant future needs, and where the business is “at” in terms of attending to those folks and their needs. In other words, making all work (and objectives) visible, including attributes such as progress, status, and other interesting aspects of the work (aspects made interesting due, themselves, to the pertinent set of Folks that Matter, and their needs).

Indeed, all value-adding work is attending to (some) folks’ needs. And all wasted work is work where folks’ need are undermined.

What value would a real-time (or near real-time) visualisation of the needsscape bring to your group and/or business?

– Bob

Further Reading

English Words Suffixed with -scape ~ Wiktionary entry

 

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

BenSImoTweets

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapy provides guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. Most product development today is driven by rationality. What are the customers’ pain points? What are the user stories or customer journeys we need to address? What features should we provide to ameliorate those pain points and meet those user needs? Upshot: mediocre products which fail to appeal to the buyers emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) focusing as it does on product features, with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets.

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistent through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principleproposes that putting the principle of “attending to folks’ needs” at front and centre of allof the organisations policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineeringdisciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter.

– Bob

Some Alien Tropes

Most people, and hence organisations, fear the alien, And by doing so, cleave to the conventional. Yet progress, change, and organisational effectiveness depend on embracing the alien.

“Problems cannot be solved with the same mindset that created them.”

~ Albert Einstein

To help folks understand what I mean by the phrase “alien tropes” here’s a short list of tropes from the Synergistic mindset. Very alien to all the Analytic-minded organisations out there.

  • Treat people like adults. In all things.
  • Allow people to choose their own terms, conditions, locations, salaries, equipment and ways of working together.
  • Understand who matters and what each of these individuals need.
  • Attend to all the needs of all the folks that matter.
  • Be aware of both the prevailing and the desired social dynamic in the organisation.
  • Think in terms of communities and teams, not individuals. Ensure all the policies of the organisation support this perspective.
  • Actively support and encourage self-organisation, self-management and self- determination (e.g. of teams).
  • People really do want to contribute, learn, make a difference and do the best they can.
  • Effective collaborative knowledge work is a learnable set of competencies.
  • Skilful dialogue is essential for effective teamwork and, as a skill, requires constant practice and development.
  • Intrinsic motivations add, extrinsic motivations subtract.
  • Productivity in collaborative knowledge work demands superior cognitive function.
  • Stress causes a decline in cognitive function.
  • Stress has many causes (fear, obligation, guilt, shame, lack of safety, …).
  • Eschew leadership in favour of e.g. fellowship.
  • Common (shared) purpose has a unique power.
  • Enthusiastically model and support discussion, debate, open-mindedness and the ability to change oneself and one’s assumptions, beliefs.
  • Alien tropes do not come naturally to people. Support their uptake.
  • Do not fear the alien; embrace it, use it, exploit it.

I’d be delighted to expand on any of the above, if and when invited to do so.

– Bob

 

Alien Tech Alien Tropes

 

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C Clarke

One of the reasons we chose the name “Familiar” for our software house (the first 100% Agile software house in Europe, BTW) was a homage to the above Arthur C Clarke quotation, and the connection with things magical. (Familiars, black cats, toads, witches, and so on).

The results we delivered to our clients were – mired as those clients were in traditional, failing approaches to software development – to them quite magical. And very alien.

And the idea that Alien Tech, although often inexplicable to us Homo sapiens, can confer amazing benefits has been a staple theme of science fiction books, films and TV for many decades (see: Stargate, Alien, Predator, Slan, Null-A, etc.)

It’s not much of a stretch to regard Organisational Psychotherapy as a kind of technology (see definition, below). And there’s no denying it’s an idea and a discipline alien to most organisations today. So, in my book, that makes Organisational Psychotherapy some kind of ALIEN TECH.

Organisational Psychotherapy is but one of many alien tropes which offer amazing benefits, yet from which most organisations recoil, due to the sheer alienness of such tropes (we could call this reaction “alienation”).

Put another way, the traditional tropes of conventional (Analytic-minded) business and management leave organisations floundering in a swamp of ineffectiveness, compared to the alien tropes of the less conventional Synergistic- (a.k.a. Teal) and Chaordic-minded organisations. Alien tropes are the sine qua non of highly effective organisations.

In my wider role of enterprise software development coach or tech business coach, one of my core value-adds is bringing alien tech and alien tropes to the attention of my clients, highlighting the benefits of these alien ideas, and helping my clients address and hopefully resolve their issues of alienation, such that they can begin to replace their conventional tropes with these alien tropes and reap the benefits.

By way of example, here’s a brief list of some alien tropes, “alien” that is to conventional management thinking:

  • Flow
  • Systems Thinking
  • Theories
  • Self-organisation
  • Fellowship
  • Cost of Focus
  • Cost of Delay
  • Play
  • Slack
  • Nonviolence
  • Psychology
  • Generalising specialists

See also my post entitled “Baggage”

Some Definitions

Alien

(adjective)

  1. unlike one’s own; strange and not familiar; not belonging to one.
  2. coming from another world; extraterrestrial.
  3. differing in nature or character, typically to the point of incompatibility.

Technology

(noun)

  1. the branch of knowledge that deals with the creation and use of technical means and their interrelation with life, society, and the environment, drawing upon such subjects as industrial arts, engineering, applied science, and pure science.
  2. the application of this knowledge for practical ends.

Trope

(noun)

  1. commonly recurring clichés in e.g. business literature. For example: Leadership; Utilisation; Management; etc..
  2. involving an agreed-upon narrative, an archetypal reading of a story or situation according to the simplest and most widely-held beliefs, a kind of narrative stereotype.
  3. a word or expression used in a figurative sense
  4. devices and conventions that a speaker can reasonably rely on as being present in the audience members’ minds and expectations.

– Bob

Further Reading

Trope (Literature) ~ Wikipedia entry

Excolat in Pace

There’s a common idea which has been doing the rounds, ever since development (coding) first became a thing. We might sum it up as:

“Developers just want to develop in peace.”

As someone who spent more than a decade in the development trenches (and still does development today, occasionally), I can instantly relate to this issue. Indeed, focus is the key question. Any kind of interruption or distraction whilst reading or writing code can suddenly evaporate the evolving mental model of the inner workings of that code, a model built up painstakingly, with deep concentration, over twenty minutes or more. So three for four interruptions or distractions, however trivial, can wipe out an hour of otherwise productive effort. And that’s before we get to the question of frustration, the impact of frustration-induced stress on the individual, and the stress-related impairment of cognitive function more generally.

On the other hand, having developers separated from the folks that matter introduces other productivity-sapping dysfunctions, such as misunderstanding folks’ needs, building the wrong things, and reducing the joy of getting to see how the developers’ efforts make a difference to others.

Conundrum

So, how to ensure developers have the peace they need to focus intently on their coding efforts, whilst also ensuring they have sufficient interactions with the folks that matter – sufficient to ensure that needs are understood and the right solutions get built?

In the past, specialist intermediaries a.k.a. Business Analysts and Project Managers have served to address this conundrum. And solutions (including the role of specialists, and the workplace environment) have been imposed on developers without much consultation. Rarely have developers, or the folks that matter, been involved in finding a way forward together.

Personally, and in the context of self-managing teams in particular, I’m all for the teams and their customers (both internal and external) getting together and thrashing out a way forward. And then having regular check-ins to improve those ways of working together.

As an example, BDD (Behaviour-deriven development) is a current set of practices that offers one such way forward. Customers and suppliers sitting down regularly (as often as several times a day, for maybe twenty minutes at a time) and working through a User Story, Scenario, or Use Case, together.

And let’s not forget that the other folks involved, aside from the developers, also have their day jobs – jobs which require them to focus and spend time on things other than working with the developers.

How do you, your teams, and their folks that matter, propose to tackle this conundrum? How are you handling it at the
moment?

– Bob

What is Expertise?

Hiring an expert is a pretty much everyday occurrence. There’s accountants and lawyers, bankers and insurers, butchers and burger flippers, gardeners and mechanics. Sometimes we hire people not for their expertise, but simply to save us time, for example dog walkers or housekeepers.

For those folks we hire for their expertise, what does that actually mean? In the Antimatter frame, we might choose to say that experts possess – and can apply – more effective strategies for getting (some of) our needs met than we possess ourselves.

We’d not often tell our accountant how to calculate our tax liabilities. Nor our lawyer how to prepare and present our legal case. That’s because, with their more effective strategies, they’re likely to achieve a more effective outcome than we, with our relatively ineffective strategies, could. So we’re more likely to see our needs (in the round) get met.

Where’s this Going, You Might be Asking

Well, let’s turn our attention to hiring people – be that employees, contractors or consultants. Sometimes we’ll hire people to save us time. We could do the job that we’re hiring them to do, but we have more valuable things we can be spending our time on, so we hire them to do the less valuable things.

But sometimes, we’ll hire folks for their expertise. There’s some needs for which we accept our own strategies for getting those needs met are relatively ineffective. Like, running a software team or department, for example. So we find someone who appears to possess – and can apply – relatively more effective strategies.

So far, so good. If we choose our experts well, we’ll see our needs met more effectively – sometimes very much more effectively – than if we chose to attempt to meet those needs ourselves.

However. What happens when the effective strategies employed by our experts seem inexplicable to us? When we just can’t understand how applying their preferred strategies can achieve getting our needs met? We rarely quiz our accountants and bankers on their strategies. But we do quiz our new hires. As if we’d understand.

The Credibility Barrier

We have crashed headlong into the “credibility barrier”. Where it’s our own incredulity that blocks us from hiring those very folks possessing the most effective strategies for getting our needs met. And the most likely outcome being, we’ll reject the expert and their expertise, rather than recalibrate our assumptions and beliefs about what’s credible.

– Bob

What is “Working Software”?

We have for decades now been informed by the Agile Manifesto, and its four guidelines. Guideline number two is “working software over comprehensive documentation”. I’m sure many folks skip over this with no more than a quick nod of agreement (and a implicit interpreting of “comprehensive documentation” as “reams of useless documentation”).

But what exactly do we mean by “working software”? A quick trawl through the Internet finds little in the way of a definition of this term, nor any explicit explanations of the why – the value – of “working software”.

For me, working software is simply any software that is actively being used by customers (a.k.a. users) in their real jobs. Until and unless it’s actually being used for the core purpose for which it was built, no one will be any the wiser as to its fitness for purpose.

Who Benefits from “Working Software”?

Developers

Developers get to understand how close they came to understanding the customers’ needs. Assuming, of course, that the feedback loop from customs to developers is a closed loop, rather than having no feedback from customers, or any feedback that is provided falling into a hole or getting hopeless garbled somewhere along the line from customers to developers. In the latter case working software is a pretty useless and ultimately frustrating concept.

Customers

Customers get to apply the software in the context it was intended. By which I mean their using it to help them be more successful (whatever that might mean in any individual case). They’re reassured that the developers are attending to their needs (although not necessarily fully meeting them). By applying the software in their work context, they get to see its true nature and fit. And they get to tell their story, or at least a part of it. Folks find telling their stories cathartic (assuming they’re being listened-to).

The Producers

The producers (the company supplying/building the software) get to exercise their channels to and from the market, and to and from active users. Shortfalls in the clear communication of needs (customers -> developers), smooth deployments (company -> customers) and clear communication of feedback (customers -> developers) can be identified and addressed. In principle, anyways.

Other Benefits

“Working software” as defined above, promises other benefits, above and beyond those already mentioned.These additional benefits  include:

  • Provides a definitive and unambiguous definition of what has been shipped/deployed, in a way that written requirements or documentation (one of the forms of documentation mentioned in the aforementioned Agile Manifesto guideline) simply cannot.
  • Promotes interaction and collaboration. Not just via feedback on the final version, but all the way through the evolution of the product or service under development. (Assuming the product or service deployed is capable of supporting real users in real work).
  • Early & regular delivery of value:
    Value to the customer / user (the growing utility of the product or service, as it evolves through numerous deployments and instances of real use).
    Value to the producers (assuming the producers get paid for each deployment + live use).
    Value to the developers (kudos and the joy inherent in materially attending to folks’ needs).
  • Flow (assuming iterative deployments + live use).
  • The Check phase of PDCA (hypothesise -> experiment -> compare proposed results with actual results -> draw conclusions )
  • A valuable measure of progress (“how well are we contributing to the success of our customers?”)

What “Working Software” is Not

It’s not:

  • “works on my machine”
  • “passes the test suite”
  • “runs in the test environment”
  • “runs in production”

None of these provide the acid test of real users doing real work with the thing.

Proviso

As with most things Agile, the label “working software” misleads as much as it helps. I’d propose renaming it to e.g. “deployed product or service” but that horse is already out of the stables and far over the hills. “Working” is ambiguous, and “software” omits mention of all the other elements of the deployed product or service necessary to put it to real use (user guides, release notes, other documentation, training, support, etc.).

– Bob

Further Reading

Online Experimentation at Microsoft ~ Ronny Kohavi et al.

%d bloggers like this: