How Japanese Manufacturing Influenced Agile: A Brief Explanation on Scrum vs Kanban
When we talk about products, we think of them in two different ways, either as physical products that are manufactured or software products that are developed by software developers. Despite the manufacturing sector and software development sector having completely different structures and processes, the two have been nourishing each other for quite some time by inter-learning between the two and I want to talk about one such instance.
The Two Great Ideas: Agile and Lean
Agile software development came into prominence in late 1990s with the development of software using Rapid Application Development (1991), Scrum (1994) and Extreme Programming (1996). However, a group of prominent developers in 2001 set the agile methodology in stone by publishing Manifesto for Agile Software Development which you can currently see in Agile Manifesto. The philosophy centered around providing workable software to the clients in close iterations which improved collaboration between the developers and clients. Currently, the most used software development philosophy behind waterfall, Agile is spearheaded by Scrum, a methodology that focuses on “sprints”, which we will discuss later.
Lean manufacturing came into prominence in the late 20th century, based on the learnings from Just-in-Time, a Japanese philosophy that was pioneered by Japanese automotive giant Toyota.
This philosophy that highlighted around elimination of “muda” (waste) was pioneered by Toyota Production System, that gave a massive competitive advantage to Japanese manufacturers that surpassed US manufacturing through “kaizen” (continuous improvement). Toyota viewed waste as anything that did not provide customer value, so the manufacturing chain was centered around eliminating non-value adding activities. “Kanban” (signboard) was used to schedule the manufacturing processes in this system.
Agile Software Development
To understand agile, I will mention some of the features of it, that specifically differentiates it from traditional waterfall method.
Agile discourages heavy planning as planning is expected to be inaccurate anyway due to uncertainty of future events. It embraces changes requested by clients throughout the product development as opposed to only gathering requirements at the start. The methodology promotes more in-person communication without the use of email, messages, etc. that slows down work and also discourages documentation while encouraging more frequent demos to the clients.
Agile methodologies are favored in software development use cases where there is a higher tolerance for bugs and errors and areas where the software is not required to be Right-First-Time.
You can see the principles behind the Agile Manifesto here.
Scrum
Scrum is an agile methodology where the focus is put on sprints which spans predefined periods of time.
Scrum can be of 1 week, but can also be extended to a period of more than a month depending on the type of the software product.
At the start of the sprint, there is a planning meeting lead by the “Scrum Master” while the “Product Owner” picks the features need to be developed and plan it for the sprint. This picking is usually based on a predetermined criteria such as urgency or criticality and the Product Owner with the development team should estimate how much time it would need to be developed and tested. The process uses a Scrum Board for planning the sprint and each feature that is to be developed is handled using a ticket.
Every day a daily stand-up is held where the developers and the Scrum Master come together to discuss what needs to be done and what tickets are to be managed. At the end of the sprint, a “retrospective” is done where the work done is reviewed and the lessons are learned. This is the key point where the accuracy of the work estimation is reviewed and then improved to be used for the planning for the next sprint.
The key feature of the Scrum methodology is the release of the features at the end of the sprint. There is a clear focus on the sprint planning as the success of the sprint fully depends on how accurate the work estimation is at the start of the sprint. If there are tickets left at the end of the sprint, the efficiency is reevaluated at the retrospective to avoid over-committing for the next estimation.
Kanban
To understand Agile Kanban, you have to understand the original Just-in-Time manufacturing methodology. The Japanese emphasized on getting rid of Work-in-Progress, the in-progress inventory that built up the inventory levels in the supply chain. Since the money was tied up in this inventory, this removal reduced the costs as well as emphasize the faults hidden through these Work-in-Progress. If two workers were carrying out sequential work in the manufacturing process, first worker did not send a piece before the second worker requested it. This resulted in complete reliance on a demand-based manufacturing process resulting in low Work-in-Progress.
In an Agile Kanban environment, the above philosophy is adpoted, but with a twist.
The idea is to release as much as possible without waiting until the end of a sprint like in Scrum.
This focus on the releases eliminates the requirement to have a predetermined sprints, thus removing the organizational setup around the sprint, thus reducing unnecessary waste as Japanese did with their manufacturing. There are no sprint planning, no retrospective and the Agile Kanban continues until the backlog is empty without ever stopping.
An “Agile Coach” replaces the Scrum Master in the Kanban methodology while Product Owner does the ticket selection from the back log. So how do they replace the estimation that is done in Scrum? Ironically, they keep a Work-in-Progress level so there is no over-commitment. If the WIP level is kept at 3 tickets, a ticket is only pulled from the To-Do column only if there are less than 3 tickets in the In-Progress column.
Conclusion
So what is better?
No such thing. Scrum vs Kanban is a decision that should be taken by a company after considering the culture they want to have and the personalities in the development teams. For me, a person who came from a manufacturing background, Kanban feels homey despite it lacking the modern project-like feeling that a sprint in Scrum provides.
After all, who does not want to go for a happy hour after a successful sprint.
