Cargo Cults

Back in World War II, in what is now known as Indonesia, Japanese and American forces set up base camps. These base camps were set up to provide supplies and ammunition to the forces in the region. Planes were called in using radios. The operators would wear headphones and talk into microphones and call in the planes.

To the primitive indigenous people, this was like magic. They would see the actions of the soldiers and see the outcomes of cargo, the precious cargo drop from the heavens via air drops. Be brought in by planes. Spectacular battles would be fought on the ground and in the air. Then all of a sudden it would all stop. The cargo that they treasured so much that would come from the heavens no longer came. The people that brought it, gone. What were they to do.

So, the indigenous people would try to mimic what the soldiers did. They made radios out of wood, Headphones out of coconuts, planes out of sticks and straw. No matter what they did, no matter how much they tried, the cargo would not come.

The same can be said about those that try agile and DevOps without understanding. For whatever reason, for example, a manager or C level executive reads about how Agile is getting results much quicker and with much better quality than traditional methods. They may even read a couple of blog posts. They read that Agile/Scrum has stand ups, Sprints of 2 weeks. So they implement that.

You might even get a planning session, only a hour or so, just long enough to assign tasks to the team members for the sprint.

Here, we see Cargo Cult activities in action. These practitioners of agile go through the motions. There may be some improvement (That just shows how dysfunctional Waterfall is), but most of the time, they will fail and not understand why. Therefore the thinking is that Agile is a failure and does not work.

In these cases, the thinking is that the process has all the magic.

Another variation is that CI or CD is implemented. Again, the system may have some benefits, but most of the time it fails. I this case, the thinking is that the magic is in the technology.

Again, cargo cult. Going through the motions. Following the process without understanding, and expecting the magic to happen.

Primarily, these approaches are both wrong and miss the point. The magic itself is in the people. When the people accept agile, work towards making it work. Try to learn, try to improve. That is where you get the speed, and quality. The process and technology are supporting roles to the people.The process is there to help the people communicate. The technology is just a tool to help embed quality and speed up development.

When the people stop “doing agile” and start “being agile”, the cargo cult phase morphs into the being phase. It just clicks.

At least  that is how I see it. I’m still waiting for things to click. If it has clicked for you, I’d like to know your story.

Toyota Tour

Late last week, I had the opportunity to visit the Toyota factory at Altona in Melbourne. If you have the opportunity to visit the plant before it closes in late 2017, I highly recommend you do. It’s around about a 6 month wait for groups (At least it was when I signed up in March this year, but you may get in if you are a small group. You never know, there may be a late cancellation. The tour is free, and you get to see the Toyota Production System first hand. i.e., Genchi Genbutsu (Go and See). 

The tour guide took us first to the pressing plant where the sheet metal for the car bodies were being pressed. Those dies are huge and heavy. I remember reading in the Toyota Way where in other car companies previously, it would take hours to change over dies to different molds. On the tour, we were told that it would take minutes. A few for the lighter dies, and up to 12 for the heavier. Everything was controlled by one crane operator who controlled everything from the ground. So he know where to place everything. There was still a cabin for the crane where the operator previously sat, and they would have someone below guiding, but by having the operator on the ground, it made things more efficient, and that was the whole point. Efficiency as simply as possible. We saw simple solutions to get efficient. For example, when bonnets are pressed and stacked. To prevent them from banging into each other and causing dents in the metal, tennis balls on string were used to separate the bonnets. A simple solution, but it did the job. There was also complex solutions. They had autonomous rovers that would carry parts to and from assembly areas. These rovers would follow a magnetic strip along the ground. They would stop if anyone got within 50-100cm from the rover. And they would run every where at a slow walking pace.

I could see first hand the limiting of parts of each station. There would be a bin for each station for the required parts that the operator would take from. A second bin would be present for when the first one was used up. And possibly a third. When the bin was empty, an electronic Kanban system was triggered to fetch another load if required. Speaking of Kanban’s, these were gathered every 38 minutes. An announcement was made at one facility for them to be gathered by Supervisors.

There was only one area where there was inventory. That was for parts that came directly from Japan. We were told that the only reason they had inventory was in case of Typhoons and other delays. Otherwise everything comes as required.

For every car that comes off the line in one end, the materials to make another car come in from the other. The whole system is a highly coreographed dance. 

Everything is made in the order it was ordered. For example, you have one red Camry, another white Aurion. A blue Camry hybrid etc. Each car is made in that order. They do not do batches. For example, 50 Camry’s white, 50 Camry’s blue etc. We didn’t get to see inside the paint facilities, but they showed us a video from Megafactories of the painting. Each car is painted individually. You may have one white car, and then next to it, only 50 to 100cm away, a blue car. The painting is so accurate, that there is no splatter. To reduce splatter, the car is charged negative and the paint is charged positive so that they are attracted to one another. Exhaust fans drive excess paint down through the floor – what little waste there is. Everything is paced based on “takt” Time, which is the frequency it takes to produce vehicles. The takt time is based on orders. For example, a slow day may produce 80 vehicles per shift, a fast paced one would be 200 vehicles per shift. Everything is based on the number of orders. Painting is also where the most time taken to manufacture a vehicle takes place. It takes 12-15 hours for the paint to dry and 24 hours total for a car to be manufactured.

If it did happen where a major part was for the wrong vehicle, for example the seats, then the right seats would be taken from the limited stock on site. By the time the vehicle for that stock was taken is about to be put together, a replacement would have been on site. It takes around about 16 minutes for local suppliers to get replacement parts where required.

As I mentioned previously, the Toyota Factory is closing late next year. It’s going to be a hard time for the workers there, but from what I saw, the management does not take this lightly. There is a training center where employees get skilled up to help them find a job later. Management has a “Food for Thought” drive, where senior management will have a meal together with every employee who wants one.  This in my opinion shows respect for their employees. I have never seen something like this happen in my entire working life. 

While I was on the tour, I did ask one question. I’m curious about Kaizen. I’m the sort of person who comes up with a lot of ideas, and usually comes up with some sort of prototype to test the theory. Anyway, my question was “How often is the Kaizen workshops done? Is it monthly or as required?” I was told that it is as required. When an employee comes up with an idea, it is evaluated straight away. No idea is too stupid. 

I like this sort of thinking in companies. It uses their people as a resource for innovation. I saw something similar when I visited the Telstra innovation hub late last year. Telstra has a system where employees could submit ideas online, they would be evaluated by their peers through a Monopoly money type System where each employee has $100 and can invest that money however they see fit in other people’s ideas to fund them. 

If you want to learn more about the Toyota Production System and Lean manufacturing, or Lean in general, I highly recommend the following books.

The Toyota Way – Jeffrey Liker
Lean Thinking – Womack and Jones

Thoughts on Focusing On Cost

A company that predominantly focuses on cost is a company that is going out of business.


There is a lowest level you can go with cost. If you cut costs too low, you limit your ability to make more revenue. You go down a deadly spiral till you are out of business.

The opposite is true, a company that focuses on revenue has no limits.


There is no known ceiling to how much revenue you can make.

In the theory of constraints, the focus is on increasing throughput, in lean it is flow.

Both methods look at getting the product out to the customer with quality sooner. This can result in more sales, better market response time and thus more revenue.

Flow or throughput is made faster by making the system more efficient. By increasing efficiency, you reduce waste, be it materials or effort. This results in reduce cost.

This means that reduced cost is a byproduct of the theory of constraints and lean. The first goal is getting a quality product out to the customer as efficiently as possible.

Speed of delivery is also a byproduct of lean and theory of constraints thinking.

By increasing efficiency, you reduce the manufacturing time, and therefore increase the tie of delivery.

Lean Terms

Agile, or at least Scrum is based on the manufacturing practices of Japanese car companies from the 1980’s. At the time, Japanese car companies were building cars with better quality, faster and cheaper than their American counterparts. The most successful of these Japanese companies was Toyota with their Toyota Production System. From this, evolved the Lean process.

Myself and my team are about to go visit the Toyota plant in Altona Victoria later this month. So I thought it would be a good idea to get myself reaquainted with Lean terms that I read in “The Toyota Way” by Jeffrey Liker.

I’m going to try to relate these terms to the CAMS (Culture, Automation, Measurement/Monitoring, Sharing) principles developed by John Willis and Damon Edwards that was developed during their DevOps Cafe podcast and give my explanation of what I think the terms mean in terms of software development.


Poka Yoke : Mistake Proofing (culture, automation) – In my thoughts, this is trying to prevent Defects in the software development process. One possible method of mistake proofing is through Test Driven Development where you build your tests before you start your development. It can also mean automation. There are a number of tasks that we that are manual, repetitive, and or simply done so infrequently that it’s hard to remember all the steps. By removing the component that can cause mistakes in tasks of this nature (The human) you can prevent mistakes from happening.

Hansei : Self Reflection (culture) – This I think is the retrospective in Scrum, but in a more personal level. It is simply to think over what you have done whether it’s in the past hour or the past sprint and try to think of a better way to improve.

Andon : Sign or signal to highlight action required (measurement, monitoring) – This is simply a signal to tell when a developer is in trouble or when the system is in trouble. In software development, it can take the form of an alert, an email, even a red light.

Jidoka : automation (automation – obviously) – To put simply, all types of automation. Automation of the build process, automation of the development process. Automation of tasks you do every day. For example a daily health check email. Anything that you can automate that will improve the system.

Just in Time (culture) : This is simply to have resources, requirements come just as they are required. Contrary to popular thinking about Agile that you do not need planning, to get Just in Time to work, you need to plan. If for example, to make a change to the firewall to get some ports opened up, and there is a 2 day lead time, you need to make that request 2 days before you need the ports opened up. Not when you need the ports, nor significantly in advance as requirements may change.

Henjunka : production smoothing or leveling (culture) – This is leveling the workload. How many of you have been on a project where at the beginning there is a lot of slack time. Nothing to do. Then at the end there is a mad rush to get the project completed in time. By doing the work in small chunks (sprints) you should have a constant flow of work.

Kaizen : Continuous improvement (culture) – This is where you try to continuously improve the system. Try something, try it at a scale that will not cause significant impact, see if it improves the situation. If it does, decide whether to adopt the changed process or not. If there is no improvement, determine whether or not to modify the trial procedure or drop the change completely. Don’t be afraid of failure, as each failure should be treated as a learning experience. Kaizen is one of the methods where PDCA (Plan Do check Act) learning cycle is used to try improvements.

Genchi Genbutsu : go and see for yourself (culture) – I see it a lot, I’ve done it myself a lot of times. I would come up with a theory on how something works. Or why it’s not working. The best way to determine how something works is to actually run it. Try it.Be it an API, a new technology etc. With the advent of Open Source and trial software, it’s easy to try products out yourself and see if they work for you.

Nemawashi : laying the groundwork or foundation for consensus (culture) – This I think is when the Team decides. It can be in the form of team meetings where you discuss the use of a new process, plan the work to be done. Just get everyone together and discuss.

kanban : signboard (culture) – This is where the Kanban board got its name from. With the Kanban board, you have a card which represents a piece of work. As it flows through the board, you see it’s progress. This gives a good visual queue to anyone who may be passing by as to the progress of any single piece of work.

gemba : the place where the actual work is done (culture) – This is a little tricky in Software development. In manufacturing, it’s simply the factory floor. In software development, it’s done at people’s desks. On the computer and in their heads.  For managers though, if you want to know what is happening with your people, go out and talk to them. Don’t just rely on reports, the wall, burn down charts etc.

zero quality control (culture, automation, measurement, monitoring) – This I think is part of the “Shift Left” movement where quality is being pushed towards the developer. The idea being that you build in quality as part of the process. Not as a process you do at the end of the development cycle as is done with traditional testing. Zero Quality Control is an asymptotic goal. A goal that is to be strived for but may never be reached. By continuously improving and trying to remove the cause of defects (not the actual defects themselves) you work towards the goal of never having any defects.

kaikaku : radical improvement (culture) – This is where significant change happens. It can mean moving from Waterfall to Agile, Agile to DevOps. Changing company direction. Anything that has a significant, radical change to they way work is done. This is opposed to Kaizen which is incremental change.


This is only a quick overview and my own explanations of what I think these terms mean to me. I may at some point in the future go through these in more depth.  I really need to re-read the Toyota Way. This time around, take notes as it sticks in my head better.