“Costs do not exist to be calculated, costs exist to be reduced.”Taiichi Ohno

3M is not only a famous Post-it® company. It’s also an acronym for the three major causes of what generates costs and delays in any process (manufacturing or not): Muda, Mura, and Muri.

As industries around the world become more aware of Lean principles, these concepts start to be understood and continuous improvement policies tackle them in a more or less effective way in many organizations.

On the software development side, while more and more methods combining Agile and Lean principles appear, few of them address the 3 Ms as efficiently as a properly implanted Scrum framework. In this post, I’ll present you each of the Ms and attempt to outline how Agile practices help in tackling them.

“The most dangerous kind of waste is the waste that we don’t recognize.”Shigeo Shingo

Muda is the most widely known M; it’s simply the waste.

Usually defined as any activity or process that does not produce value for the client, Muda is a pure and simple loss of time, money, and resources. It’s to be removed without hesitation.

Most waste falls into seven categories (T. Ohno, Toyota Production System, 1988):

  1. Overproduction: It occurs when more is produced than required by the clients.
  2. Inventory: It’s the raw materials, work in progress, or finished goods not producing income.
  3. Transportation: It’s moving the product, parts, documents, etc., without adding value.
  4. Over-processing: It occurs each time more work is being done than necessary to produce.
  5. Motion: It’s the damage incurred to people and materials during the production process.
  6. Defects: It’s the reworking time or loss if delivered to the client.
  7. Waiting: It’s the time during which the goods are not being actively produced or transformed.

Moreover, an eighth category is often added, which can be summarized as the loss of human potential to create something valuable while producing waste.

Now, let’s see how this is addressed by Agile practices.

As the members of a Scrum team are usually collocated (physically or virtually), less transportation is needed.

Inventory is reduced in all places as the team selects only a limited subset of the product backlog for a time-boxed iteration, limits the work in progress, and, by the end of the iteration, only delivers the selected product backlog items.

Motion is trickier as, happily, in software development there is small risk of incurring physical injury from the process. However, two of the Agile Manifesto principles promote the need to build projects around motivated individuals and the maintenance of a sustainable pace. That usually lessens the psychological wear and tear that individuals may experience when disengaged, stressed, and/or overworked. This is also the key behind unleashing the human potential to create something awesome, thus reducing the unofficial eighth type of waste.

While it may still happen, waiting is reduced to a minimum thanks to the Daily Scrum (or Stand-Up in XP) meetings. Also, as one of the essential characteristics of a team is to be cross-functional and autonomous, waiting caused by external dependencies should ideally never occur.

Simplicity, or the art of maximizing the work not done as stated in the Agile Manifesto, lessens the risk of over-processing. When the work is split into manageable pieces, the team is focused on achieving what is strictly required for each backlog item. By focusing on creating only what’s the most valuable from the client standpoint, Agile methods help to reduce the overproduction waste, which usually materializes when large batches are produced ahead of time.

Finally, working software is what all Agile practices are about; that is, without defects. The definition of “Done” in Scrum and some engineering practices, such as Test-Driven Development, are examples of how the risk of defects can be reduced to a minimum.

“The slower but consistent tortoise causes less waste and is more desirable than the speedy hare that races ahead to stop occasionally to doze. The Toyota Production System (TPS) can be realized only when all the workers are tortoises.”Taiichi Ohno

Mura, or the unevenness or inconsistency, is what creates many of the forms of waste mentioned above. The inability to set and maintain a consistent pace creates variations in the process.

A classic example, purely fictional but somehow familiar to anyone with some experience in the IT field, is the lengthy implementation of some given system.

As it starts, work is usually slow. The team gets started and waits for approvals. Plans are put into Gantt charts. Meetings to get everyone on the same page drain precious time and long documents are written to set in stone everything that might possibly be needed.

As time progresses, pressure related to the delivery date and the scope begins to rise, and teams start working at a higher pace. Meetings are required to follow up on the progress of work and coordinate teams. Gantt charts are updated. Documents are written to pass work from one team to another within a project. Architectures are set in stone and, finally, we can start to code.

Despite incredible efforts and high priority, the date gets dangerously close and the team works nights and week-ends to get all the pieces together for the required date. When the system is finally in production, the second nightmare starts as soon as defects are discovered. Thus, remaining players work overtime to hastily fix what can be fixed and figure out workarounds for what can’t be fixed.

