Archive

Management

Management Monstrosities

Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question: 

“Why do so many well intentioned founders and companies end up creating management monstrosities?”

The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and Rightshifted outliers are known to be).

But Michele’s question is: “Why?”

Over twenty years and more, I’ve seen dozens of organisations up close and personal.  In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.

Category Error

Collaborative knowledge work is NOT like:

  • Factory Work
  • Manufacturing
  • Office work
  • Service work (e.g. Call centres, Help desks, etc.)
  • Individual knowledge work

Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.

Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.

Assumptions and Beliefs

Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are never aligned to effective working.

You may now be asking “Why is the category they assign (almost) never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).

– Bob

Cost of Focus Revisited

[Recent conversations suggest that my post on Cost of Focus failed to explain the idea clearly enough for readers to grasp easily or quickly. As, for me at least, it’s a simple idea, I thought I’d summarise it in brief with a new post (this one).]

Cost of Focus

Let’s start with a definition in a nutshell:

Cost of Focus is the cost incurred when we fail to include key stakeholders* in our deliberations**.

* I generally refer to these folks, collectively, as The Folks That Matter™.
** By deliberations, I have in mind what old-school folks call “requirements capture” or “requirements analysis”, and what I, nowadays, refer to as “needs investigation”.

Put another way:

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.

Note: I could have chosen the name “Cost of Flawed Focus” (the cost of focussing on less relevant stakeholders and less relevant requirements), but this seemed a little less snappy than “Cost of Focus”.

Typically, the costs in question accrue from rejection of part or all of the delivered project / system / product / software application by one or more key parties (such as users) whose needs have not been adequately addressed  – and these costs can be massive. In any number of cases, whole systems have had to be abandoned because one or more key stakeholder groups have refused to use the new system. And even when not totally abandoned, oftentimes major costs have accrued from the delays and extra work required to remediate the original errors of focus. (See also Cost of Focus’ kissing cousin – Cost of Delay).

The Folks That Matter™

[The following excerpt first appeared in my blog post The Folks That Matter™. I repeat it here for the convenience of the reader:]

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of delaying a given feature by prioritising 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, i.e. the question of Cost of Focus.

By definition, we are failing to meet some folks’ 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 (prioritise less valuable features), 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, black-and-white 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 to whose needs to attend, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Cost of Focus ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
Cost of Delay ~ Wikipedia entry

Three Questions

There are three questions I like to ask my clients upon our first meeting. You might find them equally useful in your own dialogues within your particular organisation. Here are the three questions:

1. Is anyone in your organisation at all interested in productivity (or quality, or effectiveness)?

Note: Many folks will express an interest in productivity, quality or effectiveness, but not act congruent with this espoused interest. You might like to look into the work of Chris Argyris to learn more about this phenomenon (see: espoused theories vs theories-in-use). You may also care to look at what’s really happening within the organisation for evidence of actual interest in e.g. productivity.

If your true answer to question 1 is “no”, then there’s not much point proceeding to the next question.

But if there are folks in your organisation at all interested in productivity (or quality, or effectiveness), then question 2 is:

2. Do all interested parties agree that folks’ collective assumptions and beliefs about work, the world of work, and how work should work is at the root of effectiveness a.k.a. productivity?

If your answer to question 2 is “no”, then I propose you might like to look elsewhere for your answers, rather than proceed to question 3.

But if there are enough folks in your organisation who can agree that collective assumptions and beliefs about work, the world of work, and how work should work is at the root of organisational effectiveness a.k.a. productivity, then question 3 is:

3. How will you go about affecting this collection of shared assumptions and beliefs – in ways which translate to meeting folks’ needs for increased productivity (or quality, or effectiveness)?

Note: In some organisations, maybe there are already some initiatives or actions in train intended to bring about such a change in shared assumption and beliefs.

I’d be very interested to hear your answers.

– Bob

Beyond Command and Control – A Book Review

BeyondCommand&ControlCover

John Seddon of Vanguard Consulting Ltd. kindly shared an advance copy of his upcoming new book “Beyond Command and Control” with me recently. I am delighted to be able to share my impressions of the book with you, by way of this review.

I’ve known John and his work with e.g. the Vanguard Method for many years. The results his approach delivers are well known and widely lauded. But that approach is not widely taken up. I doubt whether this new book will move the needle much on that, but that’s not really the point. As he himself writes “change is a normative process”. That’s to say, folks have to go see for themselves how things really are, and experience the dysfunctions of the status quo for themselves, before becoming open to the possibilities of pursuing new ways of doing things.

Significant Improvement Demands a Shift in Thinking

The book starts out by explaining how significant improvement in services necessitates a fundamental shift in leaders’ thinking about the management of service operations. Having describe basic concepts such as command and control, and people-centred services, the book then moves on to explore the concept of the “management factory”. Here’s a flavour:

“In the management factory, initiatives are usually evaluated for being on-plan rather than actually working.”

(Where we might define “working” as “actually meeting the needs of the Folks that Matter”.)

Bottom line: the management factory is inextricable bound up with the philosophy of command and control – and it’s a primary cause of the many dysfunctions described throughout the book.

Putting Software and IT Last

One stand-out section of the book is the several chapters explaining the role of software and IT systems in the transformed service, or organisation. These chapters excoriate the software and IT industry, and in particular Agile methods, and caution against spending time and money on building or buying software and IT “solutions” before customer needs are fully understood.

“Start without IT. The first design has to be manual. Simple physical means, like pin-boards, T-cards and spreadsheet.”

If there is an existing IT system, treat it as a constraint, or turn it off. Only build or buy IT once the new service design is up and running and stable. Aside: This reflects my position on #NoSoftware.

