Tag: Theory of Constraints

Practically Agile

As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.

Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.

  • Systems Thinking
  • Community Context
  • Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.

At the very heart the manifesto is about getting better at delivering software.

“We are uncovering better ways” – it is a journey of discovery, we do not have all the answers.  “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.

Systems Thinking = YOU are not the center of the universe

The goal is effective Agile Software Development, solving a problem for a user, with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .

Transformation failures

In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed.  The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.

An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster.  High performing teams arise when we learn that we are more that the sum of our parts.

The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally and this is the pillar that binds it together and makes it so strong.  We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.

As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.

We challenge our thinking, we question our beliefs and we look for ways to grow.

We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.

If you always do what you’ve always done, you’ll always get what you always got

Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.

5-focusing-steps-113297

Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.

Summary

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.

 

Understanding the 5 focusing steps

The Theory of Constraints (TOC)

The Theory of Constraints complements Agile software development extremely well, it is about applying a mindset of ongoing improvement to your organization. It contains the notion of applying efforts to improve to the areas that will have the most impact and offers some practical techniques for achieving this.

When we talk about the Theory of Constraints what is often thought about are the 5 focussing steps. The steps are not always easy to understand and the wording can be confusing. I’ll attempt to explain the steps with a few examples, where possible I’ll use examples more common to software delivery organizations.

broken-link-lean-theory-of-constraints

What is a constraint?

Firstly a constraint is neither good nor bad, it just is. Your system has a constraint and no matter what you do, it will always have a constraint. You may say that in a perfect system the constraint is the external demand for your product or services, but even then there are ways to increase demand or open new markets, and markets have a tendency to change over time.

Do not treat a constraint as a bad thing to be eradicated, awareness and understanding of the constraint is the goal, what to do with that knowledge is a secondary consideration.

Constraints:

A constraint limits the useful output of your system, so any improvements to the constraint will directly impact on the total output of your system.

Conversely improvements to an area that is not a constraint will have no impact on the output of your system.

example:

toc

Let us consider a simple system.  I can build 3 units a day and I can ship 1 unit a day.   

Shipping is my constraint, Building is NOT my constraint.  If I make improvements to shipping and can now ship 2 units a day I have doubled the output of my entire system.

If however I improve the building aspect of my system and can now build 4 units a day, it is wasted effort as I can still only ship 1 unit.  The over production is stuck there.

Any effort to improve any part of the system that is not your constraint is wasted effort. You should instead focus on improving your constraint.

This sounds obvious, but when your organization breaks areas into silos and measures managers on the performance of their area alone you tend to see this a lot. Teams striving for improvement and additional output when they are not the constraint.  The result is make-work. Things that “you know will be needed later” building inventory and so on.  Sadly cost-accounting supports this dysfunction by rewarding the behavior by classifying work in progress and finished goods inventory as an asset when in most cases it is a liability.

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Eli Goldratt

What is the system?

Our goal when applying the TOC is to identify constraints or rather the constraint in your system.  But that begs the question what is the system?

As a very broad rule of thumb, the system is all that is within your (organization’s) sphere of influence. It is not limited to just one area of the business.

Note: Your sphere of influence should include your market and potential market, and your supply chain, which includes potential recruitment candidates. Anything within which you have authority to influence.  

5-focusing-steps-113297

The 5 focussing steps

  1. Identify the system constraint
  2. Exploit the constraint
    (Make the best use of what you currently have)
  3. Subordinate everything to the constraint
    (Make decisions based on the constraint, the system should run at the pace of the constraint)
  4. Elevate the constraint
    (Make improvements to the constraint)
  5. Repeat the steps

Step 1 Identify the System Constraint

The three most obvious signs of a constraint are:

  • They are always busy
  • Work is piling up in front of them (in the case of people this may be requests for help)
  • Work downstream is starved, people that are dependent on them are regularly waiting

Note: busy work or excessive Work in Progress can mask these signs, so the first step is to stop any non-essential work, anything that is not needed immediately or cannot be traced to the top priority.  By reducing work in progress it will help reveal where your constraint is.  All too often your constraint is busy doing something not needed.

Once you have identified where you believe your constraint is, we move on to the next step.

Step 2: Exploit the constraint

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

Peter Drucker

As we identified earlier any improvement to the constraint improves the output of your entire system. but the converse is also true. Any time your constraint is not working then your entire system is not working, any effort your constraint spends on something that is not immediately needed to deliver value to your customers is output lost to your entire system.  It may not be obvious but this is a key aspect to understand.

