The Hidden Biases That Keep Us Hooked on Management

💡 Are you tired of relying on the idea of “management” as the default solution to organisational problems?

➡ The strong inclination towards management as a solution for organisational problems can be influenced by bias in a variety of ways. These include:

• Cultural bias: Western cultures tend to place a high value on individual achievement and personal success, which can lead to a focus on hierarchical management structures as a means of exerting control and achieving results.
• Confirmation bias: Organisations and individuals may be predisposed to seeing management as the solution to problems, leading them to selectively seek out and interpret information that supports this view.
• Limited perspectives: Management can be seen as the default solution for organisational problems due to a lack of consideration or awareness of alternative approaches or perspectives.
• Financial incentives: Financial incentives can create a bias towards management as a solution, particularly among those who stand to benefit financially from its implementation.
• Management industry: The management industry has a vested interest in promoting management as the solution to organisational problems, which can create a bias towards this approach.

Upton Sinclair’s dictum,

“It is difficult to get a man to understand something, when his salary depends on his not understanding it,”

is particularly relevant in this context. Financial incentives and the influence of the management industry can create a powerful bias towards management as a solution for organisational problems, particularly when individuals stand to benefit financially from its implementation.

To address bias towards management as a solution, it is important to maintain an open mind, seek out diverse perspectives, and evaluate potential solutions based on their effectiveness rather than defaulting to a particular approach. This may involve exploring alternative management styles, such as servant leadership, or considering other approaches to addressing organisational challenges, such as self-organising teams, #Fellowship, and #NoManagement.

By remaining open to new ideas and approaches, organisations can avoid the limitations imposed by bias and better address their challenges and opportunities.

#NoPlanning

I’ve lost count of the number of folks I’ve encountered that see planning as sacrosanct, as gospel. I’ve also lost count of the number of occasions I’ve attempted to broach the subject with offers of e.g. dialogue and mutual exploration, only to be stonewalled.

In support of #NoPlanning, I offer the follow Ackoff quote:

“If you have the capacity for response to the unexpected, then you don’t have to plan for it. The important thing to do then is to continuously increase the capacity to respond to whatever occurs in the future.”

~ Russell Ackoff

I posit that #NoPlanning is the epitome of business agility.

Would you be willing to talk about it?

– Bob

Quintessential Product Development

In my most recent book “Quintessence” I map out the details of what makes for highly effective software development organisations.