I could go on with this example for much longer, but I think you get the point… The unevenness of this waterfall example results in plenty of the wastes we have discussed above. It is disastrous to the organization on all levels: money gets sunk to deliver on time, the project team becomes exhausted, the client is dissatisfied, and there is no real sense of achievement as defects are being discovered after delivery.

Focusing on early and iterative delivery of working software, Agile methods and practices aim to set a sustainable pace for all the players involved: both the development team and the client. Time-boxing the work helps the empirical process by setting a constant inspection and adaptation loop. It greatly helps the team to know its pace based on past iterations. Velocity is often used to define this pace.

Also, frequent inspection of the process of producing working software increments (iteration retrospective) ensures that impediments are removed and that the process becomes smoother as members of the team learn how to work better together. As we have seen before, with a professional use of Agile practices, most of the waste can be avoided or, at least, reduced.

“We are doomed to failure without a daily deconstruction of our various preconceptions.”Taiichi Ohno

Muri, or the overburden, is what usually results of Mura, but it also happens due to numerous organizational issues. It’s the unnecessary stress induced to employees and processes within the organization. Over time, a failure to tackle Muri adequately will produce new Mura and Muda, even though the organization might have successfully reduced them before.

People and processes suffer overburden when impediments are structural and procedural (sometimes even institutionalized by internal policies). Poorly laid out and cluttered work places, unclear instructions, lack of training, wrong tools, lack of maintenance, poor communication patterns are all major causes of overburden to employees and processes. And as you read the list, I’m pretty certain you had illustrations based on your own experience for any one of them.

When it comes to Agile practices, these structural and organizational deficiencies apply to a much lesser extent. For instance, Scrum is a lightweight framework that is very easy to understand. So, there is simply less stress due to the lack of training.

Instructions are pretty clear and every event, artefact, and role has its precise purpose, scope, and responsibilities. A dedicated team member ensures that the framework serves its purpose; thus, removing this burden off the back of the other team members.

As stated in the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” All Agile practices aim at lessening as much as possible the overburden of poor communication channels by promoting direct collaboration.

Finally, as for the organization of the workplace and the selection of appropriate tools, self-organizing teams are the key to reduce the burden at this level. They know best how to organize their work in order to optimize it.

“If you are going to do TPS, you must do it all the way. You also need to change the way you think. You need to change how you look at things.”Taiichi Ohno

All is said in the above quote. Getting rid of all 3 Ms at a team level is like cleaning up a drawer in the basement of your house… As perfect as the resulting drawer may be, it still has almost no impact if the basement is overrun with waste and disorder.

A true transformation occurs when the organization and all its parts learn how to think differently. What is often easily achievable on a team level with Agile practices and Lean thinking requires much more effort and commitment when it comes to the organization as a whole.

Such a transformation is not always fun as Agile and Lean practices thrive on visibility and transparency, quickly putting waste and impediments in broad daylight. A wholehearted commitment to a better way of working is required of everyone involved as, according to Taiichi Ohno, “a half-hearted introduction brings a hundred harms and not a single gain”.

Most successful transformations occur when organizations have no other choice if they want to remain competitive in an increasingly aggressive economic environment. As Ken Schwaber stated it: “For Scrum to succeed, the pain of doing Scrum must be less than the pain of not doing it.”

Previous post

Get the most out of your Scrum grinder!

Next post

Unravelling team spirit


Diplômé en 2004 et certifié Professional Scrum Master, Pawel a joué divers rôles depuis le début de sa carrière – programmeur, analyste, chargé de projet, coordonnateur, responsable de produit et, plus récemment, architecte d’affaires – dans des contextes de réalisation de projet tant traditionnels qu’Agiles. Depuis 2011, il met en application les méthodes Agiles dans des équipes de projets informatiques et aussi dans celles responsables des activités commerciales.

Convaincu de la force des principes Lean et de la philosophie Agile, Pawel s'est joint à Pyxis en 20015 pour continuer à aider les personnes et les organisations à découvrir une façon de travailler valorisante, responsabilisante et efficace et qui demeure centrée sur la valeur pour le client.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *