Category Archives: Kanban

Kanban: values, understanding & purpose

Posted on by

I’ve had a fantastic response to my previous post, Introducing Kanban through its values - it seems to have resonated with a lot of people. Followup discussions in a number of places over the past few days have helped me take the ideas a little further on and finish with some extra clarity.

Here then is the conclusion that I wasn’t quite ready to reach last week. I hope it both satisfies those who expressed disappointment that learning didn’t make my final list and reassures those who worry that values are somehow too fragile to write down.

Values

Kanban has at its heart a value system that includes Understanding, Agreement, Respect, Leadership, Flow, Customer Focus, Transparency, Balance & Collaboration.

Having this list as a commentary on Kanban’s principles & practices is helpful at three levels:

  1. We can cross-check and perhaps reframe (e.g. for teaching purposes) our understanding of the method. As it turns out, this reconciliation will pick up areas where perhaps the method definition itself could usefully be strengthened, though that wasn’t in my mind at the beginning.
  2. At any given time, we can use them to help us reflect on where we are as change agents and validate the approach we’re taking on the ground. This may heighten self-awareness &/or help identify areas of risk or weakness (as it did for me, though retrospectively).
  3. It identifies some characteristics of learning organisations (in the sense of, say, Peter Senge) that Kanban helps to foster. I don’t mean (as some have worried) “Kanban defining for me my company’s values”, but it suggests some good things to expect and encourage, as implicitly or explicitly as your situation demands.

A note of caution: at any level, don’t expect anything good to come from espousing values inauthentically. When in doubt, understand and reflect first.

Purpose

Some time after identifying that third level I had a lightbulb moment: we often say what the Kanban method is (an evolutionary approach to change) without saying what it is actually for! Change what? To what end?

Let’s fix that then:

The Kanban method is an evolutionary approach to building learning organisations.

Put like that, learning is right up there in Kanban’s purpose. That’s a relief! In retrospect I might have done well to start there but I’m journalling my thinking process as honestly as I can.

Interesting Addenda

On agreement, Greg Brougham brought to my attention Ackoff’s distinction between agreement in principle (a theoretical kind of agreement) and agreement in practice (an agreement to live with the consequences of a decision, accepting that agreement on “better” can be effective where consensus on perfection is impossible).

David Anderson would add Pragmatism (with a big P), referring to a philosophical tradition that describes a process in which theory is extracted from practice and applied back to practice. I expect we’ll see that one again.

Doing some blog archaeology, I revisited my Kanban in a nutshell post (March 2010) and confirmed that I took the same tool-first (or worse, tool-only) approach that I worried about in last week’s post. Health warning needed! I’m relieved to find that Learning together (June 2010, a collaboration with Jabe Bloom looking at Kanban and Agile principles) came not too long afterwards

Acknowledgements

I really do value collaboration, and I’m grateful (proud, even) to have these as collaborators: Dave “Value System” White, Arne “Learning” Roock, Hermanni “Understanding & Purpose” Hyytiälä, Patrick “Variety & Resilience” Steyaert and Jabe “Learning Together” Bloom. David “Leadership” Anderson has on multiple occasions actively encouraged me to pursue lines of thought or language even when they seemed to be in conflict with his. And if you tweeted, left a comment, posted on kanbandev or Google+ or in any other way encouraged me to explain myself better, thank you.

Introducing Kanban through its values

Posted on by

[German translation]

Introductions to the Kanban method tend to start with a description of the kanban card wall (a tool) and lead on to a description of its core practices. If you’re lucky, you’ll get to hear about Kanban’s foundational principles too.

Here, I’m attempting a different approach, one that gives equal weight both to the principles (which I believe should come first – they’re not called “foundational” for nothing) and the core practices by identifying the values that underpin them. In doing so we’ll cover most of the main elements of the method, so perhaps this works as a teaching framework too?

Regardless, the result is holistic (the values are widely applicable at multiple levels), remains true to Kanban’s purpose of driving evolutionary organisational change, and helps to address three misconceptions:

i.         that Kanban is somehow a software development process

ii.         that Kanban doesn’t have at its heart the kind of values that will both challenge an organization and guide its agents of change, and

iii.         that Kanban is only for number-crunching tool-heads in control-driven organisations (I exaggerate this last misconception only slightly)

Moreover, I hope to demonstrate also that a values-based description is useful for other, more constructive reasons.

My starting point

From Kanban’s Foundational Principles in their usual sequence I identify four values: Understanding, Agreement, Respect & Leadership. The first of these requires a little justification but the other three can be read directly into the principles as they are typically worded.

The values behind Kanban’s six Core Practices are a little trickier, not because the they aren’t there but because the correspondence isn’t exactly one-to-one. I chose another four (that’s eight so far): Transparency, Balance, Flow & Collaboration. However, I found it helpful to depart from the this obvious sequence and was compelled to add an additional one, making nine in total.

As I expand on each of these we’ll uncover a few more candidates for inclusion – I’ll highlight in bold anything that looks like a value (abstract nouns, basically). With the one exception to which I’ve already alluded, they’re less important, less axiomatic, less “core”.

Nine core values of Kanban

1.    Understanding

Understanding is one of the less obvious values of Kanban. I read it into the first foundational principle,  “Start with what you do now”. Understand the thing you’re changing, whether it’s the nitty-gritty details of a process, the way a process performs under conditions of stress, or something as abstract as your organisation’s overall approach to change.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
The Process Myth, Rands in Repose

In our Kanban training we teach a Systems Thinking approach that places understanding very high on our list of priorities. It’s right there in our early introductions to the method, the basis of the very first class exercise. Where does work come from? What characterizes different kinds of work? What approaches to the problems of change and improvement tend to succeed or fail, both generally and in your organisation specifically? Why might that be?

By definition, the absence of understanding is what characterises cargo cult implementations. Even with good intentions there’s a likelihood that understanding will be lost when change is driven top-down, justified weakly (over-relying on appeals to best practice for example) and passed unthinkingly between organisational layers.  It’s no small surprise therefore that change projects have a tendency to disappoint. Unfortunately for the lazy or unskilled manager, understanding and its allied values of learning and alignment take effort.

2.    Agreement

Agreement is right there in the second foundational principle, “Agree to pursue incremental, evolutionary change”. I like to turn this around: would you reasonably expect to be successful in implementing change without it? Could it be that it’s lack of agreement that’s limiting your progress? Or perhaps there is some agreement but it’s not deep enough – you’re agreed on the existence of a problem but not on its impact or causes (see understanding)?

This principle might seem to suggest another value, that of incrementalism. I would however shy away from describing this this as a core value, for the reason that we promote incremental, evolutionary change because it has a high chance of success, not because its alternatives in radicalism or conservatism are never better alternatives. And if pragmatism is a value, it is a rather slippery one.

3.    Respect

“Respect for people” is a pillar of Lean. Kanban applies this to the problem of organisational change in its third principle, “Initially, respect current roles, responsibilities & job titles”.

As in life, respect is a good guide when implementing change. Will it increase your chances of success if you start by implying that people are doing a bad job, or their roles are worthless? Probably not. Is it helpful to assume bad motives? Again, probably not. But does respect just mean “be nice”? Again no:

Showing respect for people does not mean you have to like them, agree with their views, and fail to challenge any half baked reasoning.
Stephen Parry

That kind of respect takes courage, taking us to our next value.

4.    Leadership

Leadership features in most stories of success but it was only in 2012 that it was added as a foundational principle, in the form “Encourage acts of leadership at all levels in your organization – from individual contributor to senior management”.

Much has been written on leadership and I won’t add to it here except to make a few quick observations:

i.         You might wish for an autocrat – a Steve Jobs (or a Steve Ballmer) perhaps – but the “at every level” kind of leadership is something different.

ii.         Not only is leadership something to value, management isn’t inherently something to despise either (remember respect?).

iii.         Furthermore, neither leadership nor management precludes self organisation, where individuals, teams and systems have the capacity to adapt without central or senior direction. Rather, good leadership and good management create the conditions in which self organisation thrives.

iv.         Good leadership involves challenge (we’ve used this word already). As agents of change we must be prepared both to challenge and to be challenged.

5.    Flow

Turning to the practices, we start with the third one, “Manage flow”.

The management part of this practice speaks of tactical organisation and decision-making aimed at progressing work for optimal outcomes (effectiveness). At some level – though with widely varying degrees of success – this is universal.

Flow adds something much less common, a sense of smoothness and predictability; addressing impediments to these systematically is a powerful improvement approach, exemplified in Lean.

