Tuesday, September 16, 2014

Care about business strategy? - Tune to this channel...

If you think the principles and values of agile extend beyond the narrow boundaries of software development teams to organisations and corporate cultures, I think, like me, you'll be inspired by a couple of presentations from the recent Agile On The Beach conference, They are great bedtime viewing (for when you've finally had enough of Bakeoff!).

Firstly a video from Tom Sedge: TDD for Business Strategies – Developing Business Strategies Test-First.
Tom Sedge provides very practical advice on how to define mission (why we're here - our purpose and driving cause), vision (where we're heading - how the world will be different), goals (what we want - destinations or desired outcomes), and strategies (how we will get there - potential routes to the destination). His examples of good (Tesla, SpaceX) and bad (Kodak) missions/visions are particularly helpful. How could the inventor of the digital camera go bust, just as digital photography exploded on scene, particularly as their founder George Eastman expressed his vision in the 1880's as "a world where the camera is as convenient as the pencil". These days I quite often wish I had a pencil on me, yet I always have a camera! His vision makes a sad contrast with Kodak's mission and vision statement from the early 2000's - a paragraph of unmemorable platitudes about customer focus and shareholder value, that no one outside the company would care a fig about!

The second one is from Bjarte Bogsnes, Vice President of Performance Management Development at the major international oil company, Statoil. It's on Beyond Budgeting – an agile management model for new business and people realities. If you give it a listen you'll understand why (even though I think budgets are essential) I'm not that keen on investing much time in annual budgeting. In his words, the approach "... is about rethinking how we manage organisations in a post-industrial world, where innovative management models represent the only sustainable competitive advantage ... releasing people from the burdens of stifling bureaucracy and suffocating control systems, trusting them with information and giving them time to think, reflect, share, learn and improve."

Remember he's talking about a massive oil company - not the easiest place to introduce agile thinking! Gives hope to the rest of us.

Thursday, September 11, 2014

x-Banning a process

I've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way here!

Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!

When I was asked in early 2013 if I would work with Clearvision's product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.

There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.

Start x-Banning your process now!

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.