In this blog, I will highlight the concepts of waste and continuos improvement to frame the agile stream approach.
Lean is embodied in the agile stream thinking with its quest to continuously improve the ecosystem surrounding agile streams.
Lean thinking differ in the subtle ways from Lean manufacturing, where the goal of lean thinking is to “understand how to seek dynamic gains rather than static efficiencies” compared to lean manufacturing where it is “a form of operational excellence aimed at taking costs out of processes.”
Lean manufacturing or lean production, often called "lean," is a systematic method to reduce Waste as an effective way to increase profitability. Lean targets (1) designing out inconsistencies Mura (2) relieving stress and overburdened in process Muri (3) and the elimination of waste Muda within a manufacturing system.
Wikipedia defines Mura (/mu-ra/, Kanji: 無斑) as “unevenness; irregularity; lack of uniformity; non-uniformity; inequality,” and can be addressed with Just-In-Time (JIT) systems and planning to supply working software at a sustainable pace. These systems supply the production process with the right part, at the right time, in the right amount, using first-in/first-out (FIFO) component flow. JIT systems create a “pull system” in which each sub-process withdraws its needs from the preceding sub-processes, and ultimately from an outside supplier. When a preceding process does not receive a request or withdrawal, it does not make more parts. This type of system is designed to maximize productivity by minimizing storage overhead.
We identified Mura in our business requests process. Requests were all over the place and with competing interests. Teams did not have a uniform approach to solving problems, so business managers had to spend time researching which team can do accomplish what they needed, which created unevenness in the workload levels. We addressed Mura with Scrum’s Product Owner prioritizing and setting direction for teams, training and empowering teams to be effective Scrum teams; teams breaking down stories and sizing their efforts in Story Points; used XP practices to improve quality.
Wikipedia defines Muri (/mu-ri/, Kanji 無理) as "unreasonableness; impossible; beyond one's power; too difficult; by force; perforce; forcibly; compulsorily; excessiveness; immoderation" and can be addressed through standardized work. Muri can be interpreted as all unreasonable work imposed by management on workers and machines resulting from poor organization, and pushing a person, or a machine beyond its natural limits, without modifying acceptance criteria, introducing higher risks to themselves and the company, and it is almost related to working at an unsustainable pace.
We identified Muri in our software delivery process. Managers over promised deliveries and expected teams to work around the clock to deliver on time. Defects added to the problem and took us down a thorny road by asking people to stay late and come on weekends to fix bugs. These practices were unsustainable, bad for morale and business. Muri drove much of bad behavior at every level of the organization in an attempt to compensate for the pressure and overburden. We addressed Muri with clear policies to disable the practices and empowered teams to use Scrum, XP practices and Agile Stream Framework to solve the problems.
Wikipedia defines Muda (/mu-da/, Kanji:無駄) as "futility; uselessness; idleness; superfluity; waste; wastage; wastefulness.”Muda is characterized by processes that consume more resources than what is needed to create business value, and it is addressed by identifying and removing such waste.
Figure 1: Seven wastes (Muda) in Toyota Production System.
There are seven common wastes outlined in Toyota Production System by Shigeo Shingo which are:
Inventory waste— It is observed as excess inventory in raw materials, unfinished work, or work in progress activities. It represents a capital outlay that has not yet produced an income.
In agile software development, inventory waste is found in stories that are not complete as defined by the Definition of Done (DoD), code that is not refactored, tested, documented, or localized, preventing the work from being demoed, deployed or delivered to customer.
Overproduction waste— Occurs when we produce more product than required at that time by your customers. Overproduction would lead to excess inventory, which then requires the expenditure of resources on storage space and preservation, activities that do not benefit the customer.
In agile software development, overproduction waste is observed in extra features that are released to production and must await being used or consumed by the customer. This is a common type of waste, where the effort is focused on deploying software, without accounting for adoption time.
Extra processing— Occurs any time more work is done other than what is required by the customer. This includes using components, metrics, or solutions that are more precise, complex, or cost more than absolutely required.
In software this waste is often referred to Gold Plating where team members engage in building complex solutions, building something new where existing and cheaper alternatives exists, and building functionalities that does not add business value to the customer.
Transportation Waste— Whenever a product is moved it stands the risk of being damaged, lost, delayed, and adding cost without delivering additional value. Transportation does not make any transformation to the product that the consumer is willing to pay for.
In software this is experienced by moving of tasks between silos, injecting gatekeepers in the process, moving work between teams, etc.
Waiting is another form of waste of time. Teams waiting to information from customers or other teams. Whenever goods are not in transport or being processed, they are waiting. In traditional processes, a large part of an individual product's life is spent waiting to be worked on.
In agile software development, waiting occurs anytime teams anything that delays them from delivery value. Generally, this form of waste can be easily detected if you look for it.
Motion waste— refers to the damage that the production process inflicts on the entity that creates the product, either over time, or during discrete events.
In agile software development this form of waste occurs when teams switch context and tasks.
Defects— Flaws in the deliverables that impact functionality incurs extra costs reworking the part, rescheduling production, etc. Which increases production costs?
In software development defects costs increase exponentially when they are discovered at a future time in production and have the lowest impact on cost when corrected within the sprint.
Before moving on to the next topic from the Mura, Muri, and Muda, I wanted to share the importance of these concepts to the overall operational and financial healths of the software development life cycle. As a startup operating in a chaotic ecosystem and with limited resources, by focusing on building software using Scrum and continuously removing waste through Agile Stream Framework we could maintain a leading position in the markets we competed in, at third of the budget.
Many, if not all, of these concepts have roots in Toyota’s lean management practices, known as Toyota Production System (TPS). I will go ahead and talk about Toyota and how it ties further to this conversation.
In 2001, Toyota published the underlining philosophy, values and manufacturing ideals of the company in a document titled “The Toyota Way” which includes a set of principles and behaviors that clarify the values and business methods that all Toyota employees should embrace. Toyota way is supported by two main pillars: “Continuous Improvement,” and “Respect for People,” and these pillars are also central to agile stream thinking.
Figure 2: Depiction of pillars and their components in Toyota Way 2001.
Continuos Improvement
Continuos Improvement (CI), also known as Kaizen, describes an attitude in which team members are expected not to be satisfied with the status of things and continuously develop innovative ideas and solutions that yield higher value. This pillar is composed of:
Challenge— Continuously setting and achieving goals with courage and creativity. In the absence of a challenge, teams develop the solution at hand and fail to seek opportunities for improvement.
In agile stream thinking, challenges are quantifiable, presented as hypothesis and observed with agile metrics.
Kaizen (Continuos Improvement)— Constant, Consistent, and Continuos Kaizen (3Cs) philosophy by team.
In agile stream thinking, it is the quest to continuously experiment, learn and adapt.
Genchi Genbutsu— Go and see where it is first. It is a simple yet powerful component of CI that has a great impact on quality of work and organizational responsiveness.
At ayna we did not use that Japanese term, instead would used “Go See” (/rooh-shoof/, Arabic: روح شوف) to understand the problem at hand. I have found this practice to be extremely helpful in understanding issues that were difficult to identify through reporting chains.
Respect for People
Respect for People describes an attitude in which team members are expected to respect each other, employees, customers, stakeholder and society. This pillar is composed of:
Respect — Seek to respect others, make every effort to understand each other, take responsibility of our actions and do our best to build mutual trust.
It is supported by organizational policies and individual interactions with everyone on a daily basis.
Team Work — Seek to build an environment to enable team-work and professional growth, share the opportunities of development and maximize individual and team performance.