We also value flow in Csikszentmihalyi’s sense, that very positive state of complete absorption in what we’re doing. This kind of flow is hard to find when distraction, interruption and constantly changing priorities dominate the work environment.

6.    Customer Focus

We haven’t finished with “Manage flow” yet! An expanded version of this practice might read something like

Manage to timely completion the smooth flow of customer-recognised value over a range of timescales

Value is meant in the sense of purpose (understanding the customer’s “why”) as much as in any monetary sense (taking care not to confuse utility with mere cost). A customer-focussed concern for completion means going beyond an activity-centric “task complete” or a product-centric “potentially shippable product”. In my experience, this is a surprisingly challenging concept whose impact can be dramatic.

Work done but not yet benefiting the customer is just sunk cost. We’ll return to this issue and address the “over a range of timescales” phrase when we look at the value of balance.

7.    Transparency

Transparency underpins three of Kanban’s core practices: the first, “Visualise [work]”, the fourth, “Make policies explicit”, and the fifth (another 2012 addition), “Implement feedback loops”.

Kanban creates transparency at multiple levels:

i.         In making work visible

ii.         In making visible the workflows that work items go through and the states that actual work items occupy at any given time

iii.         In making visible the parameters, policies and constraints that guide decision-making and ultimately drive the overall performance of the system

iv.         In making visible the impact of all the above in customer-focussed measures of performance

The first two types of visibility flow naturally from the kanban systems after which the Kanban method is named. The first three together create leverage points – points in our systems at which significant change can be effected for relatively little cost or effort. The fourth (a feedback loop) tells us that change is taking us in the right direction.

Kanban then is a way to evolve systems that learn and adapt, a strategy for organisations to find greater fitness relative to the competitive ecosystems they inhabit.

8.    Balance

The second core practice is “Limit work-in-progress (WIP)”. Limiting WIP across a process has multiple benefits:

  • Thanks to Little’s law, lead times (and therefore feedback cycles) tend to shorten; the customer is satisfied sooner and learning accelerates.
  • Work gets started only when capacity becomes available. This creates flow from the work item’s perspective and keeps supply and demand in balance from the team or worker’s perspective (respect!).
  • With just a little extra sophistication we can easily find balance between different kinds of operational work and between operational work and improvement work.

This last point suggests another principle, “Embrace variety”. Systems that behave well in the face of variety can be described as having a resilience that is good for customer, organization and worker alike, another example of balance. Kanban’s help in evolving resilient systems that can deliver predictability for a variety of work item types with a range of performance expectations (timescales perhaps ranging from hours or days to months or more) really is a killer feature.

For more on the role of balance in Kanban see David Anderson’s talk When is Kanban not appropriate [video] [slides]. My talk Kanban the hard way [video] [slides] includes an exploration of variety and resilience.

9.    Collaboration

Collaboration features in the sixth (and last) core practice, “Improve collaboratively, evolve experimentally [using models [and the scientific method]]”.

Building on agreement, respect and customer focus, collaboration creates the expectation that we will look beyond our own team’s boundaries in addressing impediments to flow.

The full version of this practice (with the two optional parts included) speaks of working systematically in a way that improves understanding through observation, model-building, experimentation and measurement (empiricism).

“Using models” has a second sense that suggests values of curiosity and even generosity. Kanban actively encourages its practitioners to look outside the method to a growing body of knowledge. Kanban acknowledges roots in Lean, Theory of Constraints and Agile, foundations in queuing theory and complexity science, influences as diverse as Lean Startup and family therapy. Individual practitioners have their own personal favourite models – I for example draw on A3, GROW, and Influencer.

Why stop at nine?

It bothered me that the Lean value of customer focus can’t be inferred in any obvious way from the standard wordings of Kanban’s foundational principles and core practices – you could say that I had to cheat! I think though it fully deserves its place.

Less so these others that I’ve identified:

  • Learning and alignment have strong associations with understanding. I fully recognise that a strong case can be made for each of these but I’ve gone with the one that I think best reflects Kanban’s roots in System Thinking. My most-referenced article emphasises learning, so this was a tough one!
  • Challenge (also vision) and courage overlap sufficiently with leadership that I don’t regard them as axiomatic. See related post Dole out the 3C’s.
  • Self organisation would rank high as an organisational design value but respect seems to be an adequate guide for the change agent. All else being equal, respect would prefer a solution allowing or building on self organisation over one that doesn’t.
  • Resilience features strongly in my thinking but it describes outcome more than approach. Smoothness and predictability similarly.

Putting values to work

Let’s see our nine values together then:

Understanding, Agreement, Respect,
Leadership, Flow, Customer Focus,
Transparency, Balance, Collaboration

Admittedly, that’s quite a long list – longer than the initial three or four that I have quoted at every opportunity for some time – but not so long that we’re incapable of debating, remembering and referring to them.

Do any of these resonate with you more strongly than others?  What does that say to you?  I might explore that one at a leadership retreat – the differences between practitioners might be revealing!

Do any seem to be missing in your current environment? Again, what does that say to you? Does that suggest to you some things that really need to be put right?

For example, I can look back at times where lack of the right kind of agreement either slowed the pace of change or resulted in change that could revert too easily. From what I read, I don’t believe I’m unique in this.

Reflection

I’ve made values explicit – this is transparency at work – creating an opportunity for challenge (namely that I want to see customer focus feature more explicitly in the core method), and increasing my understanding of at least one source of ineffectiveness. In an eat-your-own-dog-food kind of way, the system works! I like that.

Whether you or the wider community would choose the same values is an interesting question worthy of group exploration. How else might you go about it? I’d love to see some alternative attempts. Could the values I’ve chosen benefit from some additional structure or from being sequenced differently? Or are values so fragile that they’re better left unsaid?

Continuing a line of thought started a couple of months ago in my post How Deep is “How is Your Kanban”, could values provide a better foundation for a second-generation Kanban assessment tool? Does the current tool’s emphasis on practices hide the method’s true purpose? I really think that it might.

As to whether this is a good way to introduce Kanban, this can only be answered by testing it. I intend to!

[Update: I've written some stronger conclusions in a followup post, Values, understanding & purpose]

Fire-and-forget: what it means, some remedies

Posted on by

Even as I wrote it, the first item in last week’s little list of process change patterns stood out like a sore thumb, crying out for further elaboration:

  1. Replace “fire-and-forget” with something robust (e.g handover, trackers, visualisation)

Fire-and-forget refers to habits of one-way communication as a way of progressing work, for example:

  • Processes that allow work to be sent to absent staff without anyone noticing (I see this a lot)
  • Documented processes that end in “Send an email” (not unusual either, especially when descriptions are role-centric rather than workflow-centric)
  • The tendency to consider “done” to mean things like code committed, document sent, order placed, edict announced

Here then are eight ways to address this problem:

1. Confirmation

Here the sender expects, requests, or chases for some assurance that the work product has been received, perhaps even understood.

Pro: Simplicity
Con: Places a burden on the receiving party to respond to something that might have been unsolicited. Chasing adds a cost to the sender that grows with the number of confirmations outstanding.

2. “Proper” handover

Less send & confirm, more explanation & conversation.

Pro: Appeal to professionalism
Con: “Proper” is very much in the eye of the beholder.

I can’t resist my favourite George Bernard Shaw quote here:

The single biggest problem in communication is the illusion that it has taken place.

Substitute “communication” with “handover” for additional emphasis!

3. Collaboration

Instead of handover being an activity in its own right, make the transfer of knowledge and responsibility flow naturally out of the work itself.

Pro: The whole is greater than the sum of its parts (think of your favourite creative collaboration here, not just the sharing of a task)
Con: How to scale?

Collaboration is of course a huge topic in its own right, foundational both to Agile (“Customer collaboration over contract negotiation”) and to Kanban (“Improve collaboratively, evolve experimentally”). It can take time for collaborative approaches to take hold, but don’t be afraid to try it in limited ways.

4. Self-organising cross-functional teams

This is collaboration at scale: teams assembled with the full range of capabilities required to meet the customer’s needs, empowered to adapt in accordance with the challenges they face. We seek to address fire-and-forget by eliminating the organisational boundaries that hinder the flow of work or information in the direction of the customer.

Pro: Super-effective when it works
Con: Not a quick fix. The wider organisation may not support the creation of cross-functional teams; it may even actively resist the idea. Paradoxically perhaps, self-organisation needs the right constraints (boundaries, policies etc) and leadership if it is to function effectively; these need nurturing.

5. Tracking

Together with any/all of the above, implement some basic infrastructure that ensures that work does not fall between the cracks.

Pro: Adds a measure of confidence and resilience, reduces the dependency on what’s in people’s heads
Con: The natural tendency for tracking systems to serve their administrators better than they do the team. Potentially therefore the thin end of a bureaucratic wedge.

6. Validation

This means systematically tracking work right through to its productive use/effect in the field, looking for evidence that the work has resulted in the benefits originally hoped for. Validation makes it very difficult to lose work mid-process, even when end-to-end it spans multiple teams. Sometimes it’s the customer that forgets!

Pro: Its effect on quality; gateway to Validated Learning (Lean Startup)
Con: Constrained by time-to-market, inhibitions

7. Visual management

Tracking made so visible and accessible that it is an integral part of the team’s working environment.

Pro: Tracking without the shortfalls; very low overhead if implemented well
Con: Potentially messy. What to do with sensitive information (a consideration even if non-messy electronic systems are used)?

8. Kanban systems

Visual management of work items through their various states, applying designed-in constraints on work-in-progress (WIP).

Pro: Improved flow, a readily-modified expression of process, a natural focus for self-organised improvement; gateway to Kanban (the evolutionary change method), Lean
Con: See “7. Visual Management” above

Commentary

Space does not permit me to include examples – I’d have a book chapter on my hands were I to do so! I’ve seen each of these approaches first-hand multiple times and I expect you’ve encountered most of them too.

There’s some natural ordering here but I don’t wish to give the impression that the simpler/weaker ones are never the appropriate option. Indeed, even fire-and-forget can be the right choice given the right context. That said, in my home territory of software development, the combination of validation and Kanban operated by a self-organising cross-functional team has proved very effective, bringing about change not just to the software development process but to customer behaviour too.  Powerful stuff.

If I missed anything (here or in my catalogue), do let me know.

A modest catalogue of process change patterns

Posted on by

I have in mind a new talk for 2013 that starts not with Kanban but with day-to-day process change challenges that many people will recognise. Right now I’m looking at a fairly chunky change and I realise that it’s easily described via a number of quite generic transformation steps (“patterns”?):

  1. Replace “fire-and-forget” with something robust (e.g handover, trackers, visualisation)
  2. Refine ready/done criteria for an activity
  3. Move an activity across an organisational boundary
  4. Eliminate a process step (or, conversely, add one)
  5. Change the granularity at which work is managed
  6. Extend process scope upstream/downstream

Each of these are directly applicable to that one particular end-to-end process without being in any way specific to it. In one context easy and obvious; in another quite the opposite (right now, a bit of both). And where, you might ask, does Kanban fit in?  Posing the questions or helping to answer them?  Highly contextual of course – in fact I’m saying nothing yet about the “how”.

I don’t suppose that this list is unique but it seems like a useful starting point and I may continue to add to it. What would you add?

Dole out the 3C’s

Posted on by

I pick that phrase out of Eight Ways to Avoid the Kaizen Roach Motel, from Mark Hamel’s (@MarkRHamel‘s) blog. The 3C’s? Challenge, courage, creativity. That’s a new one on me but I like it – you may recall that I argued for “challenge” a month ago, here.

Hat tip: Curious Cat’s Management Improvement Blog Carnival #182.

When will this project be ready? (and some better questions)

Posted on by

A couple of good articles have caught my eye recently, both extolling the virtues of Critical Chain Project Management (or aspects thereof), namely:

Also announced in the last few days: Troy Magennis’s (@t_magennis) new book Lean Forecasting (“Rapid Forecasting Likely Staff, Cost and Delivery Dates of Agile Software Projects”). Meanwhile there’s always the classic Waltzing with Bears by Tom DeMarco and Timothy Lister.

Here on positiveincline.com I’ve made some small contributions of my own on the subject of planning, for example:

But there’s a problem with these technical approaches…

Is the when will this project be ready question always a good one to ask?   And even when it is a reasonable question, are we guilty of rushing to answer it when more interesting questions need to be asked first?  Questions like:

  • Why do you ask?
  • What will we need to prove?
  • What parts should we deliver first?
  • What else needs to happen for this to be successful?

Moreover, we risk a lot of needless pain and waste if we don’t take the trouble find out what kind of date we’re talking about.  Is it a “bad things will happen if we’re a day late” kind of date, or “I need some cost information so that I can make a priority call” kind of date?

I don’t expect the need for forecasting and schedule risk management to to go away completely, but let me leave you with another:

  • What needs to change in our organisation for the when will this project be ready question to be asked only rarely?

Answer that one, and you’re probably on a good path to a kind of processes that deliver predictability in ways more valuable than just date compliance. Worth exploring, surely?

No-one said it would be easy…

Posted on by

Much as expected, Lean Kanban Central Europe 2012 (#lkce12) turned out to be an excellent conference, probably the best-organised I’ve attended. Well done to the board (Markus, Pawel, Hermanni, Klaus and Karl) and everyone who helped behind the scenes.

The slides for my talk ‘Not “Portfolio Kanban” but “Kanban”’ are now up on Slideshare.  The most important slide is probably the one shown below (#30), which illustrates the scale of the what’s to be done “if we are serious as change agents” (a phrase I used more than once).

Four different directions of interaction to consider. Four different considerations (the “Agreement, Alignment, Models, Challenge”) for each direction. That makes 16 if all combinations are relevant (most will be). Hard work and worth tracking, so perhaps some new visualisations will be needed too – something to think about. I will be talking to David about incorporating some or all of this in the “Kanban depth” tool also.

How Deep is “How Deep is Your Kanban”?

Posted on by

[wonkish, sorry]

I’m busy putting the final touches to my portfolio-related talk for next week’s #lkce12 conference in Vienna. It owes a significant debt to David’s milestone talk How Deep is Your Kanban, but this leaves me with a couple of slightly embarrassing niggles.

Where in the assessment tool are:

  1. Agreement - “Agree to pursue incremental, evolutionary change” is a foundational principle of Kanban and the organisational scope of any agreement is surely assessable. As a change agent, have I achieved 360-degree agreement? If I have, won’t this help make change “stickier”?
  2. Challenge – The language of the tool is big on improvement, implicitly in the direction of “improved” or “fitter”. Isn’t this a bit weak? What about other drivers, direction-setters and pace-setters? Together with “leadership” and “alignment” (already well represented), adding “challenge” might go some way to address the “Kanban is too nice” perception and help complete the connection with Lean organisational practice.

Got that off my chest!

With that out of the way, keep an eye out in my talk for my son’s summer programming project – Kanban meets Design Factory meets Beyond Budgeting. It needs a better name than “Foo” though…

Your customer-in-the-small

Posted on by

…treat any stakeholder who holds any kind of a veto over your delivery … as a customer

This is to ask: have I identified them all, have I considered their needs?

To illustrate this at a small scale, which of these is better:

  1. “I’ve got this code for feature X I need you to review”, or
  2. “I’m about to make a start on feature X. What will you expect to see?”

Former colleagues from my dev management days will recognise this one! Whether you call it “no surprises”, “good risk management”, or simply “taking responsibility”, it’s no contest, surely.

What other sources of delay and unpredictability could you attack in the same way?

Kanban the Hard Way

Posted on by

I’m just back from a fantastic Lean Agile Scotland, many thanks to Chris McDermott and team for putting together a great event.

The slides for my talk “Kanban the Hard Way“ are now up on Slideshare.  In overview:

  1. Kanban works on your organisation – visual management, self-organisation, the knowledge discovery process
  2. Kanban works on your process – pull systems, leverage points, interventions
  3. Kanban works on your system – models for evolutionary change, the Kanban Method and its debt to Systems Thinking, Lean and TOC

I’ve given this talk several times now, sprinting through it as a webinar in half an hour, presenting it in the typical 45-minute conference slot (Lean/Kanban Southern Europe, Lean Agile Scotland) and twice as a 90-minute tutorial (BCS Manchester, Agile North). It’s an introductory talk that never fails to provoke good questions from experienced people too and I always enjoy giving it.

New in this iteration was a reference to Lean Software Strategies by Peter Middleton and my friend Jim Sutton.  I love their advice to treat any stakeholder who holds any kind of a veto over your delivery (my words, not theirs) as a customer. Not only will you do a better job of capturing requirements, it’s very good risk management advice too. The CFD on slide 30 shows what happens when you don’t pay enough attention to this.

Do get in touch by email if you would like to see the notes as well as the slides.  I never present it quite the same way twice so you might not recognise the talk you heard, but they should help with recalling the main concepts. Drop me a line also if you’d be interested in hearing this talk at your organisation or event.