John echoes a now-common view in the software community regarding Agile software development and the wider application of Agile principles:

“We soon came to regard this phenomenon [Agile] as possibly the most dysfunctional management fad we have ever come cross.”

I invite you to read this section for an insight into the progressive business perspective on the use of software and IT in business, and the track record of Agile in the field. You may take some issue with the description of Agile development methods as described here – as did I – but the minor discrepancies and pejorative tone pale into insignificance compared to the broader point: there’s no point automating the wrong service design, or investing in software or IT not grounded in meeting folks’ real needs.

Summary

I found Beyond Command and Control uplifting and depressing in equal measure.

Uplifting because it describes real-world experiences of the benefits of fundamentally shifting thinking from command and control to e.g. systems thinking (a.k.a. “Synergistic thinking” Cf. the Marshall Model).

And depressing because it illustrates how rare and difficult is this shift, and how far our organisations have yet to travel to become places which deliver us the joy in work that Bill Deming says we’re entitled to. Not to mention the services that we as customers desperately need but do not receive. It resonates with my work in the Marshall Model, with command-and-control being a universal characteristic of Analytic-minded organisations, and systems thinking being reserved to the Synergistic– and Chaordic-minded.

– Bob

Further Reading

I Want You To Cheat! ~ John Seddon
Freedom From Command and Control ~ John Seddon
The Whitehall Effect ~ John Seddon
Systems Thinking in the Public Sector ~ John Seddon

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

My Work

My work of the past ten+ years tells executives, managers and employees:

  1. What is the root of the problems in their organisation
  2. What to do about it (how to fix it)
  3. Why they won’t do anything about it

The Root of the Problems

The root of the problems in your organisation is the collective assumptions and beliefs (I generally refer to these as the collective mindset) held in common by all people within the organisation. Most significant (in the conventional hierarchical organisation) are the assumptions and beliefs held in common by the senior executives. In the Marshall Model I refer to the most frequently occurring set of collective assumptions and beliefs as the Analytic Mindset.

In knowledge-work organisations in particular, the Analytic Mindset is at the root of most, if not all, major organisational dysfunctions and “problems”.

What to Do About It

The way forward, leaving the dysfunctions of the Analytic Mindset behind, is to set about revising and replacing the prevailing set of collective assumptions and beliefs in your organisation with a new set of collective assumptions and beliefs. A collective mindset less dysfunctional re: knowledge work, one more suited to (collaborative) knowledge work. In the Marshall Model I refer to this new, more effective set of collective assumptions and beliefs as the Synergistic Mindset. Yes, as an (occasionally) rational, intentional herd, we can change our common thinking, our set of collective assumptions and beliefs – if we so choose.

Why You Won’t Do Anything

You may be forgiven for thinking that changing a collective mindset is difficult, maybe impossibly so. But that’s not the reason you won’t do anything.

The real reason is that the current situation (the dysfunctional, ineffective, lame behaviours driven by the Analytic Mindset) is good enough for those in power to get their needs met. Never mind that employees are disengaged and stressed out. Never mind that customers are tearing their hair out when using your byzantine software products and screaming for better quality and service. Never mind that shareholders are seeing meagre returns on their investments. Those in charge are all right, Jack. And any suggestion of change threatens their relatively comfortable situation.

So, what are you going to do? Just ignore this post and carry on as usual, most likely.

– Bob

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Red Lines

There’s been a lot of talk about Theresa May’s “Red Lines” in the media recently.

Every organisation I’ve ever known has had their own Red Lines – ideas, principles, practices and policies which are deemed unacceptable, beyond the pale. Many of these latter would make the organisation markedly more effective, efficient or profitable, yet are ruled out.

Here’s a list of such ideas, in roughly increasing order of benefit and unacceptability both:

Transparency of salaries
Attending to folks’ needs
Nonviolence
Restorative justice (vs Retributive justice)
Self-organising / self-managing teams
No estimates
No projects
No tools
No software
Defect prevention (ZeeDee) approach to Quality (vs Testing / Inspection)
Employees choosing their own tools, languages and development hardware
Employees designing / owning their own physical workspace(s)
(colour schemes, lighting, furniture, floor plans, drinks machines, games etc.) 
Employees choosing their own ways of working (methods, processes)
Organising to optimise Flow (vs costs)
Employees choosing their own working locations (office, cafe, remote, etc.)
Employees choosing their own working hours (incl. hours per day / week)
Employees forming their own teams
Employees guiding their own training and career, skills development
Employees hiring their own peers (and coaches)
Paramountcy of interpersonal relationships and social skills (vs tech skills)
Organisational Psychotherapy
Teams appointing their direct managers
Teams appointing their senior managers
“Open book” financials
Employees choosing their own salaries and terms of employment
Teams awarding themselves their own bonuses
No managers (alternatives to control hierarchies)
Fellowship (No positional leadership)
Do nothing that is not play

Where does your organisation draw its red lines – and how much more effective could it be if it redrew them?

– Bob

 

Congruence

What if the last twenty years has been another classic example of software developers solving the wrong problem?♥

What if “agility” was never the issue as far as business was and is concerned? What if business agility is NOT the most useful response to, or strategy for, life in a VUCA world?

We hear so much about the need for agility. It’s now a given, an unchallenged assumption. Maybe even an undiscussable assumption? Well, I’m challenging it. And in the spirit of this blog – always having an alternative to offer – I propose congruence as a more useful response to the challenges of a VUCA business environment.

Agility: the power of moving quickly and easily; nimbleness.

Congruence: Similarity between self-image and actual experience.

