Introduction
Much has been said and written about Toyota and how its practices have influenced and sometimes revolutionized the working environment of companies from different sectors worldwide.
Toyota has been the cornerstone on which Lean principles were grounded and these in time have greatly influenced Agile and the Scrum framework.
We often times forget to go back to Scrum roots in order to understand why we do things. Scrum has become popular but many people continue to ignore the pillars on which it is based and this can brings negative consequences.
The Machine that Changed the World
Cars have had a great influence on the transformation of societies and their way of producing has been definitive when it comes to modernizing manufacturing.
In fact, no other machine in the modern era has had such a big influence on the way workers, materials, capital, knowledge and equipment have been organized [Womack07].
A more efficient form of organization −following Lean principles and avoiding various forms of waste− leads to greater productivity, better aligned with the market and impacts positively the well-being of the teams: hence the recommendation that Scrum Masters know and try to apply Lean manufacturing principles.
The Essence of the Toyota Way
Taiichi Ohno [Ohno13] greatly summarized a fundamental principle: the misperception that comes from being too far away from the gemba. To clarify errors of perception Ohno suggests a simple “Go and see” practice.
Unfortunately, this principle is not frequently seen in Scrum Teams that intended to supervise or evaluate the work by just reading reports and seeing visual indicators.
A second fundamental principle is “stop and fix” which literally meant for Toyota to stop the production line as soon as a quality problem was detected, apply the “five whys” technique to find the root cause of the problem, mitigate (not find the perfect solution) and then resume the production line.
The “stop and fix” principle also had a second purpose: to force continuous learning. In general, adults, or at least a great number of us, do not want to continue learning and therefore a practice like this forced Toyota developers to stop working, reflect on what was not working well, propose possible mitigations and experiment with them.
Contrary to the “stop and fix” principle many Scrum Teams out there frequently tend to pile up defects and even create a backlog for them where they got recorded but ultimately forgotten; this practice not only contradicts a Toyota principle but also doesn’t improve engineering practices nor contributes to expand developers’ knowledge. Doing more work that is lacking quality or doing it in a more predictive way won’t positively impact the product that will keep accumulating technical debt.
The list of Toyota Principles includes many [Liker04] but here only one more will be mentioned: “kaizen at infinitum”. This principle is about people continuously learning and expanding their knowledge, that eventually greatly pays off in the form of higher quality products [Senge90].
Very frequently I encountered Scrum Masters that are after learning the “Scrum best practices” which in reality doesn’t exit, and if they do those are tightly connected to a particular context and for that reason can not be directly extrapolated. Instead of embarking on that imposible quest, the Scrum Master should turn her/his attention to uncover how to build an environment of constant learning in which people can experiment with different practices. Paraphrasing Senge [Senge90] the differentiator of an organization (and its teams) is the wealth of acquired knowledge and the willingness to keep learning.
Lean, Respect and Waste
The Lean approach for manufacturing could be simplistically expressed using the following formula [Ballé14]:
LEAN = RESPECT + KAIZEN
Where RESPECT refers to respect for the workers and their creativity, and the upper management commitment to provide all the necessary conditions for workers to develop their maximum potential.
From a traditional Lean perspective the central theme is to maximize activities that contribute value and minimize activities that generates waste. Wasteful work then can be classified into to broad categories: urgent waste that has to be reduced inmidiatlye and identified waste for which there is no mitigation that can be applied immediately.
Waste can take many forms, some of the most common are:
- Overburden and stressed workers
- Bottlenecks
- Waiting in queues
- Handoff
- Wishful thinking
- Dissemination of information
And many others that are particular to individual teams and context.
Consequently, part of the job of the Scrum Master is to positively contribute to create a culture in the team that values respect, really embraces and uses it as a pillar to work collaboratively to identify forms of waste and possible mitigations.
The opposite would be a culture of no-respect where forms of waste are not identified and even if so no one in the team does anything about it; no-respect can also lead to demotivation and won’t help the team to improve its own practices.
Agile: Decades After and There is Still Confusion
It is very common these days to hear the very popular term “Agile” as a prefix of many things like Agile Coach, Agile Adoption, Agile Inception and many others. However there is a sustancial problem that remains unsolved: people and organizations are trying to copy and use something that they haven’t completely understood yet.
Because of this one of the big challenges for the Scrum Master is to educate others so there is an overall better understanding of what Agile really is. One valuable tool that can help with this is the Agile Manifesto but this could not be sufficient due to its concise and lightweight nature.
Another tool is to educate using terminology and concepts that are frequently used in the Agile space and connected to software development.
Notwithstanding, I’ve found in practice that people and organizations tend to better assimilate Agile when it’s presented from a historical perspective that describes its evolution starting from its roots in Toyota, the connection with software and the key influence of eXtreme Programming.
Furthermore, it’s very valuable to highlight the connection between Toyota and the current practices of DevOps [Forsgren18].
Whichever path you choose to explain Agile I think is important to recognize that Agile has a lot to do with things like:
MINDSET <-> CULTURE (PRINCIPLES + PRACTICES)
Equally important to mention is that Agile keeps evolving as more and more agilist gain experience and take Agile to other domains, there are for instance two examples of agile evolution: Modern Agile and The Heart of Agile. I’m expecting that this evolution continues as Agile itself is an evolving concept.
And That is How We Arrived to Scrum
It is true that Scrum is an Agile lightweight framework that is team-centric and used by teams to collaboratively build products, but it’s also true that Scrum conceptual simplicity could led to be erroneously interpreted as a simple prescription of a set of meetings and the use of post-its on a taskboard.
Scrum needs then be understood from a more educated historical perspective and also in connection with other disciplines that complements it, more simplify put:
SCRUM = LINEAGE + INTERSECTIONS
If we talk about lineage it’s vital to understand that Scrum is not a revolutionary framework; instead it comes from the influence of the Toyota Production System that originated Lean Manufacturing and both influenced in time Agile and Scrum.
And if we talk about intersections Scrum intersects with a long list of disciplines such us:
- Queueing Theory
- Systems Theory
- Industrial Empirical Process Control
- eXTreme Programming
- Caos Theory
- Soft Skills
- Team Building
- Facilitation
- Coaching
The Scrum pragmatic goal is to create a continuous learning environment where is safe to experiment and fail. This type of environment fosters continuous improvement and benefits the Scrum Team, the Product Owner, the organization and the advancement of software development practices.
A corollary of this is that the Scrum Master should focus in four areas: the Development Team, the Product Owner, the Organization and the software development practices [Larman17].
Conclusions
It’s been openly said that Scrum can and should be adapted and combine with other tools and approaches but that needs to occur respecting the Agile principles and also taking into account the connection with Lean and the Toyota Production System.
Making adaptations disconnected from the Agile principles frequently have lead to suboptimal results and/or failed Scrum adoptions. What is even worst, Scrum has been mistakenly seen as a new and improved tool for better control developers that now need to work harder to meet imposed deadlines.
The Scrum Master rol is fundamental to clarify this misunderstandings so Scrum can be all adopted and really benefits people as the Scrum creators really envisioned.
Bibliography
Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition
Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw-Hill
Liker04 Liker J., 2004. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, McGraw-Hill
Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday
Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute
Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press
Larman17 Larman C., Vodde B., 2011. Large-Scale Scrum More with LeSS, Addison-Wesley
