The History of Lean Product and Scrum Organization
At iSeatz, we use an organizational system called Agile Scrum methodology to complete development projects. We are constantly striving for high efficiency and quality of work which are the hallmarks of this organizational structure. Below is a little about the history and mechanics behind agile scrum methodology.
Borrowing from Fluid Dynamics
In fluid dynamics, there is a phenomenon when you try to push fluid through a conductor and the fluid hits a bottleneck. When you shove a high volume into the container and it’s going through a bottleneck, even less fluid volume comes out through the choke point due to churn in the system.
(Image source: https://www.fortelabs.co/)
This is because pushing more content through a bottleneck actually makes it worse. This is a non-intuitive thought process that happens in many different types of systems. Many manager’s initial reactions would be to load more in the front end of the funnel to ensure that at least some content comes out of the bottleneck. But what actually is happening is that the entire system is becoming less productive.
(image source: https://www.fortelabs.co/)
To solve this process, the actual tactic to maximize the system productivity, is to actually put less work than the capacity of the bottleneck can handle at any one time. This reduces the pressure of the bottleneck, allowing more output to come through.
House of Toyota
In the 1960s, Innovators at Toyota were looking at optimizing the manufacturing system. Toyota looked at the manufacturing line through the eyes of fluid dynamics methodology. As they watched parts come in, and work their way through the stations in the factory, they realized that parts stacked up at certain stations and this backlog was causing inefficiency upstream.
Toyota began to create a specific tactical and cultural framework to the manufacturing process to increase efficiency. The pillars of their methodology is below:
(image source: www.Lean.org)
Heijunka or “Just-in-time”: To reduce bottlenecks, aim to get parts or to the station as they are in need of them. Toyota worked with upstream vendors to first, create a line of communication between the different factories, and second created a “pull” system where the installation center would order parts as they were needed, instead of previously receiving parts as they were built.
Jidoka or “Quality Automation”: A focus on efficient practices and high quality are key. Toyota empowered everyone on the line to manage quality. Anyone who saw a level of quality that was not up to standards was empowered to shut down the entire system temporarily. This allowed the team to come together and address the problem at hand, instead of forcing workers downstream to overcompensate, adjust or work around the problem they inherited. A small problem can amplify quickly into a costly issue. This allowed the problem to be fixed early on, instead of having the problem compound.
Additionally, Toyota went above and beyond when it came to utilizing automation. They analyzed processes and assigned standardized, repetitive work to machines and computers to better utilize human capital and creativity for tasks that benefited from a human touch.
Kaizen or “Continuous Improvement”: As the system was showing results, the idea of “Kaizen” or continuous improvements was implemented. Culturally, Toyota strived to continue to refine this process and make it better.
This process allowed Toyota to be a leading car manufacturer in the 1960s and 1970s. Their quality was almost unmatched by the competition and their prices were lower also.
Applying Agile Scrum Methodology to Software Development
The ideas from Toyota’s manufacturing facilities were so efficient, other industries began to see if some of these ideas could be implemented in their field.
Software developers want high quality software with as efficient cost as possible. They began to create a framework that emulated Toyota’s process. Completed software replaced cars, tasks replaced parts, and developers replaced manufactures. Once this idea was realized, much of the ideology was able to transfer.
(image source: www.vertex42.com/)
The Scrum methodology initiative breaks down a major project into small tasks. After tasks are defined, group of workers agree on which tasks to complete in a given timeframe (usually 1-4 weeks) and then the piece of the project is completed, tested and new tasks are agreed upon. As this cycle continues, efficiencies are found and the process is optimized, ensuring the highest quality of work completed in the most efficient way.
Agile software development focuses on keeping code simple, testing often and delivering functional bits of the application as soon as they’re ready. The Agile Manifesto was created as an alternative to document-driven, heavyweight software development processes.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
How iSeatz Uses Scrum Methodology
Want to learn more about how iSeatz organizes our teams to work on projects? Read our blog “How We Work: Basics of Scrum Methodology.”