Taiichi Ohno on Kaizen: Don't be a Fool!

According to the Kaizen Institute's blog, gemba panta rei, Taiichi Ohno once scolded a subordinate for following his instructions too closely:

You are a fool if you do just as I say. You are a greater fool if you don't do as I say. You should think for yourself and come up with better ideas than mine.

Some Reflections on Values

Here's a short quiz: Match the company to its corporate values:

• Companies: IBM, Toyota, Enron
• Values:
• A. Communication, Respect, Integrity, Excellence
• B. Challenge, Continuous Improvement, Go and See, Respect, Teamwork
• C. Client success, Meaningful Innovation, Trust and personal responsibility

[Answers are at the bottom of the post.]

At first blush they all sound pretty good.  After all, who doesn't love a manifesto, motherhood statements, and apple pie?

Systems of Values

In exploring examples of systems of values one might also examine

• Religious creeds: the 10 commandments, the Golden Rule, etc.
• Practical philosophies: the Agile manifesto, Scrum values, XP values
• Insights: e.g. Seligman on Happiness
• Your child's school's values
• Your personal values

It seems to me that value statements present us with at least three challenges:

1. Explicit values vs tacit values
2. The sheer quantity of possible values
3. What to do in the presence of conflicting values

1. Explicit vs tacit values

The war between appearance and substance, perception and reality is ongoing.  At their best explicit values can capture and promote positive ends by conserving what is good and guiding aspirations to do better.  At their worst explicit values devolve to propaganda, or as we say nowadays "spin".

Actions speak louder than words: An interesting exercise is matching actions to explicit values and taking the leftovers and framing tacit values that they match.

2. So many values ...

Consider needs:

In the face of so many possible and overlapping values consider starting with a lists of needs and selecting a small number that are personally relevant and reasonably independent.  The aforementioned needs have the following headings: connection, physical well-being, honesty, play, peace, autonomy, meaning.  The journey from a need to an espoused value is from necessity or desire to intended action.

Maslow's hierarchy of needs -- in ascending order: physiological, safety, love and belonging, esteem, self-actualization -- is another categorization worth examining.

Self-Determination Theory identifies Competence, Relatedness and Autonomy as key.  Dan Pink subs in Purpose for Relatedness and rebrands Competence to claim Autonomy, Mastery and Purpose as the keys to intrinsic motivation.

Some other interesting examples:

Tim Gallwey and co. explore the relationships between Performance, Learning and Enjoyment -- the vertices of the "PLE triangle" -- in The Inner Game of Stress. Organizations typically obsess over Performance (the obvious, outward objective) over the other two (internal, enabling objectives).  If performance is poor (or feels empty), try focussing on learning and/or enjoyment for a while. Performance may well improve as a consequence.

At Kaizen camp Melbourne 2013 Ian MacDonald's System Leadership Theory was touched on.  In MacDonald's schema: trust, fairness, honesty, dignity, courage, and love are identified as core values that manifest in different ways depending on the work culture of an organization.

Mix and match

I've identified some categories that I find useful for comparing systems of values:

• Ethics: Without ethics, who are we?
• Purpose: What am I trying to achieve?  Why does the organization exist?  What distinguishes it? 
• Performance: How am I /we doing?  Can we survive?  Can we excel?
• Learning: How do we improve and get better, especially in the face of threat and/or competition?
• Safety and enjoyment: Without safety, enjoyment, connection and fulfilment it will be difficult to thrive and survive long-term. [Oft-stated, sadly oft-ignored.] 

If an organization doesn't value all of these in some shape or form, that's going to leave a significant weakness.

3. Values Conflicts

Values Conflicts were the main subject of discussion in the values session at Kaizen Camp.  Discussion of examples suggested that values-conflicts may be over-diagnosed and clashes of competing self-interest under-diagnosed.

Nevertheless, the following commandments ;-) were suggested as guides to dealing with values conflicts:

1. Thou shalt not prostitute your values.
2. Thou shalt not retreat into learned helplessness.
3. Thou shalt understand alternative points of view.
4. Thou shalt understand operational imperatives.
5. In a difficult situation, thou shalt look for ways to achieve the deeper aim, while honouring your values.
6. Thou shalt not set up systems that reinforce bad behaviour.