Carl Rogers stated that the personality is like a triangle made up of the real [or actual] self, the perceived self, and ideal self. According to Rogers, when there is a good fit between all three components, the person has congruence. This is a healthy state of being and helps people continue to progress toward self-actualisation.

Applied to organisations, we can say that an organisation is made up of the real [or actual] organisation, the organisation as it perceives itself, and its ideal self. When there is a good fit between all three components, the organisation has congruence. This is a healthy state of being and helps the organisation progress toward being all it can be.

Without congruence, organisations won’t know what to do with agility, or how to get it. Without congruence, a VUCA environment presents challenges which incongruent organisations are poorly equipped to meet.

So, forget the past twenty years and the search for agility. Congruence is the thing.

– Bob

Footnote

♥ It was a bunch of software developers that invented and promoted the idea of agility (for software development) some twenty years ago now. Businesses everywhere have seized on this prior art in their attempts to cope with the upswing in perceived volatility, uncertainty, complexity and ambiguity in the business environment.

PS

The same argument also applies to the birthplace of the agility meme: the software development silo. Forget the past twenty years and the search for development agility. Congruence is the thing.

Management Must Manage

Years ago, when I was starting out in my study of management methods, I came across ITT and its then president, Harold S. Geneen. Setting aside his connection with Phil Crosby and the ZeeDee (Zero Defects) quality movement, Geneen was famous for many things, including one quote which has stuck with me ever since I first heard it:

“Management must manage.”

What a soundbite!

Taken at face value, it’s a homily. Management must manage. Those with management responsibilities must execute those responsibilities (rather than dicking around with other things). “Well, of course. What else would they do?”

But there’s another meaning I choose to also find within. Management must manage: when we have people appointed to management positions, those people are the ones that must manage, not some others.

The whole Agile shambles, most often labelled AINO (Agile In Name Only), stems largely from ignoring this second interpretation of Geneen’s admonition.

Early Agilists, wanting to escape from the oversight of managers who had different opinions about how to manage software development, created Agile to wrest de-facto management responsibility from those managers. Thus grew the lame-assed version of self-organisation and self-managed teams so widespread today. I say lame-assed because almost no Agile team is self-managed. How could they be, when managers still have the authority and positional power to manage?

So we have instead a festering conflict of responsibilities, causing confusion and resentment all around, and dragging down engagement and productivity. Agile can “work” when the split of management responsibilities are made crystal clear for all concerned. And when that split has the blessing of management. This is almost never the case.

So, management must manage. Not developers. Not dev teams.

That sucks. Until we realise that it can be no other way. And even then, it still sucks, unless dev teams themselves have the responsibility and authority to manage. Where the dev teams are the management. Then we have the best of both worlds. A world of autonomy, mastery and purpose. A world of engaged people aligned to a common purpose and a common approach.

– Bob

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

Cost of Focus

Or, more specifically, the cost of suboptimal focus – the cost of focusing on some (less relevant) needs of some Folks That Matter to the detriment or neglect of other (more relevant, valuable) needs of other Folks That Matter.

If we commit our (always limited) resources ineffectively, our returns (we might call this ROI) will likewise fall short of what would be possible if we committed our resources more effectively, or optimally.

How Do We Decide?

How we as a individual, team, group or organisation decide who we’re trying to please, delight, satisfy, or otherwise engage with and deliver to?  How do we get to know what folks need, and who to ask about the details of those needs? How do we choose whose needs we can successfully discount or defer when the inevitable resource (time, money, effort) crunches come? Who matters and who does not? Which needs are more relevant, valuable (with respect our chosen Goal) and which, less?

Might it be useful to have some heuristics, or policy, or other forms of guidance, to guide us in decisions on including, excluding and prioritising folks and their needs? Personally, if it were entirely up to me, I’d go with the general principle describe by Goldratt and summarised in my post “What is Value?“.

By way of a quick summary of that post:

Focus on those things that relax the customers’ constraint, so as to increase the overall throughput of their business (a.k.a. “Mafia Offers”). And focus on the customers, or market segments, that you understand best – or at least can work with to find such understanding.

Our aim: to optimise the Needsscape a.k.a. the needs we meet (for example, need for revenue, profit, cost reduction, etc. often sits at top of mind).

Relevance For Workers

This post is not just about decisions made by executives and managers. Everybody has the same dilemma: how do I/we decide where to focus? Which code module would it be better to deliver first? Which tests are more valuable that others? Who would it be better to work with first, to understand their needs (a.k.a. constraints, requirements, or whatever)? Where we choose to focus absolutely determines how others see us and our efforts.

Bottom Line

The bottom line is: the more effective we are at focussing on things that contribute to our personal or business goal (Cf. Goldratt), the more of our goal we’re likely to get. (Is that self-serving? Only if our goal is self-serving. Choose wisely).

– Bob

Further Reading

The Goal ~ Eliyahu M. Goldratt
It’s Not Luck ~ Eliyahu M. Goldratt
Focus ~ Think Different blog post
What is Value? ~ Think Different blog post

The Folks That Matter™

Stakeholders, team members, the Big Team, customers, users, stakeholders – 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), choice 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

Wants, Needs

My previous post seems to have struck a chord, judging by the number of retweets on Twitter. It also presents an opportunity to explore a perennial challenge of building things for other people: teasing out real needs from expressed wants.

Have you ever worked with business folks who articulate their wants in the form of solutions, rather than as solution-free “requirements”? As means rather than ends?

Let’s take another look at the list of desired outcomes (wants) appearing in the aforementioned post:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement

Business Analysis for the Way the Work Works

