Nov 29, 2016

Old Thinking vs New Thinking (Old Thinking Redefined)

The diagram below (from the internet) makes “Old Thinking” sound evil. What if we redefine “Old Thinking” so it doesn’t sound so bad?

Old Vs New

Redefinition:

  • Employees are biggest risk - we have the best employees; competitors might attract them; let's take care of ours
  • Top Down Communication - Ensure everyone is informed of the CEO's thinking and company's plans; no one is unimportant
  • Skill Over Behavior - our customers prefer reliable products and services over our friendly apologies
  • Manage Time - efficiency and productivity are key competitive competencies
  • Rigid Working Schedule - don't work over time, make time for your personal life
  • At Your Desk - we provide you with all you need and your own space
  • Work for the weekend - work hard, play hard. Complete your work for the week so you can enjoy your weekend
  • Corporate Jargon - precise terminology is clear and efficient; be scared when surgeons have the same vocabulary as litigation lawyers
  • Double standard - demand more from the experienced; be more tolerant of those learning the ropes
  • Fear of Failure - think things through; use risk management
    Enrich shareholders - they are the moms and pops who have invested their lifesaving with us for their retirement

Nov 23, 2016

Deming and a System of Profound Ignorance

W Edwards Deming's famous (or in some circle, infamous) 14 Points traces its roots from his 'System of Profound Knowledge' (SOPK), a framework for thinking that he developed to help leaders (and really, everyone) understand what they need to know if they are to effectively improve (rather than destroy) the organisations they work in. 

SOPK consists of four components (Appreciation for a System, Theory of Knowledge, Knowledge of Variation, and Psychology) and the interactions between and among each of them.

In order to attain 'profound knowledge' one must have:

  • A solid understanding of each component from a conceptual perspective (e.g., what is variation and why do I need to know about it?)
  • A solid understanding of how each component interacts with the other three, from a conceptual perspective (e.g., how does a theory of knowledge impact how you interpret a system's behaviour?)
  • A solid understanding of the above as applied to a domain (e.g., software development)
  • A solid understanding of the above as applied to a specific organisation (e.g., this team)

Most of us will be familiar with one or more of the above components. But what about those who occupy leadership positions but are not aware of any of them? If they're using a different set of components, then they are using an alternative thinking framework, an anti-SOPK. The opposite of knowledge is ignorance, therefore such a framework can be said to be a SOPI - a System of Profound Ignorance.

What might the effects of such a framework look like?

  • Lack of Appreciation for a System - SOPI practitioners focus on optimisation of each organisation sub-units, often turning them into 'profit centres', and comparing the profitability of each against the other. The psychology of survival kicks in within each sub-unit: Sales makes unachievable promises to customers, Purchasing seeks the lowest cost vendors, to the detriment of quality or reliability. Traders step over the bounds of ethics, The result: a system consisting of sub-units that fight for their own survival, a system that turns against its own best interests.
  • Lack of Knowledge of Variation - SOPI practitioners look only at the most recent numbers. They celebrate when a target is exceeded, dishing out 'Well Done!'s to a few, and words of encouragement to 'Keep up the good work'. Disappointment occurs over the next several month's results as normal variation kicks in.
  • Lack of a Theory of Knowledge - opinions and gut-feel rule the day. There is no appetite for going to the place where the data occurs (the gemba), no interest in persistent monitoring of phenomena, no rigorous approach to theory and experimentation to understand why things are as they are.
  • Lack of appreciation for Psychology - SOPI practitioners ignore the psychological nature of people. They are surprised when people behave in ways that do not fit a deterministic, 'rational', linear cause-and-effect paradigm.

SOPK is both easy and demanding. The framework is easy enough to understand: just four components and their interactions; Deming suggests proficiency of any of the concepts is not required to begin using SOPK. 

Though easy, it is nevertheless demanding, for at least three reasons. 

First, each of the components can be a deep subject in its own right. Mastery of the concepts and principles take time. To reuse a description: a mouse can wade in any of them, yet an elephant can drown in any of them.

Second, while beginning to use SOPK is easy, the actual usage can be tedious. It is, after all, a scientific system demanding theories, experiments, validations. Mastery of application takes longer. Tenacity is required to keep using it.

Third, the insights that SOPK brings places its practitioners square against the mass of 'common sense'. The insights may say a cultural change is needed. Sometimes they direct us to a required change in the larger system. These types of changes take time and effort. In an era where instant results, 'decisive thinking', and putting out fires are what attracts attention and praise, it's not an easy place to be.

SOPK requires faith. But SOPI is the path of least resistance and instant rewards.

Oct 14, 2016

Hard Stuff is Sometimes Hard Stuff

Glen Alleman has a great little post about two ways to solve a problem (http://herdingcats.typepad.com/my_weblog/2016/10/making-hard-stuff-into-east-stuff.html)

The story about the mathematician who ‘reduced’ the problem to a known one is funny, and easily recognisable to software developers as well – solve part of the problem and hand the rest to a function library that knows how to solve the revised problem.  It is logically sound, even if impractical if taken to the extreme as in the story.

However, it may be too simplistic an example in the argument against #NoEstimates. If you were asked to estimate how long it would take to boil away a potful of water, you might think to revise the problem into looking up (or estimating) how long it would take to boil away a tablespoon of water, and then multiply that by the number of tablespoons of water contained in the pot. In this case, you have reduced the problem into multiple known ones.  All that’s left is to combine the results of the solved problem.  I don’t know for sure, but I suspect the actual time to vaporise the whole potful will take significantly longer than the sum.

Another thing that makes project estimating hard is the dissimilarity between projects (the ‘uniqueness’ of each project) -- it’s not always about boiling the same volume of water in the same pot. It’s boiling potentially a different volume of a different kind of liquid, using a different kind of pot, using a different kind of heat source, in an area with a different temperature and different air density, with different stakeholder requirements about governance and reporting of the progress.