A Last Message from Denis

For all my life, I've been a remarkably fortunate person. I've been blessed with good health until the last few years, and bathed in the love of wonderful people around me. I've had an abundance of good things. I've had periods of sadness, too, and I very much regret having made those I love unhappy – but those times have passed and it serves no purpose to wallow in what can't be changed. In my adult life I never hurt anyone out of malice, though I know I sometimes did out of thoughtlessness and ignorance.

Tracey & Denis

The last fourteen years of my life I have spent with, and been loved by, and married the one who is to me the most beautiful, intelligent and caring woman in the world. It's impossible for me to express the amount of care and time and patience Tracey has given me, with little thought to her own needs. She has always placed mine first. This path we've had to share since 2009 has been more difficult than anyone can understand unless you've travelled a similar one – and cared as much as she has. She hid her tears from me many times, knowing how much they tore me apart; yet to cry alone and out of sight is one of the saddest things in life.

I was able to truly understand the meaning of love through her presence in my life.

Denis with Sylvia (L), Christian & Alice (R)

I also have wonderful, clever, loving daughters who mean the world to me, and a family – parents, my sisters and their husbands and families, who gave structure to my life through their love and concern. I have a loving stepdaughter, and I have a delightful stepson who has grown in Tracey’s and my care from a little child to a fine man. Tracey’s family has been as my own to me and gave me abundant support when it was most needed.

My life has been completed and fulfilled by some very special people. They know who they are and I won't try to name them here. I've had an occupation all my life that I've loved and which made my work my play; and made my occupation my hobby. Not everyone can say that. After retirement from university life, I did things that have given me great pleasure and, I believe, pleasure to many other people. I have no great unfulfilled ambitions, except the trip to Europe that Tracey, Christian and I planned to do in 2010, and which became impossible when my illness came to light.

If I've clung to life to the end it's only because of the joy of sharing life with close family and friends, and my desire to be with them as long as possible. For me, nothing else mattered but those bonds of love and friendship. To allow them to slip away is, by far, the most difficult thing to accept.

So I say with utter sincerity that I've had a fortunate life – far more fortunate than most people on this planet, and I'll always be grateful for this. But that balance – so heavily in favour of good things over bad in my life – is why I'm also grateful that I had the chance to reflect on my life and its meaning through the window of terminal illness. That time for reflection isn't something everyone gets. It's a window through which things become sharper and more vivid than any other.

It came as a shock nevertheless to face the near-certainty of imminent death at an age when I might have expected to live longer than I did. I thought about death a great deal in the past few years. Not everyone does. I became more aware than ever that life is always a fleeting thing, whether you reach one year of age, or ten or a hundred years. Every life is a little spark that flickers briefly, sometimes brightly, and then the spark fades quickly and passes back into an infinity of space and silence.

That's how we're programmed. While we live for this brief time, our bodies are the bearers of who and what we are. They are not us; they're just the vessels in which our true self resides. We stop sometimes, and try to take stock. We move on, and simply live. We occasionally contemplate the great questions or put them aside as an insoluble puzzle.

This is just how it should be. Whatever endures beyond my body will do so, especially in the form of the consequences of my actions in life, and my only wish is that whatever I've taken from the world, I have been able to give something meaningful back.

When my youngest sister Kay died of breast cancer in 2008, she told us always to look for her spirit in the flowers. This is written on her headstone. It's very apt – life and beauty regenerated. She was an earth person, and she lies at the source of her beloved plants and flowers and trees.

I am a sky person, which is why I wanted my mortal remains to be cremated. Anyone who wishes to can imagine my spirit set free to roam where it will. Day or night, in the eternity of space and time, there's something of me that will be around somewhere.

Sunset - Armidale NSW

Only recently have I truly understood the meaning of the Tibetan verse: ‘Don't mourn for me, but for those who stay behind.’ I am now free. If you mourn for me just the right amount, I am honoured - but celebrate, as I always have done, my life and good fortune – and accept, as I always have, the wisest of all sayings from Chinese philosophy, 

'Who knows what's good or bad?'

I am truly free.

Eulogy for Dr Denis Wright (2/5/1947 – 7/12/2013)

Tracey has asked me to review what we might call the public life of Dr Denis Wright.  Denis and I joined UNE’s History Department at the same time in January 1976 and we retired on the same day in July 2007 so we had a lot of shared history.

Everyone present this morning had a connection with Denis in some way or another and held him in high esteem with great affection.  But which Denis do you remember?  Is it Denis the internationally recognised scholar, the inspirational and innovative teacher, the exacting but supportive supervisor, the enthusiastic hockey player and exuberant coach, the creative film-maker or one of several other roles that Denis filled quietly and self-effacingly?  With the assistance of Tracey’s notes, Denis’ blog and information from Howard Brasted I’ll try and cover most of these aspects.

Denis was born in May 1947 in Gladstone, Queensland but spent his childhood on the family dairy farm in Calliope about 20 kilometres away with two older sisters Jan and Lyn and later a younger one, Kay.  Dairying in the 1950s was the most exacting form of farming and from an early age Denis helped with the milking.  His mother would wake him with a cup of tea and a slice of toast about 5.45 and leave for the milking parlour.  Denis followed and helped with the cows until around 7 before returning to the house to get breakfast for himself and Kay and leaving for school.  After school and at weekends he often helped with the second milking. 

Denis started school early, before he was 5, at Calliope State School where 40 or 50 children were taken to grade 8.  Although he was younger than his classmates Denis did well at school but had a clear view that he was not going to be a farmer.  When asked if he was proceeding to Gatton Agricultural College he told the head teacher “Sir … I don’t want to be a farmer. I want to be a teacher”.  Consequently, he went on to High School in Gladstone and finished there with a result in the senior public exam which won him a scholarship to the Teachers’ College at Kelvin Grove in Brisbane.  When he left home to stay with his mother’s sister, Auntie Mavis, he was not yet 17.

Followers of Denis’s blog will find many stories of his childhood and they all reflect the innocence of a very different era though there are amusing tales of his misadventures with Bimbo Brown and the organizational perils, tinged with a frisson of danger, in having a ‘Calliope girl’ and a ‘Town girl’ for the different local dances.

The teachers’ course was 2 years but within two weeks of its commencement Denis had enrolled in a BA at the University of Queensland which could be studied externally with twice-weekly evening classes.  Here serendipity shaped Denis’s future.  There were only three options in the history programme and he didn’t fancy European or American history but Indian history sounded different and interesting.  More importantly he met two people who were to have an enormous influence both professionally and personally –Dr Damodar Singhal and his wife Dr Devahuti.

Denis & Duncan

Denis finished Teachers’ College at the end of 1965 and was appointed first to Gladstone Central school and then to his old school at Calliope where he found himself teaching his younger second cousins in the same rooms where he had been a pupil.  During the two years he was teaching he kept on with external studies for his BA expanding his interest in Asia with courses on China, Japan and the Modern Far East and always with good results including a Distinction that was surprisingly upgraded to a High Distinction and allowed him to apply for and win a much prized and rare Commonwealth Later Year Award that enabled him to go to university as a full-time student. 

Back in Brisbane Denis lodged with his father’s sister Auntie Amy and was soon joined in the city by Kay who was also at the university.  In the long university vacations Denis went home and worked in an assortment of summer jobs, as a postie, a barman, a wine waiter and a labourer on the coal wharves stacking oil drums.

Denis imagined he would return to teaching and, in time, probable promotion to a headmastership, but he was persuaded to do Honours in history with a thesis on the Kashmir Dispute.  His kindly mentors Drs Singhal and Devahuti then asked him to stay on as a Tutor on the History of Asian Civilisations course which he did from 1971 until he moved to UNE.  A Tutor was paid more than a teacher of an equivalent age and Denis saw this as an opportunity to marry Janette and, with regular renewals of his contract offering security, to start a research MA on the relations between India and Pakistan.  He was 23.

In 1973 on the day he submitted his MA Denis enrolled for a PhD on the new state of Bangladesh which was formed in 1971 from what had been East Pakistan.  With the commitment that we have all seen in various settings, Denis threw himself into research with a trip to London and a stint at Chatham House with several months in India and Bangladesh before returning to Brisbane to continue as a Tutor and work on his research topic. 

