Schwachstellen auflösen mit der Theory of Constraints

Theory of Constraints – 5 Tipps für mehr Produktivität durch weniger Arbeit
Kommentare

Work in Progress limitieren, Waste eliminieren: So soll die agile Arbeit gleich viel schneller von der Hand gehen. Vor allem das agile Framework Kanban setzt auf diese Prinzipien. Das ist aber nicht der einzige Weg zu mehr Produktivität durch weniger Arbeit. Die Theory of Constraints (TOC) erklärt, warum weniger manchmal einfach mehr ist, um maximal produktiv zu sein.

Wer die Produktivität eines agilen Teams steigern möchte, kann verschiedene Ansätze wählen. „Waste“ ist ein Konzept, das Ursprünglich aus dem Autobau kommt und vor allem im agilen Framework Kanban und im Lean Management Anwendung findet. Jeder Arbeitsschritt wird dabei auf seinen Zweck hin überprüft: Generiert dieser Ablauf genug Wert, um ihn in den Workflow aufzunehmen? Kann der Schritt automatisiert werden? Alles steht auf dem Prüfstand. Wird etwas als Wasteful Activity identifiziert, beispielsweise ein Meeting, das keinen Zuwachs an Wissen oder Erkenntnissen beschert, wird es aus dem Arbeitsprozess gestrichen. So steigt die Produktivität.

Agile Kanban-Tricks für mehr Produktivität

Auch wenn es um die Menge der gleichzeitig bearbeiteten Aufgaben geht, ist Kanban strikt: Je stärker sich ein Team auf wenige Aufgaben fokussiert, desto besser. Insofern stellt das Mob Programming in gewisser Weise eine ideale Kanban-Arbeitsmethode dar – alle Teammitglieder arbeiten zugleich an einer einzigen Aufgabe, dadurch können gar nicht zu viele Aufgaben auf einmal angegangen werden, wodurch das Team ausgebremst werden könnte.

System-Flüsse betrachten mit der Theory of Constraints

Auch die Theory of Constraints kommt aus der Welt der physischen Produktion, wie Eric Gunnerson auf seinem Mircosoft-Blog schildert: Wie kann ein bestehendes System mehr produzieren? Das ist eine Kernfrage der Theory of Constraints, die genau so wie die Idee des Waste auch auf die Softwareentwicklung übertragbar ist.

Die Grundlage der TOC bildet der altbekannte Spruch, dass jede Kette nur so stark ist, wie ihr schwächstes Glied – das ist der Constraint. Weiter besagt die Theorie, dass jede Kette tatsächlich auch immer ein schwächstes Glied hat – egal, ob es sich um einen Arbeitsablauf im Autobau oder bei der Softwareentwicklung handelt. Um solche Bottlenecks aufzulösen, stellt die Theory of Constraints allerdings das gesamte System in den Fokus, nicht die Schwachstelle an sich.

1. Die echte Schwachstelle identifizieren

Dazu werden fünf Schritte durchlaufen, die dazu beitragen sollen, die Schwachstellen eines Systems zu erkennen und aufzulösen. Offensichtliche Antworten werden nicht akzeptiert: Weiß jeder, dass die andere Abteilung zu langsam ist, lautet die Lösung nicht ausschließlich, dass die Kollegen aber schneller werden müssen. Viel mehr wird zuerst intensiv nach der Schwachstelle gesucht.

Formulierungen wie „die sind zu langsam“ stellen nämlich eine Falle dar. Was ist denn „zu langsam“? In der agilen Arbeitsweise kann eine Abteilung langsam sein, wenn sie sich noch nicht in die agilen Methoden eingefunden hat; auch eine schlechte Synchronisation der Arbeitsabläufe mit anderen Abteilungen oder ein Manager, der agile Prozesse erschwert, können zu einer verlangsamten Arbeitsweise führen. Darum setzt die Theory of Constraints die Betrachtung des Gesamtsystems vor die Lösung. Funktioniert der Zufluss an Informationen aus anderen Abteilungen und durch den Kunden? Wie hoch könnte die Produktivität überhaupt sein, woran kann das gemessen werden? Ist die Produktivität der „langsamen“ Abteilung überhaupt das Problem – oder sind vielleicht die Kollegen zu schnell, verursachen dadurch aber mehr Bugs, die an anderer Stelle erneut Zeit kosten? Wird an den richtigen Aufgaben gearbeitet? Erst, wenn alle offenen Fragen beantwortet wurden, kann die Schwachstelle klar benannt werden.

2. Strategien zur Problemlösung entwickeln

In der Folge wird nach einem Weg gesucht, um die vorliegenden Schwächen gezielt abzubauen. Der Arbeitsablauf innerhalb der Abteilung wird auf vorgenannte Probleme wie Wasteful Activities und WiP-Konflikte hin betrachtet; ein agiler Coach könnte hinzugezogen werden, um die Arbeitsweise des Teams zu verbessern. Das Ziel: Die Produktivität steigern, aber ohne dadurch mehr Arbeit entstehen zu lassen.

Devs fight your battle! A pledge for cross-functional teams

mit Steffen Behn & Tina Dreimann (die kartenmacherei)

Bausteine erfolgreicher Retrospektiven in agilen Prozessen

mit Tobias Ranft (Beratung Judith Andresen)


