Eliminieren von „Waste”

Foto von Sohrab Salimi
Sohrab Salimi
•
3 Min. Lesezeit

Eines der Lean-Prinzipien ist es, „Waste” (dt.: Verschwendung) zu eliminieren. Dieses Konzept wurde in den späten 1940er Jahren in der Fertigungsbranche von Toyota geprägt. Damals war es sehr aufwendig, Fahrzeuge herzustellen, und die Unternehmen mussten von den Kunden sehr hohe Preise verlangen. Die einzige Möglichkeit für Toyota, die Preise für die Autos zu senken, bestand darin, die Herstellungskosten zu reduzieren.

Was bedeutet „Waste” bei Lean?

„Waste” bzw. „Verschwendung” ist im Grunde genommen das Gegenteil von „Value”, also „Wert” (eine Fähigkeit, die dem Kunden geliefert wird und durch die er einen direkten oder indirekten Vorteil erhält). Beispielsweise ist ein Teammeeting ohne einen konkreten Anlass reine Zeitverschwendung.

Hier sind die sieben Arten der Verschwendung, die im Toyota Produktionssystem (TPS) von Shigeo Shingo identifiziert wurden:

  1. Bestände: unfertige Erzeugnisse (WIP: work in progress)

  2. Überproduktion: mehr zu produzieren, als die Nachfrage erfordert

  3. Verarbeitung: zusätzliche Arbeitsschritte im Prozess, die nicht nötig sind

  4. Transport: Güter von einem Ort zu einem anderen zu transportieren

  5. Wartezeiten: Lücken zwischen den einzelnen Verarbeitungsschritten

  6. Bewegungsabläufe: unnötige Bewegungsabläufe im Prozess

  7. Fehler: Fehler bei den Produkten, die deren Eigenschaften und Funktionen beeinträchtigen

Was sind die Arten der Verschwendung in der Softwareentwicklung?

Anhand der sieben Arten von Verschwendung in der Fertigungsindustrie haben Mary und Tom Poppendiek die sieben Arten der Verschwendung bei der Softwareentwicklung definiert:

  1. Unfertige Arbeiten: In jedem Sprint sind die Teammitglieder für eine festgelegte Anzahl von User Stories verantwortlich. Manchmal schaffen sie es jedoch nicht, alle Stories fertigzustellen. Dann müssen sie herausfinden, warum sie nicht dazu in der Lage waren, damit sie diese Art von Verschwendung reduzieren können.

  2. Zusätzliche Features: Ganz zu Anfang hat der Product Owner eine Vision geschaffen und dann einen Product Backlog mit priorisierten Features erstellt, die einen Wert für das Produkt schaffen. Das Pareto-Prinzip besagt jedoch, dass es oft nicht notwendig ist, alle Features zu entwickeln, weil viele davon nutzlos sind.

  3. Dazulernen: In jedem Sprint sammelt man mehr und mehr Wissen, das man nutzen kann, um nicht ständig das Rad neu zu erfinden.

  4. Übergabe: Hier wir die Arbeit an eine andere Person weitergegeben, sobald die erste Person damit fertig ist. Wie kann man dem entgegenwirken? Am besten beseitigt man die Abhängigkeiten zwischen den User Stories (und Features) oder man gibt alle User Stories mit Abhängigkeiten an ein Team, um das Risiko zu mildern.

  5. Verzögerungen: Das ist alles, was das Ausliefern oder den Start einer wertsteigernden Aktivität verzögert. Wie kann man das verhindern? Man muss die Engpässe beseitigen und jeden langsamen Prozess umgestalten, um beide in Einklang zu bringen.

  6. Aufgaben wechseln: Das kommt vor, wenn der Product Owner seine Prioritäten ändert und die Teammitglieder von einer User Story zu einer anderen wechseln müssen, ohne sie vorher abschließen zu können. Der Hauptgrund hierfür ist oft, dass der Product Owner keine klare Vorstellung von dem Produkt hat oder dass ein Konkurrent ein neues Produkt auf den Markt gebracht hat und man sein eigenes Produkt so schnell wie möglich daran anpassen und herausbringen möchte.

  7. Fehler: Dies ist eines der größten Probleme in der Softwareentwicklung. Nach einer bestimmten Zeit hat man einen enormen Berg an technischen Schulden erzeugt und von da an muss man viel Zeit und Mühe investieren, um ihn Sprint für Sprint langsam wieder abzubauen.

Abschließend kann ich sagen, dass zwar viele Leute glauben, dass Lean kein guter Ansatz für ein Team ist, das mit Agile arbeitet. Aber sie täuschen sich. Tatsächlich sollte jedes Unternehmen zuerst Lean anwenden und dann zu Agile übergehen!!!

Dieser Text stammt aus dem Blog von Mario Lucero und wurde von uns ins Deutsche übersetzt.

Product Owner Training

=> Besuche eins unserer live Trainings und werde zertifizierter Product Owner

Product Backlog Refinement

=> So läuft ein Backlog Refinement in Scrum Teams ab.

Wie läuft eine Sprint Review in agilen Teams ab?

=> Hier erfährst du, wie eine ideale Sprint Review ablaufen kann.