Your constraint should be considered in that manner, we say exploit the constraint in the sense that it should be used in the most effective way possible. This means doing the very best you can achieve with what you currently have.

  • Exploit your employees that are constraints to get the maximum value (NOT EFFORT) exploiting a constraint isn’t about a death march, it is about getting the most value from them in the long-term.  A happy employee working a sensible number of hours will deliver far more value than an overworked employee.
  • Work to keep your employees engaged, engaged employees deliver more value.
  • Pay well, your constraint(s) are your company’s most valuable asset, pay them well, they are worth far more to your company than their salary.  replacement, training and adjustment of new employees to replace a constraint directly impact the output of your entire system, learn that cost and value are not the same thing.
  • Only work on the highest priority items, make sure you understand the concepts of cost of delay and opportunity cost. Maximize Value !
  • Ensure there is a buffer of work before the constraint so that there is no idle time, idle time is time lost to your entire system.
  • Avoid multi-tasking, context switching is waste, better to complete one thing at a time, so ensure tasks for the constraint are prioritized properly.
  • Ensure your constraint is not working on anything that could be done (even less efficiently) elsewhere.
  • Ensure your constraint is not working on anything that is not directly leading to immediate value. Is your constraint booking their own travel, or filling in time sheets, or even making coffee? Or are they busy on a feature that you think will be valuable later?  All of those tasks are directly impacting on the throughput of your entire system, could they be done by someone else (or not at all).
  • Does your constraint have all the materials they need, do they have access to the information they need, the right tools and the right support, the right training.  Your constraint should have the right tools, the best tools available.  Your development team should have the fastest computers and the best software for the job, skimping here is one of the most costly errors a company can make.

This leads to a mini-debate on the use of admin assistants and Scrum Masters.  There is a trade-off between the ability for people to solve their own problems, and do their own admin and generally have a broader skill set.  Having an admin to do certain jobs can be a form of exploiting your constraint, but can also create a new constraint if you become dependent on them. Same goes for a Scrum Master, they are a great example of exploiting the constraint that may be your development team: Someone to handle blockers; chase things down; and generally ensure the team is enabled to be most effective all of the time by taking non essential work off them and keeping them focused on delivering value.  But again the risk is that they become the constraint.  Everything is a trade-off.

phoenixproject-680x400

Step 3: Subordinate everything to the constraint

This is generally the step that is the most confusing. What we are saying here is that all decisions you make in your system and for your system should be made based on understanding where your constraint is.

  • Quality, your constraint should not be working on things that are poor quality and may need to be reworked.  Ensure work handed to the Constraint is of the best quality it can be.
  • Identify and anticipate problems, if there are dependencies or potential blockers or risks ensure that they are mitigate BEFORE the work gets to the constraint, blocks at the constraint are blocks to your entire system. Have questions answered in advance where possible.
  • In the case of story writing, it may be that getting the input from the development team upfront at story writing time leads to fewer problems later, focus on flow and using valuable time effectively.  This is not an excuse to silo the constraint, this is about thinking of ways to use the time in the most effective way possible.
  • The rest of the system should work at the pace of the constraint, work should flow, sensible buffers of work should be maintained but no overproduction. Identify a cadence and have the whole system work to that rhythm.
  • Have non-constraints use the inevitable slack time to work on tasks at the constraint.  Developers should be testing, testers coding, anyone and everyone should use their slack to alleviate the work at the constraint, regardless of how inefficient they may be – so long as they are not introducing errors or knowledge gaps that may cause further demands on the constraint later.  This is where encouraging T-shaped people can enable us to maximize flow through our system.

As you can see the importance of understanding your constraint and making decisions based on that

Make the bottlenecks work only on what will contribute to throughput today … not nine months from now. That’s one way to increase capacity at the bottlenecks. The other way you increase bottleneck capacity is to take some of the load off the bottlenecks and give it to non-bottlenecks.

Eli Goldratt

Step 4:  Elevate the Constraint

Once we believe we have done all we can to Exploit the constraint and to subordinate everything to the constraint and we still want to improve further then the next step it to elevate the constraint.

Up until now the efforts have been without investment, it has been to utilize what you have in the best way possible, elevating the constraint will generally require an investment of some kind.

  • Hiring more or better people to support the constraint (only hire for the constraint)
  • Purchase more machines to support the constraint
  • Training or coaching the constraint(s) to improve their skills and effectiveness
  • Purchase better software, faster machines, better tools, conferencing equipment, more meeting rooms.
  • Team building activities, or other ways to improve effectiveness of teams that are part of the constraint.
  • You can consider more drastic options such as switching to a different tech stack, if that enables solutions to be solved quicker or may make hiring easier.
  • Moving to a new location.
  • Entering a new Market or creating more (diverse) products.

Remember all of these options should be undertaken with the specific constraint in mind.

Step 5:  Repeat

Once you have worked through these steps it is expected that you will have been a catalyst for change, it would be good to have a measure of the impact if you can.  But the end result is that your constraint is less of a constraint, allow time to see the impact of the changes and re-assess where your constraint is now. It may be in the same place or a new constraint may have been identified. But in either case repeat the steps and see if further improvements can be made.

5-focusing-steps-113297

Repeat again

The Theory of Constraints is a process of ongoing improvement, if you stop improving entropy sets in and things will get worse, these steps should be repeated and repeated indefinitely and frequently

Applying the Theory of Constraints to Agile Software Delivery

In ‘Agile’ circles there are certain topics that come up frequently, such as Kanban and Scrum, so much so that we often forget that Agile is a mindset rather than a small subset of methodologies.

As the saying goes there are a great many ways to skin a cat, but limiting ourselves to only a few may constrain us from opportunities to improve.  The Theory of Constraints is one of these overlooked options.

The Theory of Constraints (TOC) is often assumed to only apply to industry and manufacturing, which is very sad. TOC is in my opinion the very example of an Agile mindset applied to industry and the techniques can be applied very effectively to Agile Software Delivery.

TOC5

Some common applications of TOC

  • Ongoing Improvements
  • Improve flow
  • Incremental delivery
  • Smaller batches of work
  • Reduced Work in Progress
  • Focus on maximizing customer value
  • Reduce firefighting
  • Reduce inventory of undelivered ‘finished’ work
  • Reduce speculative work
  • Reduce reaction time – ability to pivot sooner
  • Identify potential productivity improvements
  • Expose underutilized capacity
  • Identify skills shortages
  • Identify blocker clusters
  • Identifying new markets or new ways to engage with your market
  • Using cost of delay principles to prioritize work

TOC1

System Thinking

TOC starts and ends with system level thinking, your organization as a whole, not just your team, the whole market, not just your current customers or your current market. TOC requires you to look up and around rather than just looking down.

The Theory of constraints uses the term ‘theory’ in the scientific sense, it is a well defined set of practices that have proven to be very successful when applied appropriately.

The guiding principle is that improvements to anywhere that isn’t your bottleneck is worthless. Think of adding a third row of seats to a car that only ever has one passenger. and that improvements to your bottleneck improve your entire system as a whole so should not be measured in isolation.

This can often feel confusing and counter intuitive, it can sometimes result in decisions that increase local costs and even reduce local efficiencies.  Say shipping by air may seem far more costly per item, but results in an increase in sales that far out strip the increase in costs.  Shipping got less efficient and costs went up, profit per unit went down. All seemingly unwise decisions when considered in isolation.  But the result was that sales went up and so profits increased faster than sales.

And that is the heart of the problem, most organizations create silos and fail to consider the impact of opportunity cost on the organization as a whole. This mindset leaves the shipping department seeking to reduce costs without considering the impact on sales.

In IT this may be seen as saving money by sharing an expert between two teams which means their utilization is high (they are perceived as efficient) but they are not fulfilling their purpose in a timely way to their teams which actually costs the company far more in opportunity cost.  Sadly opportunity cost does not show on a balance sheet and so cannot be seen unless you look for it, and understand the significance of it’s impact.

Having dedicated resources with built in slack often causes traditional managers and PMs to have kittens, they cannot bear the thought of costly resources being underutilised, they only focus on cost, not on the value that people bring and that thinking could be crippling your organisation.

TOC3

Contrary to popular belief your company’s goal is not to keep all workers busy all the time,  it is to be the most profitable it can be now and in the future.  That means effective use of people and not maximum use of people. The two are not the same and until that is understood your company’s profits will suffer.

In agile we suggest dedicated teams and to minimize multi-tasking, limit WiP and so on, this often leads to under utilized resources(people) but far more value to the customer and generally more profits.

Dependent Events

Another key principle is the impact of statistical variation on dependent events.  That is a bit of a mouthful but basically it means that in any given time period, output from a person or a machine varies, neither people nor machines are consistent, we have good days and bad days, some tasks take longer than others, we encounter problems and so on.

The results is that variation in output of one item in a chain impacts on the next and so on, and the longer the chain the more stages are impacted and the more variation disrupts the flow.

This is hard to explain without a demonstration and few people get it until they see it for themselves. Goldratt explained it really well with a game in the book The Goal, but sufficie to say balance is a fallacy.

Balancing the items in a chain (people, processes or machines) does not solve the problem, TOC explores techniques for managing flow to mitigate these problems.

Agile teams apply many of the flow management techniques TOC advocates – training T-shaped people, reducing hand-offs, buffering work, smaller stories, more paths through the system, continuous delivery. These are all techniques that come directly from the Theory of Constraints and have been adopted by Agile development teams.

littles-law-queue

Summary

You would be surprised at how many good ‘Agile’ ideas have come from the Theory of Constraints and yet we continue to consider it to be for industry rather than software. Think how much more we could be missing by not applying the thinking processes.

I’ll try to cover some of the aspects of the Theory of Constraints in future articles with some ideas of how they can be applied to software development.

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.