Friday, March 14, 2014

Not all work "flows"

I've written elsewhere that it's key to focus attention on "Work that Flows" (see Clearvision's blog). That is, work that has a beginning, middle and end (delivery) and some tangible value as the outcome. The thing is not all work does flow. A lot of our time is dedicated to tasks that are simply "overhead". They might be waste - they add no value and serve no useful purpose - but equally they might be necessary activity within the context of how you deliver your work, yet not actually attached to delivery. Project management for example will need to be done for as long as the project lasts - it is not something can be completed independently from the delivery tasks. Sometimes overhead tasks can be removed if the process is changed, but  more often they are a pretty-much immovable feature of the way we work.

I just want to make one point about this - you should know the difference between work that flows and work that doesn't - i.e. overhead work. Don't put overhead tasks on your Scrum or Kanban boards for example. Focus on the work that flows. Whenever you can, eliminate (or minimise) the overhead tasks!

Saturday, December 07, 2013

Postscript on Cycle Time

In my last post Visual explanation of Kanban terms I included a diagram and quotation from the Lean Lexicon (Chet Marchwinski et al Eds, 4th ed., Lean Enterprise Institute, 2008) which defines the meaning of Cycle time (CT1) as:
Cycle Time (CT): How often a part or product actually is completed by a process as timed by observation.
In the interest of completeness, this postscript includes the definition of cycle time (CT2) from Factory Physics (Hopp, W.J and M. L. Spearman, 3rd ed., McGraw Hill, International Edition, 2008).
Cycle Time (CT): cycle time... is measured as the average time from when a job is released into a station or line to when it exits. (Where ambiguity is possible cycle time at station i is written CT(i).)
The definitions are clear, concise, from authoritative and up to date sources and referencing authoritative primary sources. Unfortunately they are also contradictory. It is therefore unsurprising that the relatively new Kanban community finds it difficult to agree on uniform and unambiguous terminology, since the Lean manufacturing community has already had this problem for a considerable time.
Lean Lexicon and Factory Physics - two clear, contemporary,authoritative... and unfortunately contradictory sources

Monday, November 04, 2013

Visual explanation of Kanban terms

David Lowe has produced a very nice video to explain commonly used terms in Kanban in his blog post, Kanban Terminology. Here it is:



The post provides one set of definitions for Lead Time, Cycle Time, Throughput and Takt Time, using commonly applied definitions. The video is helpful and neatly done so I recommend it. However I do have some observations...

Now some of you may remember I said I was resigning as the self-appointed conscience of users of Kanban terminology. People can use whatever terms they like, provided they provide a brief explanation of which definition of a term they happen to be using. In which case, why on earth am I writing this blog to comment on David's excellent video?

(Should I stop now? Ah well, I've started now, so...)

The first point is that the confusion arising over definitions of the term Cycle Time is not a Kanban-specific issue. There are two distinct definitions of what Cycle Time is in the literature of manufacturing. To disambiguate the 2 definitions, I have taken to using the abbreviations CT1 and CT2.

CT1 is the average time between items emerging from a specific point in the process (for example the time between 1 item emerging from that point, say the Collection Window and the next item emerging). This definition is used in the Toyota Production System and is explained in these books and on-line references:
  • Womack and Jones (1996, 2003) Lean Systems.
  • Chet Marchwinski et al Eds, 4th ed (2008) Lean Lexicon, a graphical glossary for Lean Thinkers
  • Mike Rother and John Shook (2003) Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA 
  • Jeffrey K. Liker (2004) The Toyota Way.
  • Professor W. Bruce Chew's Harvard Business School Glossary of Terms (2004) [http://hbswk.hbs.edu/archive/1460.html] well explained in Fang Zhou's blog [http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/]
CT2 on the other hand is the time taken by 1 item to pass between 2 points in a process, for example between the start and end points of the "Collection Process". This definition is used by these books and references:
  • Hopp, W. J. and M. L. Spearman (2000). Factory Physics: Foundations of Manufacturing Management, 2nd (ed.), Irwin McGraw Hill, New York, NY.
  • Donald G,  Reinertsen (2005) The Principles of Product Development Flow: Second Generation Lean Product Development
David Lowe's video uses the CT2 definition but, and here's another reason to be very cautious, unfortunately his example uses a situation where the WIP at each station (for example the "Collection Process") is one. Furthermore (check with Little's Law) when WIP = 1, CT1 = CT2! And this can result in people looking at the example and misinterpreting the definition.

Look at the Collection Process. The time between the start and end of the Collection Process in the video is 40 seconds. This is CT2, the definition for Cycle Time being used in the video. But if you were explaining this to someone who already knew about the CT1 definition, what would they think? The time between one item emerging and the next (CT1) is 40 seconds - no surprise there - so they carry on with their original assumption, and they would completely misinterpret the definition!

My recommendation for using an example to explain your definition of Cycle Time is to always ensure that the WIP does not equal one at any point, so this confusion does not arise. Say we said that the unit of work in this example, instead of being the order was the hamburger, and furthermore assumed that every car orders TWO hamburgers (WIP=2). In this case CT2 is exactly the same. Both hamburgers take 40 seconds from the start to the end of the process. However the average time between hamburgers emerging from this process, i.e. the average CT1, is 20 seconds! CT1 is not the same as CT2.

As David shows in the video, the time between items emerging from the final part of the process, or more accurately the time between items being demanded by customers (the target CT1) is known as Takt Time. Takt is a German word which can be loosely translated as... "Cycle" (aagghhh!). However it's a special cycle time - the target CT1 for the whole process, and thus also the target for each station. In this example, the griller of the patties should be finishing one hamburger every 20 seconds to avoid either under or over-production.

David and I were able to discuss this issue at the recent #lkuk13 conference (we sat together during Troy Magennis's Cycle Time Analytics keynote - yes I know "Cycle Time" again!).  Troy asked me during the presentation what I thought he should use instead of Cycle Time. I replied TIP, or Time In Process since I haven't yet found an ambiguous use of this term, of course realising that I can't change what people choose to use in their presentations - it's up to them. This confusion was pre-existing and no doubt will continue for a long time yet. I just want people to be aware of the nature of the ambiguity of this term. Removing the ambiguity can be quite hard since sometimes (as we've seen, when WIP=1) the two terms are equal, even though they are conceptually completely different.

Note the problem of defining Cycle Time in a context where WIP=1 appears to be common since very often in manufacturing a machine is processing only one part.

Postscript: Here's the diagram from the Lean Lexicon (referenced above) showing their definition of Cycle Time (CT1).

Cycle Time (CT1) From Lean Lexicon, a graphical glossary for Lean Thinkers

See also: Why I don't use Cycle Time in Kanban.

Shortest Possible Definition of Kanban... and why it matters for scaling


If you missed the Lean Kanban UK conference last week (you missed a treat!), there are two things you can do:
  1. Don't miss it next year
  2. Catch up on some of the really excellent presentations, many of which are available on slide sharing sites
These are my slides (above), but also check out those from Mike Burrows on "Kanban through its values", Håkan Forss on "The Red Brick Cancer", Pavel Brodzinski on "Fixing Portfolio Management, Dimitar Bakardzhiev on "Project Planning using Little’s Law", Troy Magennis on "Cycle Time Forecasting" and many others. The hashtag #lkuk13 is a good starting point for a search.

Really - don't miss next year!

Friday, October 25, 2013

Adapt - why success always begins with failure: Tim Harford

Why are you reading this book review?

Adapt came out in 2011 and it's a masterful summary of evolutionary development in economics, society, business and personal endeavour. It looks at the problems of finding solutions in complex spaces, safety measures in complex interconnected systems (like nuclear power stations, domino toppling, oil rigs and banking systems). Harford is erudite, amusing, insightful, anecdotal, informed and at times gripping. It's a great book.

Presumably you're reading this book review because you haven't read it.

WHAT?

You haven't read it?!

Stop reading this book review now! AND READ IT!

Friday, October 18, 2013

What's the quickest way to make a Gantt chart from an agile board?

Don't say it! I know. :-)

But someone actually asked this question this week, adding presumably to avoid embarrassment that the purpose was to "translate reality into management artifacts". He has a point of course. Familiar artifacts can allow people to see new things more clearly; we just also need to ensure that we've all understood what is really different in the new world.

Any way, I suggested looking at the Open Source tool xProcess, which uses its built-in forecasting engine to put start and end dates on a hierarchical collection of tasks or work items based on size estimates and team availability. I reckon if you have a table with task names you can generate such a chart in about 5 minutes.

Here are the instructions. Download xProcess from this site: http://sourceforge.net/projects/xprocess/

1. Create a project by hitting the "New" button like this:

You can choose various templates but just choose Simple Process / Simple Project. It's the.. well simplest.

2. Add the list of work items by selecting "New" again and "Task". (See next screenshot).

3. Hit "Next" and you can add all the names from the cards on your wall as a comma separated list (see screenshot on the right). Leave the "Size" as 2 - we'll come back to that.

4. Now when you go to the Task List tab (or hit  the "Tasks" button) you should see something like the screenshot below. All your tasks are listed all of size 2.0 and with start and end forecast dates of NEVER.


In other word the Scheduler is forecasting none of these task will finish. That's because we have no resources assigned to the project. The simplest quick fix for this is to add yourself to the project. So...

5. Hit the "Resources" button and then "Add/New Resource", select yourself (or add team members) and then hit "Next". This gets to the "Appointment to Project" dialog shown below. You can define availability on this screen or just hit "Finish".

We now have enough information to generate a Gantt chart, albeit with some fairly big assumptions such as a uniform size of tasks and 100% availability of the team we've assigned. Nevertheless we can hit the "Gantt Chart" button and see the result.

Here's my attempt.


There are lots of things you may wish to adjust at this point like the priority order of the tasks, the estimates for the items (either the default value or individual ones) and team availability. You can even add separate subtasks for different parts of the process into a task template and add team roles so the right people are assigned to the right types of subtask. There are lots of adjustments you can make depending how much longer than 5 minutes you want to spend on this. You can even enter (or generate) fixed "target" dates which compare the forecast dates with dates that may have been agreed with a customer ( or are simply the forecast from last month). Endless hours of fun are possible. :-)

However if you just want to give your manager a comforting diagram, the steps above could be 5 minutes well spent!