The first five commandments boil down to understanding and sticking to your own values, while striving to understand other perspectives and systemic factors, and employing creativity to find win-wins. The last item is preventative.

The Value of Values

Your beliefs become your thoughts,
Your thoughts become your words,
Your words become your actions,
Your actions become your habits,
Your habits become your values,
Your values become your destiny.
― Gandhi

Quiz answer key: A = Enron, B = Toyota, C = IBM

Don Reinertsen's talk on Flow to the Limited WIP society - 8 Big Ideas

Don Reinertsen approves (and corrects!):

@agilejitsu Nice summary. To clarify: optimum failure rate in PD is frequently 50% (500k ppm); in 6 sigma mfg 0.00034 % (3.4 ppm). 10^5 diff
— Donald Reinertsen (@DReinertsen) July 31, 2013

Introduction

In Principles of Product Development Flow: Second Generation Lean Product Development Don Reinertsen takes an economic/scientific approach to adapting lean approaches from manufacturing to product development, including but not limited to software development.

In doing so, Reinertsen provides the beginnings of a scientific basis to many of the empirical practices of Agile.

Interview (24 mins):  http://www.youtube.com/watch?v=G-NbrISyfvM

Reinertsen says: "I believe that people in the Agile software space are doing a better job at using Lean in Product Development than companies that have forty years of experience with Lean Manufacturing, and that's because the Lean Manufacturing people have this toxic idea that variability is always bad and that it is feasible to eliminate variability.  In highly repetitive manufacturing processes there's some truth to that, and in manufacturing processes you don't need to innovate.  In Product Development you need to innovate in order to add value.  As a result, if you try to drive out variability you drive out all of the innovation!"

Several of the principles that apply in Lean Manufacturing

• Minimise variability
• FIFO queues
• Waste as enemy #1

have to change when the context shifts to Product Development.

In terms of applying Lean continuous flow to Software product Development Reinertsen is inclined towards Kanban-based systems over Theory of Constraints-based systems.  He recommends David J Anderson's book, Kanban: Successful Evolutionary Change for your Technology Business for elucidation.

Reinertsen's book is quite dense: a 600 page book compressed into just under 300 pages.  The density makes Don's summary talks worthwhile: he intends to write a 150 page version for non-Engineers "one day".

Summary of Reinertsen's talk to the Limited WIP society

• Melbourne, 11 December, 2012
• Some highlights from Reinertsen's two day workshop in an hour, plus questions
• Slides from a similar talk (lots of overlap): http://gotocon.com/dl/jaoo-aarhus-2010/slides/DonReinertsen_UnderstandingTheMagicOfLeanProductDevelopment.pdf

Eight big ideas:

1. Economics: use quantified models
2. Queues: the invisible enemy in product development
3. Variability: not the enemy: can profit from it (analogous to volatility in Financial Engineering)
4. Batch size: reducing batch size is the #1 way to reduce queues
5. WIP constraints: #2 way to reduce queues
6. Cadence: offers additional performance opportunities
7. Sequencing: additional gains available by prioritising Weighted Shortest Jobs First in queues (c.f. FIFO suffices in Manufacturing)
8. Feedback: fast feedback loops enable better economic performance in the presence of uncertainty.

Big idea #1: Economics

"Provide product developers with good decision support information to make economic decisions."

• What you get: "An apolitical framework from which to make multivariate trade-offs".  Enables effective decentralization of control.
• The alternative: "Get into ideological debates."

The #1 thing to quantify: cost of delay (e.g. $ lost per month of delay of project delivery)

How accurate do you need cost of delay to be?  Inter-rater reliability of individuals' intuition of cost-of-delay at the same organisation:

• Average: 50 : 1 spread
• Best: 10 : 1
• Worst: 200 : 1

"Any analysis beats intuition."

Implementation requires the construction of a quantitative model: in questioning Reinertsen said he can build this from the implicit P&L in a typical project business case, and that it's a lot less flaky than the ROI model, but he didn't give an example or recipe.