As fas as software development organisations are concerned, it’s a bit of a moot point – as software is generally something to be avoided, rather than sought (see also: #NoSoftware).

“The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs 

Foundational Concepts

There are just a few complementary concepts that mark out the quintessential product development company. These are:

• Whole Product.
• Systematic Product Management.
• Whole Organisation (systems thinking).

Whole Product

The quintessential product development organisation embraces the concept of “whole product”. Which is to say, these organisations emphasise the need to have every element of a product i.e. core product elements plus a range of “intangibles” – everything that is needed for the customer to have a compelling reason to buy (Mckenna 1986).

Systematic Product Management

Quintessential product development organisations take a systematic approach to flowing new product ideas and features through a number of stages – often in parallel (Ward 1999) – to predictably arrive at a successful new product in the market:

• Inception – spotting a gap in the market, a.k.a. some (potential customer) needs going unmet, interesting enough to do some discovery.
• Discovery – uncovering and proving the real needs of customers, the things they value, the likely usability of possible solutions, the feasibility of meeting everyone’s needs, and the viability of a product as a means to these ends. In essence, the key risks facing the proposed product. 
• Implementation – building a whole product solution, i.e. both core elements and “intangibles”.
• Launch – Placing the product on sale (or otherwise making it available to customers).
• Feedback – Seeing how the market responds.
• Pivot or Augmentation – Acting on feedback to either reposition the solution (in response to unfavourable feedback) or to incrementally update / extend the “whole product” offering to continually strengthen the product’s value proposition and appeal.
• Cash Cow – Reap the commercial rewards of a strong product and market share.
• Sunsetting – Wind down the product in a way that meets the ongoing needs of all the Folks That Matter™️ (e.g. continued support, spare parts, etc.; easing customers’ transition to newer products; etc.). 

Whole Organisation

It’s common for organisations to think in terms of silos. A Product Management or Product Development silo being but one more silo in a long and ever-lengthening list. 

In the quintessential organisation, the whole organisation is geared around – amongst other things – the task of regularly and predictably getting new products and new product features/updates out the door and into the hands of customers. In the longer term, new products are the life blood of most organisations, especially in the technology industries.

We only have to look e.g. Toyota and their TPDS (Toyota Product Development System) to see both an example of how this works in practice, and the huge benefits of the whole-organisation approach.

Quintessential product development organisations embrace a range of progressive ideas such as Prod•gnosis and Flow•gnosis.

– Bob

Further Reading

Marshall, R.W. (2013). Product Aikido. [online] Think Different Available at: https://flowchainsensei.files.wordpress.com/2013/04/productaikido041016.pdf [Accessed 13 Jan. 2022].

Mckenna, R. (1986). The Regis Touch: New Marketing Strategies for Uncertain Times. Reading, Mass.: Addison-Wesley Pub. Co.

Perri, M. (2019). Escaping The Build Trap: How Effective Product Management Creates Real Value. O’Reilly.

Ward, A.C. (1999). Toyota’s Principles of Set-Based Concurrent Engineering. [online] MIT Sloan Management Review. Available at: https://sloanreview.mit.edu/article/toyotas-principles-of-setbased-concurrent-engineering/. [Accessed 13 Jan. 2022].

That’s Rich

In most organisations I’ve seen and worked with over the years, the prevailing belief of the Core Group seems to be ”these people (employees) are here to sweat and make us (the Core Group) rich” – where “rich” means ”loadsamoney”.

At Familiar (and some few other organisations I have read about) the prevailing belief was “the organisation is here to make the employees rich”. Where “rich” means “joyful, fulfilled, flourishing as people and community, having their needs attended to”.

See the difference?

Which scenario would you prefer to embrace?

– Bob

ICYMI: Business Doctrine

In case you missed it:

Business Doctrine

ICYMI: Product Development Flow

In case you missed it:

Product Development Flow

 

Quickie: The Goal

Here we are, nearly forty years after the first publication of Goldratt’s “The Goal“. How many organisations (percentage of all organisations) today have a clearly defined, consensual, well-communicated and well-understood GOAL?

Where does your organisation stand on this?

What Orgs Want

Or, more accurately, what organisations need. (Wants and needs are very rarely the same thing).

First off, does it make any sense to talk about what an organisation might need? Sure, we can discuss the needs of the various groups within an organisation – the Core Group, the shareholders, the employees, and so on. And the needs of the individuals involved – not that the subject of individual needs get much airtime in the typical organisation.

NB I recently wrote a post about the needs of some of these groups in “Damn Outcomes!”.

Back at the main theme of this post: what might be the needs of a given organisation?

Well, like individuals, we make sweeping generalisations at our own risk. At least for individuals, we have some guidance in the form of Maslow’s hierarchy of needs.

From the perspective of Organisational Psychotherapy, an organisation’s needs, whilst fundamental, rarely receive much overt attention. In the course of the therapeutic relationship, the organisation itself may come to a clearer awareness of its own (collective) needs. Those needs may even change and morph as they emerge, become more explicit, and become a valid topic for dialogue and discussion (i.e. ”discussable”).

But we have some basic options for consideration re: the possible needs of an organisation. I wrote about these options some time ago now, in a post entitled “Business Doctrine”. Extrapolating from that post, here’s some possible business (organisational) needs:

• The need to create and keep customers (Drucker)
• The need to supply goods and services to customers (serve the needs of the customer) (Drucker)
• The need to provide a service (Burnett)
• The need to provide a product or service that people need and do it so well that it’s profitable (Rouse)
• The need to act as a nexus for a set of contracting relationships among individuals (Jensen and Meckling)
• The need to optimise transaction costs when coordinating production through market exchange (Coase)
• The need to serve society (McLaughlin et al)
• The need to maximise the medium-term earning per share for shareholders (US business schools)
• The need to make a profit so as to continue to do things or make things for people (Handy)
• The need to make money (Slater)
• The need to make a profit (Watkinson Committee)

Given the Rightshifting perspective that the purpose of any given business is more or less unique to a time, a place, and the people involved, we might reasonable say that the needs of any given organisation are also more or less unique to a time, a place, and the people involved.

Summary

To sum up: I choose to believe that organisations, collectively, do have needs. Each organisation is different – it has its own, different and sometime unique needs. The dialogue involved in surfacing any given organisation’s needs brings benefits in and of itself. Absent clarity on those needs, how can the organisation decide on its priorities, on what matters?

– Bob

Further Reading

The Future Of Software-Intensive Product Development – Think Different blog post

 

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’ needs 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

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours.

Personally I like to call them The Folks That Matter™.

By way of example, Here’s a partial list of the groups and individuals that are candidates for inclusion in the set of The Folks That Matter™.

• Your organisation’s Core Group
• Your manager
• Your project manager
• Senior managers and executives
• Your dev team
• Other dev teams
• Ops people
• The PMO
• Testers (when separate from the dev team)
• QA folks (when present)
• The Process Group (when separate from the dev teams)
• Your business sponsor(s)
• Other people across your organisation
• Your (end) customer(s) (and their purchasing departments)
• Commercial partners
• Regulators
• Wider Society
• The Planet (Gaia)

The Interesting Angle

For me, when I’m involved building stuff, I have a need know who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to. I need to know what folks need, and who to ask about the details of those needs, if and when the detail moves to front of mind. I need to know whose needs we can successfully discount when the inevitable resource (time, money, effort) crunches come. Whose needs we can reasonably consider as outside the scope of the endeavour in which we’re involved? And I need some heuristics to guide us in decisions on including, excluding and prioritising folks and their needs.

But there’s something much more interesting than who’s on and who’s off the list of The Folks That Matter™, at any given time. The much more interesting question for me, as an Organisational Psychotherapist, is: What governs the choices? How do folks get added to or removed from the set of The Folks That Matter™? Are the means the product of rational thought, discussion and evolution, or maybe they’ve just happened, or been cargo-culted. And what are the consequences of the prevailing means? What impact do those means have on the success or failure of our endeavours? And therefore on our bottom line?

By way of example, here’s some common means for tackling the question of means:

• Consensus
• The Advice Process
• Autocracy
• Dictatorship
• HiPPO
• Cost of Focus

(Aside: Each collective mindset in the Marshall Model has its own popular choice for these “means”: Autocracy for the Ad-hoc, Dictatorship or HiPPO for the Analytic, Consensus or the Advice Process for the Synergistic, and e.g. Cost of Focus for the Chaordic).

Is it helpful for folks on the dev team to be involved in some way in maintaining or keeping the list of the The Folks That Matter™? Is that possible, in any given organisation? Is the question even discussable?

When Resources Are Limited, Some Folks, Needs, HAVE To Not Matter

And what about the folks that don’t matter (that don’t appear in the set of The Folks That Matter™? I know many readers will baulk at the idea that some folks and their needs don’t matter. But, please, get over yourselves. In any situation where resources are constrained (i.e finite, not infinite), choices HAVE to be made. Lines drawn. Resources committed to some areas and held back or withdrawn from others. How could it be otherwise? Inevitably then, in this particular frame, there must be Folks Who Don’t Matter™.

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of prioritising one feature over another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above. The question of Cost of Focus.

By definition, we are not meeting some needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong, and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact, on the outcomes we hope to achieve, arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding whose needs to attend to, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Who Really Matters ~ Art Kleiner

Not Obviously Wrong

What’s obviously wrong in software and product development? The list is continually changing, but here’s some stuff which was not obviously wrong ten or twenty years ago, which has recently become obviously wrong, at least to many people in the world of software development:

Obviously Wrong

• Big batches and queues of work (aka Waterfall)
• Utilisation (i.e. keeping resources fully busy)
• Ignoring stakeholders (a.k.a. The Folks That Matter™)
• Big Design Up Front (BDUF) (a.k.a. long feedback loops, or none at all)
• Violence in the workplace
• The daily commute

And here’s a list of stuff which has not (yet) attained the status of “obviously wrong” – and so appears in the list labelled “Not Obviously Wrong”:

Not Obviously Wrong

• Estimating (see: #NoEstimates)
• Management
• Command and control
• Telling (ordering) people what to do
• Leadership
• Specialisation
• Cost accounting
• Projects (see: #NoProjects)
• Big developments in big chunks with big groups of people
• Ignoring the costs of delays
• Testing (a.k.a. inspection)
• Demanding compliance to defined ways of doing things (a.k.a. process dogma)
• Separating ownership of the way the work works from the people that do the work
• Agile
• SAFe
• Scrum
• Kanban Method
• Ignoring the Cost of (misconceived) Focus
• Work (as contrasted with e.g. Serious Play)
• Open plan offices
• Local optimisations
• Dress codes (suits, ties, etc.)
• etc.

How do items get to move from the one list to the other? (note: everyone has their own two lists, and each item moves at different times for different folks). How do your two lists look, at the moment?

Unlearning

Looking at this another way, the obviously wrong list above has items that, although once not obviously wrong, now appear on many folks’ obviously wrong list, having made the transition through e.g. a process of reflection, evaluation, discussion and above all UNLEARNING.

No Hashtags

FWIW, it occurs to me that we might choose to regard the raft of #No… hashtags on Twitter as opportunities to consider in which of our own – and others’ – lists the related (hashtagged) topic appears.

– Bob

Business Development

The word “development” in the phrase “business development” has always meant something very different than in the phrases “product development” or “software development”. The term “business development” is generally taken to mean finding new customers, building customer relationships, and such like. And thus responsibility primarily resides in the Sales & Marketing silo.

Maybe this is one reason why the idea of “developing” a business, in the same sense as developing a product or a software system, is pretty much unknown to business folks. Many’s the time I have invited business folks to consider the merits of taking a “development”approach to the construction and evolution of their business, only to receive little response other than a sea of blank faces.

Which makes me sad, because there’s an enormous amount of “development” practice, expertise and skills available to apply to the challenges of developing a business or other organisation. I’d say that some 80% of the know-how involved in developing products or software systems is directly applicable to “developing” an organisation.

Have you ever suggested to business folks that “development” know-how could have a massive impact on their bottom line? Or otherwise effectively meet many if not all of their core needs? What kind of reactions have you seen?

– Bob

Further Reading

What, Exactly, Is Business Developoment? ~ Scott Pollack
Prod•gnosis In A Nutshell ~ FlowchainSensei

I Love To Play With Organisations

Having churned through many, many strap lines and personal branding statements over the past few years, I feel I’ve finally found one I like. One I can live by, and attempt to live up to:

“I love to play with organisations.”

I accept it’s a statement open to interpretations other than the one I have in my head. And maybe that ambiguity is a positive, in any case.

It’s The People

To clarify, I love to be involved with communities of people, contributing to what’s alive in those communities and in the people that make them up. I find joy in making and sharing relationships. And in attending to the needs of others. And some joy when that’s reciprocated, too.

I choose to call the nature of my involvements “play”. I accept the risk that some might choose to regard this as frivolous. I’d very much like to rehabilitate the idea of play as something positive, weighty and valuable.

“Accept the fact that we have to treat almost anybody as a volunteer.”

~ Peter Drucker

And what are volunteers but folks who want to play at what they’ve volunteered for?

In Practice

In practice, playing with organisations, for me, means getting involved with people as they work – or better, play – each day. Listening to how they feel and what they guess they and their communities might need.

Playing together with them to see and explore together how their individual needs dovetail into the needs of the communities in which they live, work, and play. And asking the odd (sic) question here and there to invite folks to consider if their current assumptions and modes of working/playing/living best suit their needs, or if there may be other ways, more effective ways, to do that.

I’d go so far as to declare my support for Marshall Rosenberg’s suggestion:

“Don’t do anything that isn’t play.”

~ Marshall Rosenberg

– Bob

Further Reading

Serious Play ~ Michael Schrage
LEGO Serious Play ~ The LEGO Group

Twelve Signs Of A Great Agile Evangelist

1. Don’t Talk About Agile.

The first rule of evangelising Agile is: You do NOT talk about Agile. The only folks who want to hear the word – or the gory details – will be those who are looking for a badge of some kind. Or for bragging rights at the golf club. Or tyre-kickers. Strong prospects will not be interested in the label, or the details, but rather in the fact that you understand and care about their problems (empathy) and have useful – and proven – solutions for them to apply. Some of these useful solutions may involve Agile things. Shhh. For example: Talk about their business issues, and the issues common to their business domain. Telcos might be interested in better customer service, and better customer experiences when using their online services, apps, etc..

2. Know Your Cause

“Doing Agile” is not much of a cause, really. Even “being Agile” doesn’t quite cut it. Why are you enthused by Agile? Personally, I see it as a means to move folks closer to a workplace – and a way of working – that allows those folks to realise more of their potential and get more of their needs met – whilst seeing others’ (customers, suppliers, managers, shareholders) needs better met, too. For example: “Effective agile means people more engaged with their work, more focussed on our customers – and our customers more engaged with our products.”

3. Get down with your motivation

Whatever it is that motivates you, embrace it. People can sense half-heartedness and dilettantism. For example: “We’ve seen major steps forward in happier workers, and organisations which are a joy to work in, and with.”

4. Work With Fertile Soils

Plant your cause’s seeds in fertile minds. With folks that are ready or at least willing to listen. If they think they know what their problems are, and that their existing strategies are good for addressing those problems, don’t waste your – or their – time. There will be a few folks who are either unaware of their problems – these may listen, or aware but dissatisfied with their current strategies (solutions). For example: Engage with new prospects, equipped with a checklist of those things that you believe signify fertile soils. Make it an early priority to gather the information needed to complete the checklist. If a new prospect rates poorly on the checklist, decline their kind offer to take things further.

5. Connect To Folks’ Needs

Make your cause relevant and specific to individuals and their existing needs. Help them see how your cause is a more effective strategy for them than their existing ways of working, and thinking. Of course, to connect with folks’ needs, you’ll have to attend to (explore) those needs. For example: Ask your contacts in the organisation what they need. Enquire as to whether there might be others they could suggest with whom you might have similar conversations. Discuss how new ways of working might address some of their needs, individually and collectively.

6. Supply Metastrategies

Many folks need help in acquiring a suitable metastrategy or two before they can move on from their existing strategies and adopt the one(s) you are proposing.

7. Be Honest About The Pitfalls

In many sales situations, standard advice is to avoid talking about the negatives. In Agile adoptions, avoiding mention of the pitfalls only sets up the client for failure. As DeMarco and Lister said in Waltzing With Bears “Risk Management is Project Management for grown-ups”. Maybe your audience has few to no adults? Then RUN! For example: Talk about the rates of failure (generally estimated at somewhere between 50% and 95%). Talk about the common failure modes (faux agile, management discomfort and resistance, change fatigue, organisational cognitive dissonance, etc.). And talk about some possible mitigations for those common modes.

8. Talk About The Benefits

What are the benefits? Not the old chestnuts of “faster, cheaper, quicker”. But benefits that directly address their own particular specific pain point(s). For example: “I understand your biggest competitor can add major new features to their flagship product in six weeks or less. With the necessary changes, we believe that your team could do the same, in timescales as short as two weeks.” In my post “Pitching Agile” I describe using The Three Box Monty as a sales tool in “selling agile” to executives.

9. Make The First (Or Next) Step A Small One

The Kanban Method, for example, cunningly says “start where you are”. Although this begs the question – where else could one start? In any case, engage the prospective client in discussing options and help them come up with their own way forward. For example: Visualisation (of a part of the current workflow) or explicitly limiting work-in-progress (recognising current implicit limits) might be places to start.

10. Don’t Try To Motivate People

Rah-rah motivational speeches and miraculous stories are best left for the God Squad. They have an audience that responds to that kind of thing. Use empathy rather that motivation.

11. Be Organised

Wow. Really? Not “appear well-organised” But actually be well-organised. For example: Have standard templates, checklists, and other documents and planning tools ready and to hand for each new prospect. Keep track of contacts, needs, dates, conversations, and so on. Again, clients and prospects can tell when you’re organised.

12. Be Humble

Don’t proselytise dogma. Don’t make grandiose claims. Don’t make any claims at all. Not even when you have ironclad evidence. Evidence rarely sways anyone. Great evangelists connect with people, and their existing needs. If what you’re selling isn’t what they need, then smile, wish them well, and move on.

– Bob

Further Reading

The Art Of The Start ~ Guy Kawasaki
The Art Of Evangelism ~ Guy Kawasaki
Value Forward Selling ~ Paul DiModica

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

Capability

There’s an old saw that goes:

“If you want to make a great product, build a great team and they’ll make the product for you.”

From my observations, few organisations subscribe to this homily. I’ve always wondered why.

Is it that organisations don’t want to make great products? I’ve certainly seen some of those. Organisations where everyone is just getting by. Keeping their heads down. Expending little if any discretionary effort. Today it seems trendy to call this “disengagement”.

Or maybe it’s just too much trouble. Building a great team rarely just “happens”. People, from senior managers through to the teams themselves, generally have to put a lot of effort over a sustained period to build a great team. And what happens when the product is delivered and the team disbanded? Like the labours of Sisyphus, we start all over again? That seems a demoralising prospect, to say the least.

Or is it that organisations just don’t believe it? That they don’t see a connection between great teams and the capability to build great products?

Or, perhaps it’s not even on the organisation’s radar. That people might believe the old saw, if they were paying attention to it, but because so many other things take priority, the question of i.e. a strategic capability for product development, or even just software development, doesn’t come up? Doesn’t get considered, discussed, acted upon?

Or, maybe organisations are still stuck in the past, not believing that this software thing will catch on, and that the product thet’re creating at the moment is the last one they’ll ever be call upon to make? Why invest time and effort on building a capability that has only one project – the current project – in which to provide a return on investment?

Or maybe any one organisation just can’t serve two masters. That organisations focussed on delivering products to market just can’t focus simultaneously on building a capability for the future, too.

Or maybe there’s not enough money to make it happen. Like any investment decision, the money has to come from somewhere. Short-termism seems endemic in many organisations, particularly the larger, publicly-listed ones. Jam tomorrow never looks as attractive as jam today.

Or perhaps the organisation has no faith in its being able to keep its people, and thus no faith in its ability to sustain any improvements in its capabilities. Perhaps its business model is predicated on high staff turnover, low wages and the idea that “people are merely cogs and resources”. Where this is true – and I have seen some organisations that think like this – then it might be an entirely rational response neither to invest in people as individuals, nor in the organisation’s capability as a whole.

Whatever the reason, I see organisation after organisation where people are stressed beyond endurance because the organisation is not up to snuff in its ability to deliver new products and product enhancements effectively.

I can’t fathom why this is so widespread, and so persistent – and yet I wish I knew.

– Bob

Afterword

Actually, if we look at the issue though the lens of the psychologist, we might suspect that the current situation is a product of people – and especially the Core Group – getting their needs met, albeit in sub-optimal ways. Do Core Groups not need their organisations to have an effective software or product development capability? Given the many ways I have seen organisations degrade or destroy their capability over time, I think this is a valid question.

No Testing

Testing. Checking. Inspection. Exploration. Learning. Everybody has a different understanding of what testing is. And is not. (Hint: AFAIC, it’s NOT “QA”. And it’s NOT “TDD”).

I’m not going to upset people by offering my own definition. I make no claims to be an expert on testing.

When I’m a customer, I know I don’t want to pay extra just for a product that works as advertised. By extension, I’d not want to pay for testing. I want a product that “just works”. And if asked to pay more, I’d have to enquire skeptically “why can’t you people build it right in the first place?”.

Some years ago now, David Anderson wrote a blog post asserting that “All testing is waste”. I concur. But is it necessary or unnecessary waste (Type I or Type 2 Muda?). And does that categorisation depend on the capabilities of the team(s) – the developers – building the software? If the developers can’t deliver software with the intended levels of defects (which could be non-zero, btw) then maybe testing is a necessary waste, to compensate for that inability. And maybe it’s cheaper and more humane to employ less capable developers, bolstered by testers, than to have capable developers who can meet intended defect levels reliably.

So, do we have to test, despite the customer being unkeen to pay for it? Despite it adding little or no value from the customer’s point of view? Or can we find other, more economic and humane ways to meet the needs testing currently addresses?

Needs

“Testing” is one strategy for getting folks’ needs met. Some of their needs, at least. We might imagine there could be other strategies for getting those same needs met.

What needs does testing address? And who has these needs?

• Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.
• Customers need stuff that works (that meets their needs), for a price they’re willing to pay.
• Companies making stuff need to safeguard their reputations and revenues.
• Managers generally need to appear capable of delivering new products which meet the company’s and customers’ needs, whilst also controlling margins (costs vs returns).
• And of course every individual may have their own particular personal needs, too.

Strategies

My question is: “Is testing the best strategy for meeting all the above needs?”. It may be the best known. The most widespread. The default. But is it the most economic? The most humane? Indeed, what are the dimensions of “best” here? Or even of “reasonably effective”?

“No Testing” attempts to flag up these questions. No soapbox. Just open enquiry.

– Bob

 

 

 

 

 

Dancing With Entropy

In a post last year, I wrote about the nature of product development, describing its essence thus:

“The essence of product development is an intense and ongoing struggle between organising intent and entropy. Organising intent is the will of the company, manifest in the actions of its product development people, bent on meeting the goals of the company through the creation and evolution of products and product features.

Product development is fundamentally an interactive social process. We might imagine a randori situation (freestyle Aikido training) with a uke (receiver) and nage (thrower), each attempting moves and countermoves to try to defeat the other. Product development is thus a process of continuous adaptation to events, of give and take, simultaneous synthesis and dissolution. While we try to express our organising intent in the product, entropy resists us and seeks to countervail our intent. Appreciating this dynamic interplay between organising intent and entropy is essential to understanding the fundamental nature of product development.”

I suspect some folks, reading this through a certain frame, might interpret “entropy” to mean complexity, chaos, or complicatedness. And therefore, interpret my description of product development as essentially being about reducing complexity, avoiding complicatedness, or otherwise attempting to impose some order upon chaos.

This was not my meaning. I chose the word entropy carefully, although not, perhaps, carefully enough.

“Entropy: A measure of disorder in the universe.”

My frame for this choice was e.g. “the heat death of the universe”, and the widely-known quote, re the Second Law of Thermodynamics:

“The entropy of the universe tends to a maximum.”

~ Rudolf Clausius

It’s been my experience that the entropy of a software-intensive product development effort also tends to a maximum. And our task, if we wish to actually deliver something useful, is to recognise this and to find an accommodation to this “Law”.

Anywho, let’s not get hung up on the term.

My intent was to convey the idea that, in product development as much as in war, Friktion and the Fog of War both serve to frustrate the best laid plans of organising intent. Indeed, Clausewitz invented the term Friktion to describe the “resistant medium” in which war – and business – must operate.

To paraphrase Clausewitz:

“Everything in product development is very simple, but the simplest thing is difficult. In product development more than anywhere else things do not turn out as we expect. Close up, things do not appear as they do from a distance.”

For me, Clausewitz’s Friktion is “the only concept that more or less corresponds to the factors that distinguish real product development from product development on paper.”

However, Clausewitz suggests we tackle – or offset – Friktion through acts of willpower. Some business books have referred to this as “Grit”.

I’m a Lover, Not a Fighter

Here, I beg to differ. I’m much more of the opinion that, as with Aikido’s uke and nage, we would do better to learn to accommodate ourselves to Friktion (a.k.a. entropy). To embrace it, to walk with it, care for it, engage with it, and ultimately to dance with it. To regards it an asset. And yes, to love it.

“When the wind of change blows, some build walls, others, windmills.”

~ Chinese proverb

There’s a point in the book “Ender’s Game” where Ender The Genocide, having eradicated humanity’s implacable foe (the Formic race), explains:

“In the moment when I truly understand my enemy, understand him well enough to defeat him, then in that very moment I also love him. I think it’s impossible to really understand somebody, what they want, what they believe, and not love them the way they love themselves. And then, in that very moment when I love them…. I destroy them.”

~ Orson Scott Card, Ender’s Game

I feel very much the same way about entropy. In the moment when I truly understand it, understand it well enough to defeat it, then in that moment I also come to love it. At that moment, I no longer wish to defeat it, but to dance with it. To build great products together, entropy and I.

– Bob

Further Reading

Friction of War ~ Clausewitz Condensed
It’s a Lot Like Dancing: Aikido Journey ~ Terry Dobson
Product Aikido: The Exemplar Doctrine ~ FlowchainSensei

 

Principles WTF

“Hey. Why don’t we write down some principles?”

“Why?”

“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

GDS Design Principles – Improved

I like the UK Government Digital Service Design Principles. For a government organisation, GDS show some progressive thinking and their design principles come close to principles to which I could subscribe. Close, but no cigar.

Here’s my suggestions for principles which I could wholeheartedly embrace:

1. Attend to folks’ needs.
   This improvement seems close to “start with needs”. But why just start? Sounds a bit waterfall-ish to me.

   “Before we begin any project we spend a long time working out what the user needs are.”

   Do people have needs just at the outset of an endeavour? Maybe they mean “Always give priority to (users’) needs.” If so, why not make it clear?

   Why only users’ needs? That seems like missing the fundamental opportunity to build an environment in which (GDS) folks can choose to give of their best.

   And “start with needs” seems to imply design is a linear process, rather than – as I see it – one of evolution, emergence, and continual learning/discovery.

2. Do what’s needed – more more, no less.
   Sometimes, less is more. Sometimes it’s not. If we do what’s needed, and no more, then we’ve done the minimum. Focussing on “doing what’s needed” – taking into account all constituencies and needs – seems better than “doing the most good” (whose good?). And let’s not get hung up on the minutiae of “minimal” page design (see their example) when “minimal” effective services are the aim?
3. Continually Evolve The Service with Quick Feedback and Iterations.
   OK with this one – excepting the wording “Design with Data” which may only serve to confuse, and to cut folks off from relevant pools of existing know-how, such as Lean Startup. See also my (additional) principle 11.
4. Make It Optional.
   One of the things that really gets my goat with “Digital by Default” is that it so often means “Digital only”. I won’t go into the folly of believing that digital aka online Government Services are cheaper to provide or meet folks’ needs better, by default. Better, I suggest, to make the digital option truly optional, and follow the data to learn if the digital option is the most popular option. Let folks vote with their feet!
5. Flow.
   “Iterate” is a bit of a duplicate of 3. This principle seems more about highlighting the idea of continual flow of value. I.E. No service has a beginning or end, but just a continual flow of ever-improving delivery of “meeting people’s needs”. “Launch” happens every day. Maybe dozens of times per day.
6. Build for Inclusion.
   Great principle. Hard to do when Digital By Default – “The people who most need our services are often the people who find them hardest to use” (and those who least want to use a computer to access them?). Is this issue even discussable?
7. Understand Context.
   Ditto with 6.
8. Build Services, not Digital Services.
   Granted this is not within the purview of the Digital Teams themselves, whose raison d’etre is to build Digital Services. But I believe this can change, given the will.
9. Derive Consistency From Needs.
   If needs are understood, and the trade-offs of consistency also understood, than it’s possible to decide when consistency is beneficial, and when it’s a drag.
10. Make Things Open.
    Including dissent, discussion and debate – and those topics that remain undiscussable. 😉
11. Build Improvement Into the Way the Work Works.
    Some of the original list of UK Government Digital Service Design Principles speak to improving government (digital) services as experienced by users. But I see no explicit mention of improving the way the work works. I’m sure all the smart folks in GDS are pursuing improvements to how they work, so why not recognise and honour that with its own principle? Moreover, make explicit the principle of in-band continuous improvement – to help avoid the dysfunctional anathema of e.g. change programmes, improvement teams, and so on.

– Bob

Further Reading

Sketching User Experiences: Getting the Design Right and the Right Design ~ Bill Buxton