From my days as a Business Analyst, I’ve learned that uncovering needs means having an ongoing dialogue with the people that matter. A dialogue in which we dig down, together, into the things they say they want, so as to uncover their real needs. Once we’ve teased apart the wants from the needs, we’re in a better place to choose effective strategies (solutions) for addressing those needs. Going with the superficial wants tends to box us in to the strategies (means) they provide. Strategies which often fall short of being effective.

I suspect what I’m talking about will become clearer as we examine in turn each item from the above list…

Item: A more coherent, disciplined approach to software development

This looks to me like a solution masquerading as a need. That’s to say “a more coherent, disciplined approach” seems like more like means to other ends, than and end in itself. What might those ends be? What might be the underlying needs driving this proposed solution? A dialogue with the people that matter seems in order here. A dialogue that could prove challenging, absent a degree of trust and willing collaboration. And even assuming we are all able to dig down towards the underlying needs, just as in building software there’s no guarantee we’ve identified those needs accurately, until we’ve built and delivered something and seen it “in production” long enough to gather some feedback. Active feedback, which also implies iteration and evolution: “Is this really meeting the needs of everyone that matters? Is it good enough yet? What else do we need to do to improve it further?” etc..

For illustration, I’ll take a stab at the needs which might underlie this want. Maybe some folks suppose that “a more coherent, disciplined approach” will bring order to the present chaos (a need for order). Maybe some folks suppose that “a more coherent, disciplined approach” will make delivery of e.g. features or product increments more predictable (a need for predictability).

Maybe productive and effective dialogue will uncover other latent needs implicit in this want.

Item: Improved governance and oversight

This also looks to me like a solution masquerading as a need.

Maybe some folks choose “Improved governance and oversight” as their automatic, default solution (strategy) for bring order to the present chaos (a need for order).

Item: Improved estimates

This again looks to me like a solution masquerading as a need.The No Estimates movement and debate has just about done this one to death. What might the supposed need for “improved estimates” imply. What’s really need here?

Item: Better due-date performance (reliable on-time delivery)

Whilst we could imagine this as yet another solution masquerading as a need, in this case I find this want more interesting, maybe closer to a real need than the previous two items.

I suspect some folks that matter may suppose that “better due date performance” is the obvious means to improve (external) customer satisfaction, and thereby revenue, repeat business, profit, market demand, market share, and other business metrics. Maybe those involved in the way the work works, armed with an explicit, agreed need to satisfy one or more specific business metrics, would be able to come up with ways of working which effectively address those metrics. In other words, valuable innovations.

Item: More visibility into project roadmaps

This again looks to me like a solution masquerading as a need. What might be the underlying need here? Maybe it’s something born of a feeling of powerlessness in the absence of information about what’s happening. Maybe it comes from a sense of frustration or embarrassment when having to face customers and investors expecting information about product release schedules, feature sets, and road maps. Whatever the case, an effective, productive dialogue may flush out some of those underlying feelings, and thereby lead to a better understanding of the needs we’re all trying to address.

Item: Common standards

Yet again this looks to me like a solution masquerading as a need. I’ve heard this want many times in numerous companies. This looks to me like an implicit solution to the question “how do we become more flexible, how can we cost-effectively deploy and redeploy our developers between projects and project teams as business priorities change?” I guess the people that matter suppose that “common standards” is the obvious answer. But it’s our job to understand the underlying need and come up with the most effective solution (strategy) for addressing it, not just the most common solution.

But I could be barking up the wrong tree about the presumed underlying need here, so I’d want to have conversations with the people that matter so as to really understand what they might be trying to achieve through addressing this want.

Item: Better project organisation

Another solution masquerading as a need. What might “better project organisation” bring us? Better due date performance? More visibility into project roadmaps and current status? See explanations, above, for the needs which might underlie *those* wants.

Item: People working “in sync”

Solution masquerading as a need. What might “people working in sync” bring us? Reduction in friction and waste? Improved flow (of products and features into the market)? Better due date performance? By digging down, though dialogue, we may uncover candidates for the underlying needs, which we can proceed to validate through delivering a way the work works, and getting feedback on the degree to which that way of working effectively addresses folks’ real needs.

Item: Senior management confidence (in e.g. the teams’ ability to deliver)

This is probably the one item in our list of sought outcomes that’s closest to a real need. We can intuit the scale of the problem (shortfall in senior management confidence) by looking at all the solutions they’re helpfully trying to provide us with, via the other items here. Solutions (masquerading as needs) that they believe will improve things and thereby deliver the boost in confidence they seek (and need). Ironically, the solutions they provide – being very much less effective solutions than those we can come up with for them, as experts – often undermine the very outcomes they seek.

Item: Higher staff motivation and engagement

Very laudable. But let’s not let the humanity of this want blind us to its nature as (yet another) solution masquerading as a need. What’s the end in mind? Why might the people that matter seek “higher staff motivation and engagement”?

So they can feel better about the culture for which they they feel responsible? As a means to increased throughput and thus improved revenues and profits? Again, until we know what they really need, any solutions we provide will likely fall well short of the mark. In other words, wasted effort.

Summary

So, we can see that taking “sought outcomes” at face value can lead us into sleepwalking into addressing superficial wants, and adopting other people’s (non-expert, relatively ineffective) solutions. Solutions which rate poorly on the effectiveness scale, and which in any case may well be addressing the wrong needs. I find it ironic just how much non-expert interference and micromanagement goes unnoticed, unchallenged and unlamented. Plenty of time for lamentation a year or two later.

Bottom line: When building software, the biggest risk lies in building the wrong thing (getting the requirements wrong), and it’s not any less of a risk when “building” – we might choose to call it “evolving” or even “engineering” – the way the work works.

– Bob

A Hiding To Nothing

Most large companies are on a hiding to nothing if and when they decide they’re “going Agile” for software development. “Going Agile” can only ever deliver the outcomes these companies seek if the whole organisation is prepared to change some of its fundamental beliefs about how organisations should be run.

Sought Outcomes

What outcomes do larger compares typically seek from “going Agile” in their software development teams? Here’s a partial list:

  • A more coherent, disciplined approach to software development
  • Improved governance and oversight
  • Improved estimates
  • Better due-date performance (reliable on-time delivery)
  • More visibility into project roadmaps
  • Common standards
  • Better project organisation
  • People working “in sync”
  • Senior management confidence (in e.g. the teams’ ability to deliver)
  • Higher staff motivation and engagement
  • Shorter timescales (i.e. “from concept to cash”)

Why These Outcomes Are Unrealisable

What’s not to like in the outcomes these companies seek by “going Agile”? Although maybe not comprehensive – they lack, for example, outcomes like “joy in work”, “folks getting their needs met”, “improved flow” and “customer delight” – there’s a bunch of stuff here I could get behind.

Setting aside the observation that some of the above “outcomes” – such as “common standards” and “people working in sync” – are more solutions than needs, “going Agile”, per se, is not the answer for delivering these outcomes. At least, not within the Analytic mindset world view.

Why the Analytic Mindset is the Blocker

With an implicit Theory-X, local optima (manage the parts separately) perspective, any and all solutions attempting to deiver these outcomes through “going Agile” are doomed to undermine the very outcomes sought.

It’s likely to start well, with much interest and hope expressed by the staff. After all, who wouldn’t want more autonomy, more mastery, more purpose in their work? But as things progress, existing company policies, rules, attitudes, etc. will begin to assert themselves. To the detriment of staff morale, motivation and engagement. Pretty soon, staff will begin to question the sincerity of the management in their support for “going Agile”. Pretty soon, it will start to become apparent to anyone who’s paying attention that existing policies, rules, etc., have to change fundamentally to see the outcomes sought begin to happen.

And with declining staff engagement in “going Agile”, and reducing enthusiasm for understanding the principles necessary for making Agile successful, progress will slow to a crawl. At this point, middle-management, who have to carry the burden of making “going Agile” happen will also begin, quietly, to question the wisdom of the senior management direction. This will lead to their more often reverting to orthodox, “tried and tested” (and less personally burdensome) ways of working. And more often baulking at the effort needed to push through adoption of more Agile practices.

What To Do?

So, what’s a company to do? Most companies will not realise, or want to hear, that the Analytic mindset is fundamentally incompatible with successfully “going Agile”. So, another Agile adoption failure is in the making.

Personally, having helped various companies face up to this challenge, I’d say:

“It’s extremely unlikely that you’ll want – or even be able – to give up your existing world view. At least in the short term. So something’s got to give. And it’s probably better that you give up on “going Agile”. But DON’T give up on wanting things to be better. Park your Agile aspirations, and try another path, another solution. After all, it’s the OUTCOMES you seek that matter, not some specific – and cargo-culted – solution.”

So what might that alternative solution look like? What can an unrepentantly Analytic-minded organisation do to improve its software development outcomes?

My recommendation would be to focus on the interpersonal relationships within and between departments. Help developers understand and relate to customers (both internal and external) better. Help other folks within the organisation better understand and relate to developers.

Leveraging these improving relationships, encourage multi-party, cross-function dialogue about the outcomes sought, and what folks of every stripe can do, every day, to begin to shift the organisation’s rules, policies, structures and assumptions.

In a nutshell, be less autocratic, directive and strategic, and more democratic, collegiate and opportunistic.

And remember, I’m here to help.

– Bob

Product Owners Suck

Teams doing Scrum “by the book” will have a Product Owner. The Scrum Handbook describes this role thusly:

“The Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

It goes on to say:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

i.e. the Single Wringable Neck.

Outwith Scrum “by the book”, many teams, Scrum or otherwise, will find themselves with a Product Owner, almost always, in practice, outside the immediate development team itself.

One characteristic common to every Product Owner role I have ever seen has been “push”. The Product Owner pushes work (features, stories, or whatever the unit of backlog) into the backlog, and thus onto the team. The Product Owner generally dictates the priorities of the work items in the backlog, too.

Here’s where the dysfunctions creep in. If we accept that we’d like to encourage intrinsic motivation in the team, and that Dan Pink’s three factors of intrinsic motivation apply (Autonomy, Mastery, and Purpose), then we begin to see how the typical Product Owner stance sucks the motivation away from the team by undermining their autonomy (they’re expected to do what’s pushed on them, with the priorities dictated), their mastery (focus is on delivery not learning), and purpose (the purpose is that of the PO, often opaque or little shared, not a shared common purpose across everyone involved).

Go Pull

I’ve seen clients where this push-oriented Product Owner role has served no one well. Not the Product Owner, nor the development team, nor the product, nor the customers. The Product Owner is worn to a frazzle trying to herd the developers, like cats, towards the outcomes he or she thinks the customers want. It’s most unlikely the Product Owner will know what features are valuable, and how they should work, before stuff gets in front of the customers anyway, and the delays in the “push” model just exacerbate this dysfunction.

Further, in the push model, developers have little opportunity to experiment and innovate. They’re often far better placed than the Product Owner or even the customers to spot opportunities for breakthrough innovations, both large and small, yet the push model basically precludes them from contributing in this way.

So why not turn it around? In my career, I’ve seen all the best products come from development teams that directly own the product. And, consequently, directly own the relationship with the customer. Often, not the whole team, as this might irk the customers – at Familiar we had one member of the development team act as “customer liaison” – a role which could rotate between team members if it started to become a chore for the person in question.

It’s unlikely the Product Owner will wish to do themselves out of a job, so how can we arrange things such that everyone has a better time than with the “push” model? And so we make even better use of the most valuable things the Product Owner has – product domain expertise and customer nous?

In the service (call centre, etc.) sector, Vanguard introduced the idea of front-line call staff taking all the calls, with limited (brief) training to handle the most common types of call, and with experts and specialists on hand to help them through handling the less common types of call as they arrive.

Transferring this idea to the Product Owner role, why not have the development team own the product, take all the decisions about features, stories and priorities – by pulling information from the customers – and whenever the development team has some questions they can’t answer themselves or in conjunction with the customers, have the Product Owner (now Product Domain Specialist or some such renamed role) on hand to pitch in and provide the missing knowledge or expertise.

I guess the Analytic minded organisations out there will feel uneasy about no longer having their hands around the Single Wringable Neck, but learning about Team Accountability might go some way to compensate for this?

So, let the teams suck (pull), instead of having the Product Owner push.

– Bob

PS Note that the above suggestion – to hand over core elements of the Product Owner role to the development team – assumes the development team owns the scope for the whole product, not just the software, and can collaborate and coordinate with other people and groups to ensure the whole product is delivered (whether incrementally for not). See also: Obeya.

Further Reading

The Transformation of O2 – A Vanguard Case Study in Reengineering Call Centres (pdf)

Testbash Dublin and Organisational Psychotherapy

As I mentioned in my previous post, I’m just back from presenting an interactive session on Organisational Psychotherapy at Testbash Dublin. Some folks seemed confused as to the relevance of Organisational Psychotherapy to testers and the world of testing, so I’m happy to explain the connection as I see it. (And please note that many of my previous posts on Organisational Psychotherapy may also help to illuminate this connection.)

I’ll start by riffing on something Rob Meaney said during his presentation:

“Significant quality improvements [aren’t] driven by testing. They [are] driven by building relationships and influencing the right people at the right time.” ~ @RobMeaney #TestBash

Quality (and other) improvements come from improved relationships. This has been a theme on this blog for some years now. For example see: The Power of Humane Relationships.

I asked a key (for me) question during my session (several times):

“If we accept that (as per the Marshall Model) it’s the collective mindset of the organisation that determines its relative effectiveness, how do we propose to support the organisation if and when it choses to do something about its mindset?”

Unsurprisingly perhaps, I heard no answers, excepting my own proposal for a means to that end: Organisational Psychotherapy.

I wonder how many folks involved with testing ask themselves and their peers the question “How can our organisation become more effective at testing?”. Or, using the #NoTesting frame, “How can our organisation become more effective at delivering quality products and services?”

Fellowship

Organisational Psychotherapy is not just about improving product quality, however. Through improved relationships, and a shift in how the organisation relates to its people (i.e. from Theory-X to Theory-Y), the quality of life at work also improves. Put another way, we all have more fun, more job satisfaction, and get to realise more of our potential at work. Further, for all the folks that matter, their several needs get better met. And, as a bonus for the organisation itself, it gets to see its people more productive and engaged. What’s not to like?

Incidentally

I’ve also written elsewhere about using the Antimatter Principle in practical ways during software development. For example, during development we eschew requirements gathering in favour of incrementally elaborating hypotheses about the needs of all the folks that matter, and then conducting experiments to explore those needs. I can envisage teams that still need testers adopting a needs-focused approach to driving testing. For example, putting into place various means by which to answer the question “how well does our product meet the needs of the people that matter to us?”.

Practical Applications

On a related note, some folks asked me about practical applications of Organisational Psychotherapy in their day-to-day work as testers. Here’s just a few applications which immediately come to mind:

  • Improving communication with the people that matter (i.e. developers, fellow testers, management, stakeholders, customers, etc.). I find NVC (nonviolent communication) skills and practice particularly useful in this context.
  • Clarifying what works and thus what to do more of (Cf Solutions Focus). This can improve team retrospectives.
  • Helping the people that matter (including ourselves) feel better about what we’re doing (Cf. Positive Psychology).
  • Understanding each other’s strengths, with a view to having the right people in the right seats on the bus (Cf. StrengthsFinder).
  • Eliciting requirements (if you still do that) (Cf Clean Language).
  • Building a community (such as a Testing CoP or a multi-skilled self-organising product team) (Cf Satir Family Therapy).
  • Improved cooperation with higher-ups (empathy, Transactional Analysis, etc.).
  • Dealing with blockers to changing/improving the way the work works.

Invitation

I’d love to hear if this post has helped put my recent Testbash session in context.

– Bob

Change is a Waste of Time

Change is a waste of time. And money. And human potential.

That’s not to say the fruits of change are not sweet, but the cost of those fruits, especially given the way most companies go about change, is egregiously excessive.

Put another way, if we could spend less time, effort, money, management attention etc. on change, the waste would be less. And the fruits more abundant and sweeter.

Despite many saying they want change, few need change. I mean, it’s not like anyone’s job, livelihood, career or self-image depended on it. At least, that’s the perception. And those few who DO need change, are those that seem to be stymied at every turn when trying to introduce it. 

What to do? 

How about we take a leaf out of the Book of Therapy, and simply support the few – the few individuals, the few organisations – that feel the need to change? Maybe their improved wellbeing might then encourage a few others?

– Bob

World Class? Really?

Some six years ago now, I wrote a post describing what might characterise a world class software / product development / collaborative knowledge work business.

In the interim, I’ve had some opportunities to work on these ideas for various clients. My consequent experiences, whilst in no way invalidating that post, have thrown up different perspectives on the question of “world class”.

Firstly, do you want it? Moving towards becoming a world class business involves a shed load of work, over many years. Do you want to commit to that effort? Even though the goal sounds noble, ambitious, attractive, does your business have what it takes to even begin the journey in earnest, let alone stick at it.

Then, do you need it? Absent powerful drivers spurring you on towards the goal, will you have the grit necessary to keep at it? Or will the initiative flounder and drown in the minutiae of daily exigencies, such as the constant pressure to get product and features out the door, to keep investors satisfied with (short term) results, etc.? And is the ROI there, in your context? If you do keep on the sometimes joyful, oftentimes wearisome path, and attain “world class” status, will the effort pay back in terms of e.g. the bottom line?

If your answers to the preceding two questions are yes, then we can get down to considering the characteristics of a world class collaborative knowledge-work business.

What might it look like, that goal state? Here’s my current take:

Context

Just in case a little context might help, here’s a variant of the Rightshifting chart which illustrates world class in terms of relative effectiveness (i.e. how effective are world class organisations relative to their peers?) The yellow area highlights those organisations (those at least circa 2.5 times more effective than the median) we might consider world class:

WorldClass

Fields of Competency

Any world class collaborative knowledge-work business must have mastered a bunch of different fields of knowledge. That’s not to say everyone in the organisation needs to have reached mastery (Level 5 – see below) in every one of the follow fields. But there must be a widespread acquaintance with all these fields, and some level of individual competent in each.

I suggest the following Dreyfus-inspired model for characterising an individual’s (practitioner’s) level of competency (or action-oriented knowledge) in any given field:

Level One (Novice)

The Novice level in each Field invites practitioners to acquire the basic vocabulary and core concepts of the Field. Attainment criteria will specify the expected vocabulary and core concepts. The Novice level also invites practitioners to acquire and demonstrate the ability to read and understand materials (books, articles, papers, videos, podcasts, etc.) related to the vocabulary and core concepts of the Field.

Level Two (Advanced Beginner)

The Advanced Beginner level in each Field invites practitioners to acquire the ability to critique key artefacts commonly found in the given Field. The Advanced Beginner level also invites practitioners to read more widely, and understand different perspectives or more nuanced aspects of, and peripheral or advanced elements within the Field.

Level Three (Competent)

The Competent level in each Field invites practitioners to acquire and demonstrate a practical competency in the core concepts in the Field, for example through the ability to apply the concepts, or create key artefacts, unaided.
The Competent level also invites practitioners to acquire and demonstrate the ability to collaborate with others in exploring and applying the abilities acquired in the Novice and Advanced Beginner levels.

Level Four (Proficient)

The Proficient level in each Field invites practitioners to acquire and demonstrate the ability to prepare and present examples and other educational materials appropriate to the given Field. The Proficient level also invites practitioners to acquire and demonstrate the ability to coach or otherwise guide others in applying the abilities acquired in the Novice, Advanced Beginner and Competent levels.

Level Five (Master)

The Master level in each Field invites practitioners to acquire and demonstrate national or international thought leadership in the Field. This can include: making significant public contributions or extensions to the Field; becoming a publicly recognised expert in the Field; publishing books, papers and/or articles relevant to the Field; etc.

The Fields

Any business that aspires to world class status must attain effective competencies in a wide range of different fields. The following list suggests the fields I have found most relevant to collaborative knowledge-work business in general, and software / product tech businesses in particular:

Flow

  • Flow (product development) (n): the movement of the designs, etc., for a product or service through the steps of the design processes which create them.
  • Continuous Flow (n): The progressive movement of units of design through value-adding steps within a design process such that a product design or service design proceeds from conception into production without stoppages, delays, or back flows.
  • See also: Optimised Flow Demonstration (video)

Deming

  • * Many in Japan credit Bill Deming for what has become known as the Japanese post-war economic miracle of 1950 to 1960.
  • William Edwards Deming (October 14, 1900 – December 20, 1993) was an American engineer, statistician, professor, author, lecturer, and management consultant. Deming is best known for his work in Japan after WWII, particularly his work with the leaders of Japanese industry.

Risk Management

  • Risk management is the discipline and practice of explicitly identifying and managing key risks.

    “Risk Management is Project Management for grown-ups.”
    ~ DeMarco & Lister

  • Potential benefits include:
    • makes aggressive risk-taking possible
    • protects us from getting blindsided
    • provides minimum-cost downside protection
    • reveals invisible transfers of responsibility
    • isolates the failure of a subproject
  • Note; Many Agile practices are, at their heart, about risk management.

Mindset

  • Mindset a.k.a. collective (organisational) memeplex (n): A set of memes (ideas, assumptions, beliefs, heuristics, etc.) which interact to reinforce each other.

“A memeplex is a set of memes which, while not necessarily being good survivors on their own, are good survivors in the presence of other members of the memeplex.”
~ Richard Dawkins in The God Delusion

  • The “organisational mindset” is a set of beliefs about the world and the world of work which act to reinforce each other.
  • These interlocking beliefs tightly bind organisations into a straight-jacket of thought patterns which many find inescapable. Without coordinated interventions at multiple points in the memeplex simultaneously, these interactions will prevail, as will the status quo.

Requirements a.k.a. Needs Management

  • A more or less formal approach to identifying and communicating needs
  • Any approach that ensures that everyone involved in attending to the identified needs shares a clear understanding of the required outcome(s): “doing the RIGHT thing”.

Fellowship

  • A system of organisational governance based on the precepts of Situational Leadership and with a primary focus on the quality of interpersonal relationships as a means to improved organisational health and effectiveness.
  • More generally, paying attend to the quality and effectiveness of the collaborative relationships across and through the business (and the extended value network of which it is a part).

Cognitive Function

  • Cognitive function (Neurology) (n): Any mental process that involves symbolic operations–e.g. perception, memory, creation of imagery, and thinking; Cognitive Function encompasses awareness and capacity for judgment.
  • Effectiveness of collaborative knowledge work is dictated by both e.g. quality of interpersonal relationships and degree of Cognitive Function.
  • See also: Cognitive Science

PDCA

  • PDCA (plan–do–check–act, or plan–do–check–adjust) is an iterative four-step method used for the control and continuous improvement of processes and products. It is also known as the Deming circle/cycle/wheel, Shewhart cycle, control circle/cycle, or plan–do–study–act (PDSA).
  • Based on the scientific method, (Cf. Francis Bacon) e.g. “hypothesis” – “experiment” – “evaluation”.

Statistical Process Control (SPC)

  • Statistical process control (SPC) is a method of quality control which uses statistical methods. SPC is applied in order to monitor and control a process.
  • Key tools used in SPC include control charts; a focus on continuous improvement; and the design of experiments.
  • See also: The Red Beads and the Red Bead Experiment with Dr. W. Edwards Deming (video)

Lean Product Development

  • Lean Product Development applies ideas from Lean Manufacturing to the design and development of new products (See e.g. books by Allen Ward and Michael Kennedy)
  • Aims to improve the flow of new ideas “from concept to cash”.
  • Can also help raise levels of innovation.
  • Exemplar: TPDS (Toyota Product Development System)

Don Reinertsen’s Work

  • Don Reinertsen is the author of three of the most definitive and best-selling books on product development.
  • His 1991 book, Developing Products in Half the Time is a product development classic.
  • His 1997 book, Managing the Design Factory: A Product Developer’s Toolkit, was the first book to describe how the principles of Just-in-Time manufacturing could be applied to product development. In the past 16 years this approach has become known as Lean Product Development.
  • His latest award-winning book, The Principles of Product Development Flow: Second Generation Lean Product Development, has been praised as, “… quite simply the most advanced product development book you can buy.”

Neuroscience

  • (Cognitive) neuroscience is concerned with the scientific study of the biological processes and aspects that underlie cognition, with a specific focus on the neural connections in the brain which are involved in mental processes.
  • (Cognitive) neuroscience addresses the questions of how psychological/cognitive activities are affected or controlled by neural circuits in the brain. Cognitive neuroscience is a branch of both psychology and neuroscience, overlapping with disciplines such as physiological psychology, cognitive psychology, and neuropsychology.
  • See also: Cognitive Function

Theory of Constraints

  • The Theory of Constraints (TOC) is a management paradigm originated by Eliyahu M. Goldratt.
  • TOC proposes a scientific approach to improvement. It hypothesises that every complex system, including manufacturing processes, consists of multiple linked activities, just one of which acts as a constraint upon the entire system (the “weakest link in the chain”).
  • TOC has a wide range of “thinking tools” which together form a coherent problem-solving and change management system.

Self-organisation

  • Self-organisation (n): Ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner. It is as if the system knows how to ‘do its own thing.’ Many natural systems such as cells, chemical compounds, galaxies, organisms and planets show this property. Animal and human communities too display self-organization.

    “An empowered organization is one in which individuals have the knowledge, skill, desire, and opportunity to personally succeed in a way that leads to collective organisational success.”
    ~ Stephen R. Covey

Quantification

  • In mathematics and empirical science, quantification is the act of counting and measuring that maps human sense observations and experiences into members of some set of numbers. Quantification in this sense is fundamental to the scientific method.
  • See also: Tom Gilb

Systems Thinking

  • Systems thinking provides a model of decision-making that helps organisations effectively deal with change and adapt.
  • It is a component of a learning organisation – one that facilitates learning throughout the organisation to transform itself and adapt.
  • See also: Peter Senge, Russell L. Ackoff, Donella Meadows, etc.

Psychology

  • Psychology (n): the study of behaviour and mind, embracing all aspects of conscious and unconscious experience as well as thought. It is an academic discipline and an applied science which seeks to understand individuals and groups.

Argyris

  • An American business theorist, Professor Emeritus at Harvard Business School, and known for his work on interpersonal communication, organisational effectiveness, double-loop learning and learning organisations.
  • See also: Action Science.

Psychotherapy

  • Psychotherapy (n): interventions which facilitate the shifting of perspectives and attitudes, and thus, human behaviours.
  • See also: Organisational Psychotherapy

To the above list of Fields, I invite you to add any which may have specific resonance or relevance to your own business.

And then there are the lists of technical capabilities you need to be present in your various business functions, too.

Aside – CMMI

As an aside, CMMI also provides an extensive list of “capability areas” ( circa 128 different areas, last time I looked) focussed on engineering capabilities. Note: I find the CMMI list useful, but only as a primer, not as a full-blown recipe for success.

Summary

All the above begs the question: how to get there? And, how close are you to world class, so far?

– Bob

Means and Ends

How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?

Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features, revenues, wages, …) resulting from that work.

To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:

  • Ongoing information (development schedules, quality levels, costs, plans, etc.)
  • Confidence (e.g. that milestones and Due Dates will be hit)
  • Growth
  • Learning
  • A sense of purpose (are we spending our time on stuff that matters?)
  • Integrity
  • Connection (e.g. human connections, relationships between people)
  • Appreciation
  • Harmony
  • Achievement
  • Etc. (and lots more possibilities in e.g. this Needs Inventory)

This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.

In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).

May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?

Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?

Blind Spot

In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.

How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?

What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?

– Bob

%d bloggers like this: