Archive

Monthly Archives: May 2018

The Future of Coding Environments

May 29, 2018
Coding, Engineering, Software development
1 Comment

The Future of Coding Environments

How would Scotty or Geordie go about writing code for the Starship Enterprise? Would they write code at all? Would they just interact with the Computer via speech or holodeck, or would a keyboard of some sort still have a place? 

In any case, my interests have always stretched beyond matters of organisational effectiveness, beyond matters of human and humane relationships, and beyond matters of how the work of software and product development might better work.

One of my other abiding interests has been the nature of programming. Indeed I spent more than two years, decades ago, on conceiving, designing and implementing a proof of concept for the kind of development environment I’d like to use myself, when writing code. At the time, the work was codenamed “Simplicity”.

My core feature set / wish list includes: 

  • Editing source code directly in the AST, rather than editing source code in text files
  • Direct and incremental compilation of source code as it’s being entered
  • Multiple coders editing in the same AST concurrently
  • Live editing of the AST “in production” (with appropriate safeguards built-in)
  • One homogenous AST for each entire (live production) system
  • Source code control / version control features built right in (and automated away from distracting the coders)

OK, so this may not be the kind of development environment Scotty or Geordie would recognise. But it’s a world away from all the crap we have to put up with today.

Blockers

So why don’t we see more movement towards the emergence of some of these features in our development environments today? In a word: conservatism. Developers en masse seem disinclined – or unable – to look anew at their tools, and dream.

“The future is a foreign country; they do things differently there.”

– Bob

Further Reading

The Mjølner Environment ~ Görel Hedin, Boris Magnusson

 

Not Obviously Wrong

May 26, 2018
Culture change, Doctrine, General, Product development, Rightshifting, Software development
Leave a comment

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

Product Owners Suck

May 23, 2018
DevOps, Fellowship, Management, Organisational effectiveness, Product development, Scrum, Software development
5 Comments

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

May 21, 2018
Culture change, Engineering, Fellowship, Management, Nonviolent Communication, NoTesting, Organisational effectiveness, Organisational Therapy, Product development, Software development, Teambuilding, Therapy
Leave a comment

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

Testbash Dublin

May 21, 2018
Nonviolent Communication, NoTesting, Organisational effectiveness, Psychology, Therapy
2 Comments

Testbash Dublin

I’m just back from presenting an interactive session at Testbash Dublin. I enjoyed conversations on the topic of the session – Organisational Psychotherapy – as well as conversations around e.g. #NoTesting. Indeed, I noted a common theme running through many of the sessions from the more seasoned testers presenting: a grumbling low-key disaffection with the notion of testing as a path to quality.

No Testing

A number of folks engaged me in trying to better understand what I might mean by #NoTesting. Such conversations generally start out with “What do you mean by ‘testing’?”. My time in Dublin has allowed me to see through my discomfort in avoiding this question (yes, I generally choose to avoid it). I’m loath to get into semantic arguments from the get-go. I find they rarely lead to productive mutual exploration of such topics.

The bottom-line, is: It doesn’t matter one iota what I mean by “testing”. Whatever YOU mean by “testing”, that’s what I’m talking about when I mention #NoTesting. It’s an invitation for YOU to pause awhile to consider how life would be different if you stopped doing “testing” (whatever YOU choose to understand by that term) and did something else to address the same ends.

Ends Over Means

There’s an idea from therapy which might help you understand this perspective. In eg Nonviolent Communication (and some other therapies), human motivation is assumed to stem from attempts to get our needs met. That is, our behaviours and actions result from the strategies (means) we choose in order to meet our needs (ends). Any particular strategy affords us a limited palette of behaviours and actions. Aside: Often, we have little or no conscious awareness of either our ends or our chosen means.

“Testing” (whatever YOU choose to understand by that term) is a strategy you (or someone else) has chosen – almost always, implicitly –  for getting your or their needs met. And other folks’ needs, too, in the general case.

There are always other strategies (means, options) for meeting folks’ needs. Yet rarely do these other strategies receive any consideration. Maybe some of these other options offer a way to better meet folks’ needs. How would we ever discover that, without considering them, becoming aware of them, exploring them?

So that’s what I’m talking about with #NoTesting (amongst a raft of #No hashtags) – an invitation and reminder to actively consider whether your default means (strategy) are best serving your ends (needs), whether your first and automatic choice of strategy is the most effective way to attend to your – and other folks’ – needs.

– Bob

Do Nothing That Is Not Play

May 16, 2018
Culture change, Innovation, Nonviolent Communication, Organisational effectiveness, Rightshifting
Leave a comment

Do Nothing That Is Not Play

If we think about it calmly for but a moment, one logical outcome of nonviolence is folks not working for a living, but playing for a living.

Innovation

Many companies seem desperate for “innovation”. Is innovation more like to come about through folks doing what they’re told (“working”) or through playing with things, as they see fit? I posit the latter is far more likely.

And no, this is not some flight of fancy. Do we really embrace wholeheartedly the set of assumptions labelled by Douglas McGregor as Theory-Y?

Theory-Y assumptions are: (1) physical and mental effort are natural and most people (depending on the work environment) find work to be a source of satisfaction, (2) they generally, on their own motivation, exercise self-control, self-direction, creativity, and ingenuity in pursuit of individual and collective (company) goals, (3) they either seek responsibility or learn to accept it willingly, and that (4) their full potential is not tapped in most organisations.

Could it be that folks’ “full potential is not tapped in most organisations” because they are obliged to “work” rather than play?

Could it be that engagement (and productivity) would take an amazing leap forwards if we invited folks to “play” rather than “work”?

Could you have the courage to experiment to find out for yourself?

Or are we all so in thrall to what Walter Wink calls The Domination System that play as an alternative to work is undiscussable?

– Bob

Further Reading

Serious Play ~ Michael Schrage
The Importance of Play (A Valentine for Marshall Rosenberg, part 2) ~ John Kinyon
What If #7 – No Work ~ Think Different
The Human Side of Enterprise ~ Douglas McGregor
Theories of Motivation ~ Think Different

Change is a Waste of Time

May 15, 2018
Culture change, Management, Organisational effectiveness, Organisational Therapy
Leave a comment

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

Beyond the Pale

May 10, 2018
Culture change, Dialogue, Organisational effectiveness, Organisational Therapy, Psychology
4 Comments

Beyond the Pale

Digital transformations, Agile adoptions, shifts in collective mindset, Marshall Model transitions and the like general proceed slowly, if at all. Why might this be? What slows or blocks the implementation of more effective ways working, more effective ways of meeting folks needs?

I have found that one of the biggest drags on implementing more effective strategies for getting folks’ needs met is the sheer inconceivability of the new strategies. Literally. unthinkable. And not only are these prospective, more effective ways of doing things inconceivable, they’re often also unmentionable, undiscussable and taboo, too.

Some Examples

Here’s a list of some of the kinds of new strategies I’m talking about:

  • Using throughput accounting rather than cost accounting
  • Delivering value as defined by the customer, rather than the supplier
  • Defect prevention as a preferred alternative to testing
  • Favouring slack and flow over utilisation and busywork
  • Recruiting with humanity (conversations) rather than relying on CVs
  • Funding new product initiatives incrementally rather than with a one-off budget allocation
  • Incrementally trialling new product ideas in the market rather than one time “big launch”
  • Attending to folks’ needs rather than acting as if we know what’s best for others
  • Self-managing and self-organising teams
  • Having teams “own” the product they’re working on, rather than a separate Product Owner
  • Reducing or eliminating the command & control aspects of middle management roles
  • Theory Y over theory X
  • Adopting team-wide measures rather than measuring individuals
  • Seeing people as emotional and social rather than logical and rational
  • Eliminating extrinsic motivators in favour of cultivating intrinsic motivations
  • Adopting whole systems measures rather than local measures
  • Managing and optimising the whole business rather than managing and optimising each part
  • Having folks set their own salaries and bonuses, rather than have remuneration decided by others

And so on…

Promise Unrealised

Each of the above strategies promises to contribute to a more effective business, yet each of them is in itself often inconceivable, unacceptable, unthinkable and even undiscussable. In short, such new strategies are, at a given point in time, considered as beyond the pale.

The First Challenge

When considering Digital transformations, Agile adoptions, Marshall Model transitions and the like, our collective challenge, then, is to progressively broaden and deepen our tolerance and enthusiasm for discussing and embracing these new strategies.To move ourselves to a point where one, some or all of these new strategies is conceivable, discussable and acceptable. Only then can we begin to think about build a true consensus on a specific way forward.

And maybe organisational psychotherapy has a role to play in helping the organisation open itself up and start thinking and then talking about these “tough topics”.

– Bob

Further Reading

Discussing the Undiscussable ~ Bill Noonan
Crucial Conversations ~ Kerry Patterson et al.
Six Ways To Open Up and Talk in Therapy ~ John M. Grohol Psy.D. (article)

World Class? Really?

May 2, 2018
Engineering, General, Leadership, Management, Marshall Model, Organisational effectiveness, Product development, Rightshifting, Software development
1 Comment

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:

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