• Outline of a quantitative model from Jason Yip: http://www.slideshare.net/jchyip/estimating-cost-of-delay
• A qualitative (color-coded) approach: http://agileconsulting.blogspot.com.au/2011/03/using-cost-of-delay-functions-to.html

Big idea #2: Queues

"Invisible, unmanaged queues are the root cause of poor economic performance in Product Development."

Managing the invisible: make physical artifacts: e.g. Kanban boards, Scrum boards.

Why queues matter: queues

• increase cycle time
• lower quality
• increase variability
• increase risk
• raise overhead
• lower motivation

Just like a freeway at peak hour, running close to capacity blows out queues:

Clearly, minimising excess capacity drives costs way up.  To minimise total cost, the cost of delay needs to be explicitly known:

Incidentally, these U-shaped optimisations crop up a lot in Lean Product Development.

Big idea #3: Variability ain't all bad

There's upside, too.  C.f. Financial modelling: volatility implies opportunity (positive risk), as well as downside (negative risk).

This is different from manufacturing, where variability is all bad.

Big idea #4: Reduce batch size

"Halving batch sizes halves queues and halves cycle time."

Pros:

• Easy and cheap to implement
• Easy to reverse if there are problems

Big idea #5: Reduce cycle time by limiting WIP

"Reduce cycle time by limiting WIP"

Little's formula: Average cycle time = average WIP / average departure rate

Visual control systems (e.g. Kanban boards) help.  These, with cumulative flow diagrams, show queues in a way that Gantt charts don't.

At the project level, serializing projects (rather than running many in parallel) means that:

• early projects are finished faster, delivering value sooner
• deferred projects can benefit from: more time for requirements to mature; learnings from earlier, completed projects

Big idea #6: Cadence

"A synchronised cadence offers additional performance advantages."

Cadence:

• makes maximum wait times predictable
• reduces coordination costs
• enables smaller batch sizes

Replace asynchronous processes with synchronous processes.

Big idea #7: Flexible sequencing

"Proper sequencing offers additional gains."

C.f. Hospital emergency room: expedite the person having a heart attack!

In continuous flow, prioritising according to weighted shortest job first (WSJF = Cost of Delay / Time) can result in gains of up to 96%:

A qualitative approach to WSJF for the Scaled Agile Framework

Big idea #8: Feedback

"Fast feedback loops enable better economic performance in the presence of uncertainty."

"Optimum failure rate in product development is frequently 50% (500k ppm); in 6 sigma manufacturing 0.00034% (3.4 ppm)."

Example: Hospital waiting room

• Two patients enter with chest pains
• Heartburn or heart attack?
• What to do?

1. Buy information cheaply: find out if it's a heart attack (differential diagnosis / tests)
2. Stabilise the patient, then treat at leisure: this lowers the Cost of Delay.  C.f. Give the customer the most valuable feature(s) first, then take your time with refinements.

Recommended reading and viewing from Kaizen Camp, Melbourne, 2013

Here are some references I took down during the recent unconference, which might be described as Lean Coffee, crossed with Open Space.

Cognitive biases

• Daniel Kahneman, Thinking, Fast and Slow
• Jim Benson, Why Plans Fail [Kindle]
• Dan Ariely, Predictably Irrational

Patterns of Learned Helplessness

• Definition of learned helplessness [wikipedia]
• How to fold a t-shirt in five seconds [video]
• Kaizen explained and applied to unloading a dishwasher [video]

Kanban

• Jim Benson, Personal Kanban
• David Anderson, Kanban

Systems

• Ian MacDonald et al, Systems Leadership: Creating Positive Organisations
• Stafford Beer, Viable System Model [wikipedia]

The Power of Silence

• Susan Cain, Quiet: The Power of Introverts in a World That Can't Stop Talking

Humour and Creativity

• Peter McGraw, humorcode.com
• John Cleese, a lecture on creativity [video]
• Various Italian architecture students, helium stick [video]
• Keith Johnstone, Impro: Improvisation and the Theatre

Lean Operations

• Tim Gallwey, The Inner Game of Tennis
• Tim Gallwey, The Inner Game of Stress

JFGI