Systembedingte Grenzen werden akzeptiert. Die TOC setzt hier noch nicht darauf, zusätzliche Arbeitskraft einzusetzen, sondern versucht die Schwächen mithilfe der vorhandenen Ressourcen abzubauen. Der Gedanke dahinter ist einfach: Wird einfach die theoretische Produktionskapazität erhöht, ist das Grundproblem nicht gelöst, sondern verschiebt sich. Kann eine Abteilung durch einen zusätzlichen Kollegen mehr Code produzieren, heißt das nicht, dass die parallel am Produkt arbeitenden Abteilungen mithalten können. Wer auf diese Weise versucht das Problem zu lösen, erhöht oft erst einmal nur die Kosten.

An dieser Stelle sollte auch bedacht werden, dass das Hinzufügen neuer Mitarbeiter keineswegs immer zu mehr Produktivität führt. Einerseits muss ein agiles Team gut eingespielt sein, um überhaupt gut zusammenarbeiten zu können, sodass neue Kollegen erst einmal viel durcheinander bringen – das kostet Zeit. Andererseits kann es aber auch aufwändig sein, neue Kollegen mit dem Produkt vertraut zu machen, ganz unabhängig davon, dass sie sich ins Team einfügen müssen. Code-Stile, vorhandene Funktionen und so weiter müssen jedem beteiligten Entwickler bekannt sein! So entstehen Verzögerungen, bevor ein neues Teammitglied aktiv zur Fertigstellung eines Produkts beitragen kann.

3. Umsetzen: Das System neu ordnen

Eine Lösungsstrategie muss immer das gesamte System berücksichtigen. Hilft es nicht, nur eine Abteilung zu optimieren, wird also dort angesetzt, wo es gerade am besten läuft. Hier sind oft Kapazitäten vorhanden, die dabei helfen können, bisherige Schwächen auszugleichen. Produziert eine Abteilung deutlich mehr Code als die anderen, könnte versucht werden, dieser zusätzliche Aufgaben zu geben, um ein langsameres Team (das vielleicht komplexere Probleme bearbeitet, also eigentlich nicht wirklich langsam ist) zu entlasten.

Dieser Schritt wirkt auf viele erst einmal paradox: Ein schnelles Team soll verlangsamt werden, damit ein langsames Team schneller wird. Das macht aber durchaus Sinn. Wenn das System gut zusammenarbeitet und kein Team überlastet ist, steigt die Produktivität insgesamt. Auch macht es häufig wenig Sinn, Code lange vor dem notwendigen Zeitpunkt fertig zu stellen – die Anforderungen könnten sich ja noch einmal ändern, während die parallel am Produkt arbeitenden Teams andere Funktionen umsetzen.

Insofern ist die Verlangsamung der schnellen Teile einer Produktionskette durch eine Umverteilung von Aufgaben wohl der agilste Teil der Theory of Constraints. Wenn nämlich alle Teams schnell ausliefern können, bleibt das Backlog kurz und jede Zeile Code entspricht den neusten Anforderungen! Dafür lohnt es sich, an einer Stelle ein wenig Tempo heraus zu nehmen, die Geschwindigkeit eines Teams zu senken und damit ein anderes Team zu entlasten.

4. Hilft das nicht? Investieren!

Erst, wenn weder eine Optimierung innerhalb der Schwachstelle, noch eine Umverteilung von Aufgaben auf der Systemebene dabei geholfen haben die Gesamtproduktion zu erhöhen, kann über Investitionen nachgedacht werden. Wenn alle Teams optimal auf einander abgestimmt sind, aber trotzdem zu wenig Code entsteht, kann das System durch mehr Arbeitskraft oder die Auslagerung von Aufgaben entlastet werden. Vorher sollte allerdings noch einmal zu Schritt eins zurück gegangen werden, um erneut zu überprüfen, wo genau die Hürden liegen und welche Schwachstellen sich aus dieser Maßnahme ergeben könnten.

5. Zurück zu Schritt 1

Auch wenn bereits in Schritt vier eine Rückkehr zum ersten Schritt auf dem Weg zur Auflösung von Schwachstellen notwendig ist, ist es damit nicht getan. Wurde das Problem in Schritt drei nämlich behoben, geht es mit Schritt fünf weiter und der lautet erneut: Zurück zum Anfang. Eine weitere Prämisse der TOC lautet nämlich, dass jedes System theoretisch dazu in der Lage ist, unbegrenzt viel zu produzieren. Manche Grenzen lassen sich natürlich nicht aufheben; so wird kein komplexes Produkt jemals in einem Tag entstehen, egal wie viele Entwickler darauf angesetzt werden. Irgendwo gibt es aber doch immer noch eine Möglichkeit zur Verbesserung der Produktivität – ein wenig Waste hier, eine neue Methode dort… und schon geht die Arbeit viel leichter von der Hand!

Die Theory of Constraints ist allerdings auch kein Allheilmittel. Obwohl immer etwas verbessert werden kann, muss in Schritt zwei immer auch eine Kosten-Nutzen-Rechnung erfolgen: Werden neue Methoden eingeführt, kostet das Zeit; muss ein Prozess verändert werden, ist das mit Aufwand verbunden. Am Ende geht es der Theory of Constraints also nicht so sehr darum, jede Schwachstelle auszumerzen, sondern viel mehr darum, das Gleichgewicht innerhalb eines System herzustellen, sodass jede Abteilung darin ungehindert ihre Arbeit machen kann. Das kann allerdings auch bedeuten, dass der alte Grundsatz „never change a running system“ angewendet wird. Weniger ist nämlich mehr – bei der Produktion von Code genau so wie bei Gütern und auch bei Verbesserungen.


Aufmacherbild: Three Businessman and Businesswoman meditation via Shutterstock / Urheberrecht: Titima Ongkantong

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -