Henry Ford – Master of flow

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200I have recently been presenting a talk on WiP limits and as part of my research I spent some time looking into the history of Henry Ford as he was one of the most influential pioneers of what today we would call Lean or Kanban. He was the pioneer of almost all of our current thinking in industry, and I think was a thought leader in how Agile Software Development is now done.

Theory of Constraints in action

What really struck me however, was how he exemplified the thinking processes behind the Theory of Constraints in all his actions. Everything I read drew me back to that thought.

Ford reduced the average time to produce a car from over 12.5 hours to just 93 minutes.

Ford and his team (I won’t get into the debate as to who had the ideas) created a production line and improved upon it, first by making it a moving production line to keep the focus on flow. Initially simply a winch and rope to pull the vehicle and conveyor belts to deliver parts to the workers. This simple change alone saved hours, previously the workers had dragged their tools along the line of static vehicles as they were assembled.

At one stage the production line for the Model T took 12.5 hours but over the next 5 years Ford reviewed every procedure and managed to cut the production time to just 93 minutes, he cut 11 hours of waste out of an already efficient and profitable system.

hiland2

Ford cut nearly 90% waste out of an already efficient and profitable system.

Was it a big deal?

Was it really that big of a deal?  Yes! In 1914 Ford produced more cars than everyone else, not just more cars than his competitors but MORE cars than all of his competitors in the world combined.

He also produced more with far less, Ford employed 13,000 employees, his competitors combined had 66,000 employees, so the productivity of his employees was 5 times the rest of the industry average.  That fact alone makes you sit up and take notice.

In 1914, Ford’s 13,000 workers built around 300,000 cars — more than his nearly 300 competitors managed to build with 66,350 employees.

Continual Improvement

It seemed like no improvement was good enough and Ford was continually pushing for the next improvement, 5 years of asking What’s next. Identifying every bottleneck and then the next bottleneck, his obsession for improving flow must have been relentless.

Henry_ford_1919

Fighting against local optimization

But Ford was not understood by his peers who’s focus was on Local Optimization, and even his own sales team who couldn’t understand his desire to simplify the design or reduce the price, they wanted options and variety. Ford wanted a car that was affordable to everyone.

Over the years Ford reduced the price of the Model T from $850 (approx. $22,000 in current terms) to just $265 which was less than 3 months wages for his workers.

The price of the Model T reduced from $850 to just $265 as a result of improvements.

His vision was to have a car available to everyone, but especially farmers, and the Model T was designed to be an effective Farm tool, and could easily convert to farm equipment.

I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one — and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.

Henry Ford

People Problems

One of the biggest issues that Ford faced was with his workforce, factory workers were unreliable and his new method of simple repetitive tasks and his desire for rapid growth meant he had high turnover and lower quality workers.

The manual processes Ford devised for assembling the Model T were not complicated but benefitted from training and consistency, so the lack of reliability and consistency of workers was an issue for him.

His solution was to double the average pay of factory workers, Ford offered $5 per day, he reduced the working day to 8 hours and the working week to 5 days, he also offered a form of tenure (on his terms) to all employees.

Ford quipped that it was the best cost saving decision he ever made, with a massive reduction in turnover the cost of training plummeted and productivity soared, and what was really a marketing bonanza his workers could afford his cars.

Blunder or Crime?

This decision was national news. But much of the press despised him helping the poor, seeing it as a social policy rather than a sound business decision.  The press too seemingly had no comprehension of the Theory of Constraints or system level thinking.

They believed he was hurting business, with one major paper calling him a ‘class traitor’, and commenting that he shouldn’t bring “biblical or spiritual principles into a field where they do not belong. going further suggesting that paying factory workers that much “was a blunder, if not a crime … against organized society“. That is pretty harsh for a man just wanting to pay people a little more so he could build cars.

Ford had the last laugh though, employee turnover declined radically, and profits doubled to $60 million in 1916 two years after the policy was introduced from $30 million in 1914.

black car SQ

Any customer can have a car painted any color that he wants, so long as it is black.

Henry Ford

Was the Model T only available in Black?

This for me is the most interesting story of all.  Some say it is simply a myth,  as the Model T was available in many colors over the years, others say it was a metaphor for his policy of being lean, others that it was a metaphor for his dominance in the field and how he could dictate what the customer wants.

Ford himself claims he made the statement in 1909, and yet he didn’t limit production to Black until 1914, and oddly in 1909 you couldn’t get the vehicle in black, it was not one of the 6 color options available. So the quote does have an enigma quality about it.

However, In 1914 Ford restricted the option to only Black and it remained that way for 14 years before expanding to 14 color options shortly before the Model T was replaced with the Model A.

Cost saving?

I have read that the decision to limit to black was a cost saving exercise, with a suggestion that the unit cost of black paint was less than the color options but I have been unable to validate that claim and frankly I find that very hard to accept.  Unit cost considerations have not played a part in any of his other major decisions – the wage decision being a clear example of how flow was far more important to him than unit cost. Cost savings were a consideration at a system level only and certainly not a factor if it impacted on flow.

0

It is all about flow

From what I can deduce from applying lean thinking myself to the situation, Ford would have switched to black even if the unit cost had been significantly higher. Japan Black paint was completely different to the other paint methods and had two distinct qualities that would have appealed to Ford, the first was that it touch dried very quickly and secondly it baked hard in 48 hours, compared to 14 days for the other colors.

Increase flow and reduce Cycle-time

Because the paint could dry quicker it would improve flow and so a production line was able to complete a car every 3 minutes (with 3 minutes effectively being the slowest process on the line).

Reduce Inventory and reduce Lead-Time

For Ford, being able to ship cars from his factory 12 days sooner than previously was massive, he could reduce WiP, but more significantly it enabled him to reduce his inventory of finished goods by 85%.  in 1914 at any given time he would be sitting on over $5 million (retail value) of stock, by switching to Japan Black he was able to ship more and more-sooner. That decision would have been an instant injection of over $4 million dollars (that is over $100 million dollars in 2017 terms).  And by 1923 if he had still been offering colors that inventory cost to him would have been over $30 million ($750 million – 2017 value).  Not to mention the space needed to store 80,000+ vehicles while the paint dried.

Using only black paint was a $750,000,000 Decision

In essence the decision to ONLY offer the Model T in black was a decision worth far in excess of $750 Million in todays terms, and yet very few people understood the ramifications of that decision and many opposed it or ridiculed it, and many still don’t understand it, even with the results being self-evident.

ford-3

What is Productivity?

Business is a lot of numbers, and I don’t want to bore you with figures but the improvements that Ford made to flow and cycle-time and lead-time all went straight to the bottom line, by focussing on flow rather than local optimization, and by focusing on the throughput of the whole system rather than on keeping one worker busy, Ford was able to get his workers to be 5x more productive than the competition by doing less work.

Thinking is the hardest work there is, which is probably the reason why so few engage in it.

Henry Ford

Ford showed the correlation between effort and productivity is a myth, and it is about working smarter not harder. He passed his efficiencies on to the customer, as his productivity went up the price of the Model T came down. Eventually to just $260 in 1925 which is a mere $3600 in 2017 terms.  A car truly affordable to the masses.

1908_Ford_Model_T_Runabout

System Thinker

Ford seemed to understand Systems Thinking and the Theory of Constraints long before either were recognized, and he did so to a level that few of us will ever be able to comprehend and in the face of public and private pressure against this way of thinking and he was often vocally opposed for his decisions.

Ford changed not just his own organization but his actions changed an industry and likely even the economy of a country. He balanced profitability with altruism, although some of his values and politics were questionable and some of the rules he imposed on his workers would be unthinkable today.  But for me he is the pioneer of Lean, Kanban, and the pioneer of the Theory of Constraints, everything since then seems to be built on his shoulders.

Do you know ‘what’ your problem is?

The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on what we are doing both in our work and in our product, and far too little on why we are doing it.

Failing to understand the why

The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.

There is nothing so useless as doing efficiently that which should not be done at all.

Dr Peter F. Drucker

Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice

shakespeare-quotes-9-1024x540

We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?

The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value.  It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.

Refactoring gets sacrificed when throughput is the priority.

Stories focus on the what not the why.

We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’  rather than actually asking why or giving it proper thought and effort into understanding the real why.

Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods.  We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.

It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.

stoneage

Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.

Taking a little while to do it right could well pay dividends.  Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.

Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery.   Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.

The customer should be your focus

Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.

When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.

UX is an afterthought

When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX.  The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.

The goal of a story is NOT to minimize development Effort, it is to maximize customer Value

A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.

A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer.  If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome.  Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.

Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.

Acceptance Criteria is a substitute for thinking and conversation

We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.

images

Being busy is not your goal

It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all.  Keeping you busy is not the goal, delivering the best product to the customer is.

Understanding cycle-time in software

Cycle-time and Lead-time and even Little’s Law are terms that have migrated over into the software development context and are becoming more widely used, but I am not sure they are fully understood so I’ll attempt to clarify my understanding of the terms.

How does cycle time differ from lead time?

In manufacturing:

There are two different ways I have seen to express Cycle-time:

“Cycle Time” is the overall amount of elapsed time taken to create an item. Measured from the point when work starts until item is delivered.

or

“Cycle Time” is the average amount of time between each delivered item.  e.g. 7 items delivered in a week is a cycle time of 1 day

Lead-time seems to be consistent

“Lead Time” is the amount of elapsed time from which the order was first requested by the customer until the customer has received it.

Note: The different uses of cycle time cause confusion and I prefer the first description in a software context, as the second one ignores the impact of WiP. 

Clearly both of these are more complicated in software terms as the boundaries are not as clear.

cycletime

Cycle-time

Cycle-time is generally considered to be the point when a backlog item is committed and the item is “in progress” through our development cycle, in Kanban terms this is likely time counted from when it moves out of the ‘backlog’ column. We stop counting when it is moved to the ‘done’ column.   There can be a whole debate about what ‘done’ means and that is for another topic. But for simplicity the ‘cycle’ ends when your team will stop work on it (ideally it will be in the hands of the customer).

In Scrum cycle-time is typically fixed at a sprint length, we commit at the start of the sprint and deliver at the end.  But that is not universally true, some teams do not always deliver and there will be effort later to deploy as part of a scheduled release, and some teams deliver as soon as a story is complete.

Note: Cycle-time is sometimes called delivery time. But again this get confused with lead-time because of the non-linear manufacturing to software conversion.

Lead-time

Lead-time is a bit more complicated, it may be counted from the point a need is first identified by a customer to when it is resolved but this is rarely a one-to-one mapping, or it may be considered from the point when the need is identified and refined into a backlog item that will be worked on and delivered.

But really for agile backlogs we generally don’t work in a linear fashion, just because a request has been on the backlog longer doesn’t mean it will be delivered sooner. We prioritize and so a request identified last week may be delivered sooner than one from last year.

As a result Lead-time is generally not used as frequently as Cycle-time, not because we can’t measure it but because it is not as meaningful or useful.

Throughput

Another often used term is “Throughput” this is simply the number of units that have passed though the system (units completed) in a given period.  e.g.  Our throughput is: 10 stories per week, or 5 customers per hour.

Unless stated otherwise you can usually assume that it is an average (mean) or the most recent time period.

Little’s Law

Cycle time is a trailing measurement and we are able to come up with metrics and averages from historic results.  But a mathematician from MIT – John Little  devised a mathematical formula for predicatively calculating Cycle-time from the number of units in the system.

Average Cycle Time =  Average Number of items in progress / Average Throughput

Projected Cycle Time   =  Number of items currently in progress  / Average Throughput 

picture1

e.g. So let’s say you have 50 items in progress and on average you complete 10 per week.

picture2

Number of items currently in progress (50)  / Average Throughput (10 per week)

Projected Cycle Time:   50/10  =  5 weeks

What this tells us is that for the new units entering the system, on average it will be 5 weeks before each of them is completed.

If we want to reduce Cycle-time we have two options we can either reduce the amount of work in progress, or we can increase throughput.  Often our throughput is limited by other factors and so may be harder to change, such as team size or equipment availability. But work in progress (WiP) is typically more within our discretion.

Lets say we reduce the work in progress to just 20.

picture3

Number of items currently in progress (20)  / Average Throughput (10 per week)

Projected Cycle Time:   20/10  =  2 weeks

What this tells us is that for the new units entering the system, on average it will be 2 weeks before each of them is completed.

What you see here is that our throughput is the same, we are still delivering the same amount but by reducing work in progress we are able to deliver the same amount in a shorter elapsed time, and in a desire to have more agility then a shorter cycle time enables us to change direction sooner.  Less work in progress does not increase our throughput, however, it makes us more dynamic and more adaptable to change.

The less work you have in progress the sooner it will get done.

Yorke’s motto

In essence – the less work you have in progress the sooner it will get done, that is the lesson that should be taken from this.

But there does become a point where you can reduce the work in progress to a point where throughput is impacted (the system can become starved) and thus there is a trade-off.
In some situations cycle-time is a critical factor so an element of slack time is desirable, say urgent need to see a doctor, compared to a regular appointment.
But in most other cases we would aim to limit our WiP as much as we can to the point where throughput is not impacted.

Other less used terms

Then we come to the fun ones, these terms come from manufacturing but are used much less frequently in a software context but may be useful to be aware of as it can help understand the composition of cycle-time and where you can take action to tighten up your process.

  • Process Time
    • This is the time when someone is working on creating something: writing code, documents, design, tests, etc.
  • Move time
    • In software terms this would the time to move from one user to another or from one action to another and so would include, compilation, building, deploying and hand over/knowledge sharing
  • Inspection time
    • This might be QA time or code reviews, demonstration to Product Owners or stakeholders, but this may overlap with process time as this is still value added work.
  • Queue time
    • This is time when a unit(story/task) is in progress but no worked on, say blocked, or waiting to be code reviewed waiting for QA waiting for Demo, any time work is paused for any reason before it is done.
  • Wait time
    • This is the time a request spends in the backlog before we commit to work on it, e.g. the time from when a customer identifies a feature/function or bug until we start work on it.
  • Value added time
    • Any time in the system where activity that adds value is happening e..g not queuing, waiting.

Summary

Cycle-time and Little’s Law are becoming much more frequently used and whilst they are not complicated to understand the basics of they do bring a new set of terms and associated confusion.

For example I have seen a number of times recently people advising that reducing cycle-time increases throughput.  Mathematically speaking this is incorrect, (although the reverse is true increased through put should reduce cycle-time). Anecdotally less context switching does increase throughput.
What they are advising is good advice – reduction of Work In Progress. However, their expectation and  reasoning is wrong and adds to yet more confusion.

Cycle-time is not a measure of quantity of output, but a measure of the duration it is in the system. It is important to remember that throughput and cycle-time are different measures.

Cycle-time is not a measure of quantity of output, but the duration it is in the system.

I hope this helps and I’d be happy to add any further clarification if there are parts that are unclear.