• Kaizen - change for the better
• Kaikaku - radical change
• Cynefin
• Deming, System of Profound Knowledge
• Goldratt, Theory of Constraints
• Toyota Production System
• Game Theory, Ultimatum game, Prisoner's Dilemma
• Lean Coffee
• Scaled Agile Framework, Portfolio Kanban
• sociocracy

Next: Check out Chris Chan's reflections and pics, and Lynne Cazaly's drawings.

Structured Agile for Product Teams

I teach a structured approach to Agile, developed by the Agile Academy, and adapted for larger organisations who assemble project teams to tackle all manner of projects.

In smaller organizations, development tends to be product- rather than project-oriented.  Instead of routinely assembling (and later dismantling) project teams for major projects (who then handover to standing business-as-usual teams for support and minor enhancements), there are invariably long-lived product-centered teams who perform a mix of new development, minor enhancements, plus ongoing maintenance and second-level support.

This product-team arrangement may be the wave of the future for larger organizations as well: the case for product-teams is eloquently (and vehemently) made by Evan Bottcher in his most excellent diatribe Projects are Evil and Must be Destroyed - read it!

Now product teams -- in my experience -- face a number of typical challenges, especially balancing different kinds of work, especially:

• major development initiatives
• maintenance (bug fixing) and other support needs
• minor enhancements

In the remainder of this post I'll describe how the four-phase, structured Agile approach outlined by the Agile Academy here (similar to AUP) can be adapted to meet the needs of product teams.  At a high level:

1. Concept phase
Project version: Assess the technical feasibility of a business idea.  Draft a "project charter".
Product version: Revise and update the vision  for the product; assess requests from stakeholders (or customers) for feasibility; choose the theme(s) for the next major release.  Update the "product charter".

2. Initiate phase
Project version: Review and refine the business idea for technical development.  High-level prioritization, estimation, and initial release planning for the project.
Product version: High-level prioritization, estimation, and planning for the next major release.

3. Deliver phase
Project version: Iterative and incremental development and delivery of working software.
Product version: Same, interspersed with maintenance and support.

4. Deploy phase
Project version: Rapid and secure deployment of software to required environments.  Handover to BAU team on final deploy.
Product version: Same, but no final and no handover.

Concept and Initiate still make sense, but happen periodically
The major changes involve re-purposing the Concept and Initiate phases to encourage long(ish)-term planning for product teams, centered around the next major release of the software.  This is an opportunity for the business and technical teams to put their heads together, assess and chart a way forward.

Distinguish enhancement requests from defect reports

With standing teams it is all too easy to go reactive, and treat feature requests similarly to defect reports: part of a long list of "to dos" that must be prioritized and got to.  This feels more efficient, but it may fail to reject suggestions and to sufficiently refine and combine the best ones.

The difference from the project situation -- where the Concept phase allows the team to advise the governance body to kill off projects early and cheaply -- is that in the product case the team must advice not whether but what to go ahead with: Are we funding a cohesive and worthwhile upgrade?  This requires discernment and perspective, and going back to stakeholders with counter-offers to their suggestions that enhance the design, experience and overall integrity of the software.

Set-up iterations?
A set-up iteration, usually branded "Iteration 0" takes place at the start of the Deliver phase.  In the case of Product teams, many of the traditional tasks for a green-fields project will not be necessary.  Nevertheless, periodic Iteration 0s offer the opportunity to improve on existing processes, as well as implement changes foreshadowed by the most recent Initiate phase.

Transitioning to Agile
In transitioning an existing product team to Agile, the first Concept and Initiate phase can be usefully devoted to getting the existing processes, team, and backlog of work "over the hump" and across into an initial Agile configuration.

Often challenges will include a lack of automated unit-testing, existing patterns and dysfunctions in engagement with customers, and the difficulty of unlearning old patterns of behaviour.  Early priorities will include getting the team trained up, working cross-functionally, establishing a stable iteration cycle, including daily stand-ups, iteration planning, showcases, and retrospectives, as well as breaking work into small chunks, estimating it and delivering in small increments.

Doing just enough to get the current backlog of work going without planning a new major release (just yet) is effectively a Hudson Bay start to an Agile future.  But remember: it's only a start!

Mixing bug-fixing and enhancement work
There's no one answer to this one.  Bug-fixes are typically difficult to estimate and often urgent, and this combination can play havoc with everything else.  The aim is minimize task-switching costs while maintaining standards of service.  The thing that will help is to lift the quality of the software and thereby reduce incidents.

Fewer Severity 1 reports mean fewer "all hands on deck" interruptions.  A long-term strategy to reduce technical debt, ideally using test-driven development, pair-programming and old-fashioned smarts is a great start.  Israel Gat suggestions monetizing technical debt to make it visible on the balance sheet.

Non-urgent fixes can wait (a bit).  One approach that I have tried is to schedule a day per week for maintenance -- e.g. bug-fix Thursdays -- but this is a bit inflexible.  Another approach is to estimate and schedule the fixing of reported defects in story points.  The problem with this is that estimating how long it will take to fix non-obvious bugs is uncertain.  Mike Cohn suggests another approach: assigning a few points of velocity each iteration to maintenance (convertible to the equivalent number of hours), and tracking the hours spent for reporting and to help guide future allocations.

Minor enhancements
Product teams should be brutal in only doing the most minor enhancements during minor (also known as bug-fix) releases, since such work sucks development effort away from the major-release work and needs to be merged back in, a source of overhead.  Also, the faster response-time may train stakeholders to ask for "minor enhancements" or insist that a feature request is really a defect.

An exception may be made if you have 100% automated test coverage and are practicing true continuous deployment, in which case you've achieved a higher standard of Agility than most!

Ranking Rummy

Where Planning Poker works brilliantly to estimate the size of a task by drawing on the expertise of a group, I feel the need for a similar approach to obtain a consensus ranking (e.g. for prioritization).

Here is my approach -- which I hereby dub "Ranking Rummy" -- to this problem:

Example/procedure: Consider four stakeholders have identified five "top priority" tasks for a project, but the Project Manager has requested a strict ranking.

1. The tasks are labelled and each participant is given (or produces) five corresponding cards to rank independently and secretly -- no discussion.
2. When the participants are ready, they all reveal their highest priority card.
3. If all are in agreement, we have our consensus highest priority, and can move on to find the next highest.
4. Otherwise there will be two or more factions (groups who played the same card).  Similar to Planning Poker, the facilitator asks (only) one participant from each faction to explain his or her choice.  Then there is re-consideration, and the process is repeated until consensus has been achieved or, say, three rounds have been played.  If consensus is not achieved after three rounds, a tie-breaking mechanism is employed: E.g. majority or seniority.
5. Repeat for the remaining tasks.

As with Planning Poker, the procedure encourages initial independent ranking, and structured yet informative communication about the tasks under consideration without negotiation and/or intimidation.  

Seniority is a useful tie-breaker if your group is following a consultative (but non-democratic) approach.  For example, if prioritizing among Time, Scope and Cost, the project sponsor will typically have the final call, but Ranking Rummy would allow him or her and the stakeholders to get an understanding of each others' views and preferences along the way.

Applications

• Ranking tasks, users stories, features
• Alternative to value sliders [pdf], where a strict ranking is desired.

Please let me know how you go with Ranking Rummy.  Suggestions (and donations) gratefully accepted!

No Plan Survives First Contact With the Enemy

... or friends, for that matter.

This saying, from the context of battles, applies equally to projects where outside influences are significant.  Initial planning swiftly becomes outdated, so it wise to plan at first in only broad brush strokes -- at a high level -- perform detailed planning as we go along.

For those who have limited experience as military command consider instead a game of chess (or checkers).  One might go in with certain intentions (play aggressively, use set plays when possible), but there is no way that you can plan out the whole game in advance!  You might plan a few moves ahead, but as soon as your opponent moves, everything shifts, and it's time to re-plan.

1972: Fischer challenges Spassky

As for friends (or family), suggest a plan and they'll want to get on board ;-) too!  Your plans will shift.  In a project this is the equivalent of an internal customer or product owner suggesting a better idea mid-way through the project -- and you acknowledge that it really is better.  Hmmm ... better re-plan.