Tuesday, September 17, 2013

Good prioritizers; bad prioritizers

Even though there are many excellent techniques to prioritize a project or a backlog of work -- e.g. Story Mapping and MoSCoW -- it doesn't mean that it's easy.

In the various Agile approaches we usually split high-level prioritization and estimation between different roles: the stakeholder representative / customer or proxy / product owner (in Scrum) prioritizes the over-arching product backlog, while those who will do the work (typically a development or delivery team) estimate the cost.

Good prioritizers
  • seek bang-for-buck
  • own the project vision (or at least thoroughly understand the intent)
  • strive to get the "must haves" down to around 20% of the backlog
  • are great listeners who distil insights from a range of stakeholders
  • expect to learn a lot along the way
  • are privy to high enough level information to order the relative value of different pieces of work (quantification, e.g. cost-of-delay, would be even better!)
Bad prioritizers
  • try to please everyone, and may be punished for "poor customer service"
  • negotiate for as many "must haves" to be around 80% of the backlog
  • think they know pretty much what's needed up-front
  • struggle to synthesise a coherent picture from multiple stakeholders
  • bargain with or push the delivery team
  • may be exposed to too much detailed information
Entrepreneurs, especially those who are spending their own cash seem to have an advantage in terms of setting priorities because they are crafting their vision (although they may struggle with new information that challenges their pre-conceptions) and typically have both significant financial and emotional investment.

In an organizational context these advantages can be easily lost in the org chart.  We need to deliberately set up or carve out favourable conditions for our prioritizers to do a good job.  Then our Agile techniques can work wonderfully well.

Friday, September 6, 2013

My Talk on Design by Contract, Functional Contracts, Automated Testing and Static Typing

Last night I gave a well-received ;-) talk on Design by Contract at the Melbourne Functional (Programming) User Group.

Here are the slides:

For clojurists: James Sofra said afterwards that my talk reminded hime of this recent talk: Beyond Contracts.

Wednesday, August 21, 2013

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.

Friday, August 16, 2013

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

Wednesday, July 31, 2013

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

Don Reinertsen approves (and corrects!):


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

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.

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."
  • 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."
  • 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.

Tuesday, May 21, 2013

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

Patterns of Learned Helplessness



The Power of Silence

Lean Operations

  • 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.