By the time he accepted the lecturing position at UNE in 1976, Alice had arrived in 1975 to be joined by Sylvie four years later.  Denis suspended his PhD while he constructed new courses, wrote lectures and external teaching materials but a study leave in 1980 allowed him to do the work in the USA, India, Pakistan, Bangladesh and Oxford that finally enabled him to finish and submit his thesis.

This is not the place to recite a catalogue of Denis’s many publications.  It is sufficient to note that he wrote several books, co–authored others and published many chapters and articles on aspects of Bangladeshi history, politics and culture and that he was a widely recognized expert on the modern history of the sub-continent and, of course, on Bangladesh in particular.  He wrote articles on child labour and the trafficking of women and girls in Asia and the chapters for an Australian government report on child labour in Bangladesh and Nepal that has been used by other governments as a model for combating child labour in developing countries.

Denis spent several study leave periods in Bangladesh, including one when virtual civil war raged around Dhaka and he heard the bullets snapping overhead.  His first two books on Bangladeshi history and politics were published simultaneously in that country and India.  It is typical of Denis that he arranged that the royalties on these books remain in the sub-continent and be distributed to various charities and foundations.  The number sold and the extent of the charitable outcome is unknown but both have enjoyed a constant cycle of reprints and republication by other publishers.  Denis became such a well-known figure in Bangladesh that he was affectionately referred to as the ‘white Bengali’ – speaking and reading both Hindi and Bengali – and an observer who understood the psychology of both Hindus and Muslims.  Indeed, it was for that reason that he was invited in 2001 to give the keynote address at the inaugural meeting of the Bangladeshi Psychological Society at Dhaka University.

At UNE Denis was an inspiring teacher.  Through his long-lasting, full-year unit The Great Traditions of Asia he introduced generations of students to the history, culture, philosophies and religions of India, China and Japan.  It is no exaggeration to say that he opened the minds of many to the possibilities of ‘otherness’ and he displayed manifest satisfaction when students began to switch on to the cultural history of South and East Asia.  He was also a very good supervisor at all levels; exacting in his insistence on accuracy, use of evidence and elegant expression but always supportive and eager to see his students realise the same goals that had been his as a young scholar.  He was the pre-eminent innovator in the Department and later the School in his use of emerging technologies in distance education.  Indeed his foundation unit was one of the first to be offered online long before it became standard practice.  He was also the acknowledged, though unpaid, ‘go to’ man when any of the historians encountered problems with their computers.  You must remember that those were the days when it was decided to issue computers to all staff but there was no money to train colleagues how to use them.

His contribution to the profession was no less significant.  In 1984 he became the Treasurer of the South Asian Studies Association, the professional body representing scholars in that field.  This was when the colleagues in Asian history at UNE took over a virtually moribund journal and turned it around so that it is today regarded as one of the world’s best.  In 2000 SASA awarded Denis Life Membership as an acknowledgment for the twenty years he served the Association.

Denis met Tracey when she was studying philosophy and world religions.  They had much in common, as we came to realise, and with his first marriage over Denis pursued a romance with his customary diligence.  Tracey eventually moved to Armidale in 1999 and her passion for music and the theatre opened up a whole new area of interest for Denis.  He started to make films of Musical Society productions and after his retirement he continued to film, edit and produce DVDs so successfully that he and Tracey set up Tabbycat Productions - a small filming and editing business.  As you can imagine Denis quickly mastered the intricacies of digital editing and production and was getting ever more enthusiastic about the venture when his illness was diagnosed.  Denis was made a Life Member of the Musical Society and an award set up in his name.  It is a fitting acknowledgement of everything Denis stood for that the chief criterion in selecting a recipient for the award is that their commitment to the Musical Society outweighs their desire for self- promotion.

That brings me to the last substantive category of activities that I must mention so that everyone has a proper appreciation of Denis Wright.  He was for many years an active contributor to Brain Mass, an organization that provides professional online academic assistance and advice.  For almost two decades he was one of just three directors of an international aid agency [BODHI] that raises and distributes thousands of dollars to charities, mainly in South and Southeast Asia, bringing health and education to thousands with the key principle being sustainability.  In 2010 BOHDI established four annual scholarships in Denis’s name for girls in Bangladesh.  Denis also assisted ANTaR –Australians for Native Title and Reconciliation – with graphic design and layout for their regular newsletters.  He was a hockey coach for ten years in the 1980s and 90s and is remembered by many of his hockey girls in town.  He also took groups for educational tours across China and was especially fond of travelling the old Silk Road.  Lastly through his blog, ‘My Unwelcome Stranger’, Denis has given many other people who are confronting a brain disease, as either a patient or carer, a source of information and inspiration of such significance that the blog has been selected for preservation by the Australian National Library in its Pandora Archive.

When we spoke with Denis last week, Howard and I told him that if everything we did as academics and in life was boiled down to a couple of questions they would be ‘was it all worthwhile’ and ‘did I make a difference’?  And that for him, the answer was an unequivocal yes!

David Kent

Painting by Den's niece - Jessamy Gee

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

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!

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!

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!

What is Kanban?

"What is Kanban?" you ask.

Well really that is three questions. Firstly what is a kanban?

1. A kanban is a visual signal.

It is a Japanese term meaning a card, brand or sign. In lean production systems it's used as the signal to an upstream part of the process that items are required by a downstream part of the process.

Which leads to the next question. What is a kanban system?

2. A kanban system is a system for managing work that uses (real or virtual) kanbans to control the flow.

Kanban systems were first used in Toyota for manufacturing but are now widely used in a wide variety of applications including health services and knowledge-based work such as software development. In principle a kanban system is a "pull-system" where work is triggered by demand from a downstream part of the process - ultimately by the demand of the consumer or commissioner of the product. The systems use kanban signals to prevent over or under production in various parts of the process. The kanbans may be "real", for example an empty hopper which is sent back on the production line to indicate that more parts of a given type are needed, or "virtual", such as the signals derived from a kanban board when a "story card" is moved out of a column. In both cases they indicate to the upstream process that another item should be produced, processed or selected.

"But hang on! I thought Kanban was a method."

You're right. That's the third question, the third part of what is Kanban. To be crystal clear, we should ask "What is the Kanban Method?"

3. The Kanban Method is an approach to defining and improving kanban systems.

The Kanban Method emerged from work being done by many practitioners in software management, agile and lean methods and new product development  during the first decade of this century. The author of the method was David Anderson, but many others contributed or were doing similar work which fed into the method, including Drago Dumitriu, Jim Benson (co-author of Personal Kanban), Don Reinertsen (author of Flow), Karl Scotland, Corey Ladas (author of Scrumban), Alan Shalloway, Arne Rooke, Mattias Skarin... there are many more than I know about. Kanban was first formulated as a method in a paper presented by Anderson at the Agile 2007 conference in Washington DC, and in 2010 Anderson published what is still the principal authoritative text on the method, "Kanban: Successful evolutionary change for your technology business".

As Alistair Cockburn has observed the word "method" may confuse here - he suggests "reflective improvement framework" is closer to the intention (if it weren't such a mouthful I might agree with him!). I would say Kanban is a method, but a method for defining and improving a process, not the process itself or even a process framework. As such people are often confused by what they think are properties of the Kanban Method, whereas in fact they are simply characteristics of a particular kanban system that they have observed. Try not to be confused or you may miss the crucial value that Kanban can bring to your organisation - continuous evolutionary improvement. A method such as Scrumban for example is an application of the Kanban method to a process that starts off as Scrum or Scrum-like. Scrumban is Kanban, but in a particular context!

Elsewhere in this blog I discussed my shortest possible guide to adopting Kanban, based on the underlying paradigm, the principles and the practices of the Kanban Method. Here it is again:

1. Change your viewpoint (lean flow paradigm):
   See work as flow
2. Change your mindset (foundational principles):
   Start from here and improve
3. Change your process continually (core practices):
   Make work and policies visible; make validated improvements

The mechanism of change in agile approaches

"Evolution" and "revolution" describe 2 mechanisms of change:

1. Revolution: sweep away and replace
2. Evolution: copy; differentiate; select; amplify; repeat

This defines the difference between evolution and revolution - not the size of the change, or even the size of the steps in that change. It's the mechanism of change that is significant, because evolution (surprisingly to most people) can sometimes produce large changes in short periods, while revolution sometimes involves quite small changes.

Perhaps a discussion for another time is how this relates to politics and management, and why it is that many politicians/managers (even conservative ones) favour revolutionary changes - that they can take credit for? - over evolutionary changes, which necessarily require competition between ideas and failure of quite good ones, so that better ideas are amplified.

The mechanism of evolutionary change can be seen again and again in agile methods. I''ve written elsewhere about its relevance to the evolution of processes in Kanban (see "Evolution and the culture of an adaptive organisation"). Here's another example from a test driven process: the "test-change-test-change-test" cycle in BDD and TDD-like approaches.

A Test-Driven cycle in agile development

The point about this process is that it must start and end at "survivable" points, where specs, tests and model (i.e. code) agree. There are many cases where tests or metrics fail the quality test (a "red-bar" or failed build results) and these cases must either be changed again or reverted. There are also many points where change can be introduced: the model, the requirements or the tests of fitness, but every change is subject to the selection criteria which eliminates the unfit and amplifies (promotes to "head" - where it is again copied and modified) the instance with improvements.

This is not like evolution. It is evolution.

Improving Waterfall Processes (a thought experiment)

Some recent discussions about whether Kanban is an agile method or not seems to me to miss the point somewhat. The Kanban method is about improving your process, so whether you end up with an agile process depends on two things:

1. whether your process was agile to start with
2. whether "more effective" maps to "more agile"

The first point started me thinking whether I could design a thought experiment by using Little's Law on that anathema of all non-agile processes - Waterfall! (Just say "no" I hear +Karl Scotland say. :-) More on that below, but let's deal with the second point first. 

Agility is the ability to change direction quickly in response to changing circumstances. A few businesses operate in very stable conditions and can optimise their processes to just these conditions. For them increasing throughput is usually the highest priority - agility may not be high on their priority list. However most of us working in knowledge-based disciplines find that the needs of our stakeholders change very rapidly. The ability to track this moving target and deliver new ideas faster is the key to being "more effective". For us agility does map to effectiveness.

So if we've decided being more agile is desirable in our context, how to go about it? Here are two possible approaches:

1. Look for a checklist of "agile practices" and adopt them (you may need a consultant who's cleverer than me to advise you on which ones must be adopted together and in which order!)
2. Look for a way to measure your "agility" then see if these measures improve as you make incremental changes to your current practices.

There is value in both approaches of course, since they are not mutually exclusive. However I know I am not alone in seeing failures in agile adoption initiatives where dependent practices are introduced in the wrong order (for example Scrum for team organisation, without automated build and test for regression testing). 

The second approach relies on having some measures of agility. Here are three from a recent David Anderson blog. They are cadences all measured in units of time:

1. how often can an organization interact with its customers to make selection and prioritization decisions about what to work on next? (queue replenishment period)
2. how quickly can the work be completed from making a commitment to do it? (lead time)
3. how often can new completed work be delivered and operational? (release period)

Now let's go back to whether your process was agile to start with. Let's take a fairly "waterfall" process, typical of many larger organisations, and let's see if focusing on just these metrics could provide significant improvements in agility. This thought experiment relies on Little's Law, which we can express as:

Lead Time =  WIP / Delivery Rate, where

Lead Time is the time a work item spends in the process (TIP or time in process is an alternative term)

Delivery Rate is the number of items delivered per unit of time (also called Throughput)

WIP is the number of work items are in the process at any point in time.

The initial waterfall(-ish) process

Our initial scenario is a product development company releasing a new version of a product roughly every 6 months, say 120 working days. It's not as extreme as some waterfall projects where no customer deliveries are made until years after the requirements are defined, but nor is it very agile. 

Let's say this project releases 24 new "Features" (independently releasable functionality) which are selected at the start of the analysis phase for each 6-monthly release. Each Feature can be further broken down to around  10 User Stories. (Or whatever the waterfall equivalent is! Development tasks say.) There are 3 stages in our (very simplified) process: Analysis, Development, and Release. Testing is included in the Development phase (something they must have learned from a passing agile team!).

• Analysis of an Feature takes a Business Analyst an average of 20 working days. The team has 4 Analysts so 24 Features will take 120 working days to specify.
• Development of a User Story takes 2 developers (possibly a Programmer and a Tester) 5 elapsed days to complete. With a team of 20 developers, this phase will take around 120 working days to complete the 240 stories.
• Release typically takes 10 days elapsed regardless of these size of the release. We assume however that development and analysis work may continue in parallel with this phase.

A View of the Features in Process

How do the 3 agility metrics look with this process?

• queue replenishment period: this is around 120 working days. When a release comes out and the development team start on the next release, the analysts start on the release after that, so its 120 days between each of these requirement selection meetings.
• lead time: from selection of the 24 Features, through their analysis (120), development (120) and release (10), the wait is 250 working days
• release cadence: this is the 120 working days between releases

The average Delivery Rate for this process is 0.2 Features per working day.

Let's compare this with the ideal continuous process assuming the same productivity as above but releasing as frequently as possible. Now such a change cannot be made immediately - it's a major mistake to increase the frequency of releases without improving automated build and test for example. It's more important to select smaller incremental steps where the risk of breaking the system is lower but effectiveness (including agility) can be shown to improve. But for the purpose of our thought experiment let's jump forward, assuming the basic numbers are the same, but we've reached a stage where the process can run continuously. Let's also assume the 4 analysts working together could deliver one Feature spec in 5 days rather than the 20 taken by one lone analyst.

WIP Limits for the New Process

A new Feature will be started on average every 5 working days. Dividing our 20 developers into 4 teams will allow each team to deliver separate Features, averaging 20 development days per Feature. The average arrival rate of completed Features will be 1 every 5 days. Unless we can reduce the 10 days required for each release, we would have to release 2 Features at a time, but even so our agility metrics will show massive improvement.

• queue replenishment cadence: as a new Feature is started every 5 days, we can select Features one at a time every 5 days (down from 120). If the business selected 2 at a time the period would be 10 days.
• lead time: from selection of each Features, through its analysis (5), development (20) and release (10) the wait is 35 working days (down from 250!)
• release cadence: this is now down to 10 working days between releases (down from 120). This is the minimum without addressing the release process itself - an obvious place to look for further improvement.

The average Delivery Rate is still 0.2 Features per working day (this is inherent in our assumptions above). 

The conclusion from this experiment? Agility can be measured and it can be improved radically by changing batch processes into continuous ones (or making batches as small as possible). Agile practices are needed to enable effectiveness and improved productivity at low batch sizes, but the pay-off is seen in the reduction in the times between queue replenishments and releases... and most especially in the reduction in lead time.

Footnote on Little's Law calculations:

The improvements in the 3 agile cadences in this thought experiment are based simply on adding up the times suggested by our scenario. We can derive these results using Little's Law instead, which is easier if the numbers don't drop out quite so easily as our simple scenario. First let's re-run the scenarios above.

Here's the initial waterfall process:

Average Delivery Rate = 0.2 Features per day
Average WIP = 24 Features in Analysis + 24 Features in Development + (24 in Release) * 10 days / 120 days
Thus Average WIP = 50 Features

This results in an Average Lead Time = 50 / 0.2 = 250 days

Here's the more continuous process:

Average Delivery Rate = 0.2 Features per day (still)
Average WIP = 1 Feature in Analysis + 4 Features in Development + 2 in Release
Thus Average WIP = 7 Features

This results in an Average Lead Time = 7 / 0.2 = 35 days

What would be the impact if we could reduce the 10 days of the release process down to 1 day (maybe by introducing techniques from Continuous Delivery). What would the new Lead Time be? Is it just 9 days less? Let's see.

With a 1 day release process, we can deliver Features one by one with a release on average every 2.5 days. So the figures become:

Average Delivery Rate = 0.2 Features per day (still our assumption)
Average WIP = 1 Feature in Analysis + 4 Features in Development + (1 in Release) * 1 day / 2.5 days
Thus Average WIP = 5.4 Features

This results in an Average Lead Time = 5.4 / 0.2 = 27 days

The reduction of 8 rather than 9 days is not easy to derive intuitively, proving the worth of Little's Law to continue the thought experiment and gauge the impact of improvements to other aspects of the process.

Why not try a few scenarios yourself?

Evolution and the culture of an adaptive organisation

One of the books that has most influenced my thinking about agile methods recently is The Origin of Wealth by Eric Beinhocker (Random House 2007, McKinsey & Company Inc. 2005). It's a book about economics rather than software products or development processes, so it's perhaps unsurprising it's less well known in agile circles than it ought to be. However it contains some key ideas vital to understanding the context of agile methods, specifically how products and processes evolve. Significantly it points the way for agile methods to focus on the evolution of process rather than simply the evolution of products - an insight Kanban has brought sharply into focus in recent times (not without controversy it has to be said!).

The mechanisms of evolution are the same whether the subject of evolution is a life form or the elements of an economy. These mechanisms - copy; differentiate; select; and amplify; repeated over many iterations - occur in all instances of evolution. Beinhocker demonstrates that the process by which "Physical Technology" and "Social Technology" have developed in the history of human economic activity is evolution. It's not just like evolution, it actually is evolution, with similar characteristics advantages and drawbacks that arise from it.

Furthermore its success is absolutely remarkable in both the scope of economic growth and its accelerating speed. Physical Technology refers to the artifacts of human activity from pottery and stone axes to razor blades, mobile phones, insurance policies and car washes - "product" is perhaps a simpler term. Social Technology refers to the means by which humans organise themselves and the mechanisms they use to produce the products of the economy - again I prefer a simpler term, "process". Products and processes have been evolving in an accelerating manner over millennia. At this point in history it is essential to economic survival, not only to understand these mechanisms, but also to actively participate in them. As others have said: "change - like survival - is optional!"

One of the most relevant sections of what is after all a fairly dense 600+ pages, occurs at the end of the book. Beinhocker turns his attention to how businesses need to behave within the very rapid cycle of innovation that now characterises the economy. Evolution is taking place outside organisations whatever organisations do. Whether it happens within an organisation however, and thereby enables the products and processes of the organisation to evolve sufficiently to survive and thrive in the new context, depends on the culture of the organisation - whether it is an "adaptive organisation". Rigid hierarchical organisations can survive if their context (market) is either controlled by the organisation itself or changing only very slowly. When enough change occurs to allow new organisations to compete, such rigid organisations disappear. In fast moving markets only "fit" organisations can survive in the long term.

Here is Beinhocker's summary of the characteristics of adaptive organisations that can survive in today's markets:

• Performance norms
• Performance orientation – people go the extra mile, continuous improvement expected
• Honesty – people are honest, transparent and face reality
• Meritocracy – rewards are set on the basis of merit
• Cooperating norms
• Mutual trust – trusting and trustworthy
• Reciprocity – the golden rule
• Shared purpose – common goals above personal
• Innovating norms
• Non-hierarchical – quality of the idea over status of proposer
• Openness – curious, outside thinking, experiment, seek the best
• Fact-based – facts rather than opinions ultimately count
• Challenge – competitive urgency, race with no finish line

These are the characteristics that allow evolution to occur within an organisation - not just by its death and replacement. Are you struck, as I was, how closely this mirrors the goals and norms of agile teams?

It is no coincidence that agile values match those of adaptive organisations. Agile methods recognise evolution as the key mechanism at work in improving products and improving processes. Kanban as defined in +David Anderson's Blue Book explicitly calls out evolution as the mechanism of change in its principles. Furthermore it has made the key leap beyond earlier agile methods that proposed a static Social Technology to implement evolving Physical Technologies (i.e. the use of a pre-defined process). Kanban applies evolution to the Social Technology itself. Kanban in that sense is a meta-process, a means to keep organisations in Beinhocker's "fit" state by evolving the processes it uses. In my view this makes it important for all agile teams to understand, whatever label they apply to their own current process.

The way you yourself change is at least as important as the way you change the things you are producing.

Acha Bacha

Apples

Apples

I see a red ball up in the tree.

I feel the Apple smooth skin.

I taste a juicy Apples.

I heer the bees buzzing in the Apple tree.

I smell fresh Apples in the tree.

       

Kids Little poem

Red Roses

Roses are Red,

Violets are Blue,

Sugar is Sweet,

And so Are You.

       

Morning Poem

Why I don't use Cycle Time in Kanban

Why I don't use cycle time in Kanban from Andy Carmichael

These slides were produced in response to a request for a brief summary of the terms I use for describing flow systems, particularly in a Kanban context. Along the same theme also see The difference between Cycle Time and Lead Time, More Musings on Little's Law, Visual explanation of Kanban terms and In search of unambiguous terminology for Flow systems.

What is there to be afraid of?

What is worthy of our fear? Is Death? Surely not. He who lives will die, and such inevitability must be respected and known, yet not cause dread. No more fear taxes, since he who earns can scarce keep it all, can he, any more than he can take it with him? For what purpose would you keep it all? I grant you death and taxes should be avoided - where it's possible to do so with honesty and honour. But they are not worthy of our fear.

Maybe boredom is a more suitable object. To live an uninteresting life is both eminently possible and profoundly fearful. Don't you have a mind though, and doesn't it engender imagination? And is it beyond that imagination to find an action, project or enterprise that could engage you in some means of improving your own or your fellow's lot? Boredom is not worthy of fear, since it is easily remedied.

Yet I think there is an entity worthy of fear, fear true and cold. It is waste... the waste of human potential. Such waste inhabits every corner of life where ideas spring up and are swallowed, spontaneously springing to life and dying like fundamental particles separating and colliding undetectably in the depths of space. Waste of human potential is omnipresent. It occurs in places of learning, and places of work, in families and in churches, in friendships and in war. It steals not only from those whose potential is untapped but from their communities, their

 relationships and indeed all society.


Fear this waste. Yes. Fear it and fight it.

More Musings on Little's Law

My previous posting about why not  to use Cycle Time in Kanban resulted in some interesting discussions, and I'm grateful to +Steve Tendon for pointing me in the direction of this paper [1] by John D.C. Little and Stephen C. Graves which gives some very helpful historical background into the derivation of Little's Law, its applicability and some of the terminology used.

From Little and Graves (2008)

Little's own formulation of the "law" was as follows:

L=λW

where

L = average number of items in the queuing system,
(equivalent to WIP in Kanban terminology)

W = average waiting time in the system for an item,
(equivalent to System Lead Time)

λ = average number of items arriving per unit time
(equivalent to Delivery Rate, assuming "stationarity")

With Kanban preferred terms we can see this maps to:

WIP =  Delivery Rate * Lead Time
or
Delivery Rate = WIP / Lead Time

Little used "waiting time" for the time taken by one unit to traverse the system (W) because his original context was queuing systems. For other applications he suggested Flow Time, which I think is a very useful alternative.

He also notes though that other authors use other terms for W, including cycle time, throughput time, and sojourn time, depending on the context. Yes - cycle time I'm afraid is in that list which is why confusion still abounds. This conflicts with the more generally accepted definition of cycle time in manufacturing, which corresponds to the target rate of working expressed as Takt Time, and is the reciprocal of Delivery Rate. In other words this confusion of terminology is at least as old as the reference Little and Graves cite: Factory Physics by Hopp and Spearman (1st edition:1996).

Useful background, but the message to me is still: "Don't use Cycle Time in Kanban!".


References:

[1] Little, J. D. C and S. C. Graves (2008). Little's Law, pp 81-100, in D. Chhajed and TJ. Lowe (eds.) Building Intuition: Insights From Basic Operations Management Models and Principles. doi: 10.1007/978-0-387 -73699-0, (c) Springer Science + Business Media, LLC http://web.mit.edu/sgraves/www/papers/Little%27s%20Law-Published.pdf

[2] Hopp, W. J. and M. L. Spearman (2000). Factory Physics: Foundations of Manufacturing Management, 2nd (ed.), Irwin McGraw Hill, New York, NY.