schlanker Prozesse Softwareentwicklung

Von David J.Anderson.David J.Anderson ist der Autor von drei Büchern, Lektionen in der agilen Verwaltung: Auf dem Weg zu Kanban, das im Jahre 2012 veröffentlicht wurde, Kanban: Erfolgreiche Evolutionsänderung für das Technologiegeschäft, [1], das im Jahre 2010 veröffentlicht wurde, und Agile-Management für Softwaretechnik: Anwenden der Theorie der Beschränkungen für Geschäftsergebnisse, [2], das im Jahre 2003 veröffentlicht wurde.Er war Mitglied eines Teams in Singapur, das von 1997 bis 1999 im Rahmen der agilen Softwareentwicklung die Methode „Feature-Driven Development“ (FDD) entwickelt hat.Die erstellte MSF for CMMI Process Improvement und er CO-erstellte technischen Hinweis vom Software Engineering Institute, "CMMI und Agile: Warum nicht Umarmung beide!" Es wurde ein Gründer der verschlankte System-Gesellschaft (http://www.leansystemssociety.org).Er ist CEO von Mager-Kanban University Inc., ein beglaubigtes Training und die Qualitätsstandardorganisation, die weltweit Kanban-Training über ein Netzwerk von Partnern und davon anbietet, führt ein internationales Management-Training und Nachschlagenunternehmen, David J.Anderson & Associates Inc.(http://www.agilemanagement.net), die Technologieunternehmen hilft, ihre Performance mithilfe besserer Management- und Entscheidungsstrategien zu optimieren.

November 2011 aktualisiertes im November 2012.

Anderson beschreibt Lean Software Development (dt. schlanke Softwareentwicklung).

Betrifft

Lean, Softwareentwicklung, Projektmanagement, Team Foundation Server

• Introduction

• Lean und Agile

• Lean zusätzlich zu Agile

• Definieren von Lean Software Development

• Werte

• Prinzipien

• Verfahren

Der Begriff Lean Software Development wurde zum ersten Mal als Name für eine Konferenz gewählt, die im Oktober 1992 im Rahmen des ESPRIT-Programms der Europäischen Union in Stuttgart abgehalten wurde.Unabhängig davon wird ein Jahr später von Robert Charette das Konzept von Lean Software Development als Teil einer Arbeit vorgeschlagen, in der er Möglichkeiten für ein optimales Risikomanagement in Softwareprojekten untersucht.Der Begriff Lean wird 1991 von James Womack, Daniel Jones und Daniel Roos in ihrem Buch The Machine That Changed the World: The Story of Lean Production[3] als eine englische Bezeichnung für den bei Toyota praktizierten Managementansatz vorgeschlagen.Nachdem Lean zunächst im Zusammenhang mit Trends in den Herstellungsverfahren und in der Verfahrenstechnik angewendet wird, etabliert sich dieses Konzept kurze Zeit später auch in der Softwareentwicklung.

In ihrem zweiten, 1995 veröffentlichten Buch definieren Womack und Jones[4] fünf Kernprinzipien von Lean Thinking (schlankes Denken).Diese sind:

• Wert

• Wertstrom

• Fluss

• Pull

• Perfektion

Diese Prinzipien werden für das folgende Jahrzehnt die allgemein übliche Arbeitsdefinition für Lean.Perfektion wird nach diesem Ansatz durch die Beseitigung von Verschwendung erreicht.Von diesen fünf Prinzipien findet vor allem das Anstreben von Perfektion durch Aufspüren und Eliminieren unwirtschaftlicher Aktivitäten eine große Resonanz.Lean wird spätestens ab dem Ende der 1990er fast ausschließlich mit der Beseitigung von Verschwendung gleichgesetzt.

Die Definition von Womack und Jones für Lean wird jedoch nicht allgemein geteilt.Die Managementprinzipien bei Toyota sind weitaus detaillierter.Das englische Wort „Waste“ (dt. Verschwendung) wird im Japanischen mit den folgenden drei Begriffen differenzierter beschrieben:

• Muda - bedeutet eigentlich „Verschwendung“, impliziert aber auch nicht wertschöpfende Aktivitäten

• Mura - bedeutet „Unausgeglichenheit“ und wird als „Variabilität im Fluss“ interpretiert

• Muri - bedeutet „Überlastung“ oder „Unzumutbarkeit“

Perfektion wird sowohl durch die Reduzierung nicht wertschöpfender Aktivitäten als auch durch den reibungslosen Fluss (Durchlauf) und die Eliminierung von Überlastung erreicht.Der Ansatz von Toyota basiert auf einem grundlegenden Respekt vor dem Menschen und wird stark durch die Lehren von Experten der Qualitätssicherung und statistischen Prozesslenkung des 20. Jahrhunderts beeinflusst, wie beispielsweise W.Edwards Deming.

Leider gibt es für den Begriff Lean mindestens so viele Definitionen wie Autoren zu diesem Thema.

Lean und Agile

Im Jahre 2001 wird bei einem Treffen in Snowbird, Utah (an dem Robert Charette trotz Einladung leider nicht teilnehmen konnte) das Manifesto for Agile Software Development[5] (deutsch: Agiles Manifest) formuliert.Das Lean Software Development-Konzept von Robert Charette wird jedoch auch ohne seine Anwesenheit als einer von mehreren agilen Ansätzen für die Softwareentwicklung angesehen.In seinem 2002 erschienenen Buch[6] widmet Jim Highsmith diesem Thema in Form eines Interviews mit Robert Charette ein Kapitel.Etwas später veröffentlichen Mary & Tom Poppendieck eine Reihe von drei[7,8,9] Büchern.In den ersten Jahren des 21. Jahrhunderts wird mithilfe der Lean-Prinzipien erklärt, weshalb agile Methoden besser sind.Mithilfe des Lean-Ansatzes wird belegt, dass agile Methoden wenig „Verschwendung“ beinhalten und zu einem besseren wirtschaftlichen Ergebnis führen.Lean-Prinzipien werden als Berechtigung zur Implementierung agiler Methoden benutzt.

Lean zusätzlich zu Agile

Lean Software Development hat sich in den letzten Jahren als eigene Disziplin herausgebildet, die zwar mit der Agile-Bewegung verbunden ist, ohne jedoch ein spezieller Teilbereich davon zu sein.Diese Entwicklung beginnt mit der Synthese von Konzepten aus dem Lean Product Development und den Arbeiten von Donald G.Reinertsen[10,11] und Konzepten aus dem nicht agilen Bereich der groß angelegten Projektplanung und den Arbeiten von James Sutton und Peter Middleton[12].Ich habe ferner die Arbeit von Eli Goldratt und W.Edwards Deming zusammengefasst und den Fokus nicht auf die Reduzierung von Verschwendung, sondern auf den Fluss gerichtet[13].Gegen 2005 habe ich auf Anregung von Reinertsen die Verwendung von Kanban-Systemen vorgestellt. In diesen Systemen wird die Work in Progress (WIP, laufende Arbeit) begrenzt und nur neue Arbeit aufgenommen (Pull-Prinzip), wenn das System sie abarbeiten kann.In seinem 2009 veröffentlichten Buch zum Thema[14] bringt Alan Shalloway zusätzliche Überlegungen zu Lean Software Development ein.Seit 2007 richtet das Lean-Konzept als neue Kraft in der Softwareentwicklung den Fokus auf die Verbesserung von Fluss, Risikomanagement und Entscheidungsfindung.Kanban erweist sich als besonders förderlich für Lean-Programme in der Informationstechnik.Scheinbar ist ein Fokus auf den Fluss anstelle eines Fokus auf die Reduzierung von Verschwendung ein besserer Antriebsfaktor für den kontinuierlichen Verbesserungsprozess innerhalb von Knowledge Work-Aktivitäten wie z. B. die Softwareentwicklung.

Definieren von Lean Software Development

Das Definieren von Lean Software Development ist eine Herausforderung, da es keine spezifische Methode bzw. keinen spezifischen Prozess im Lean Software Development gibt.Lean ist keine Entsprechung zu Personal Software Process, V-Model, Spiral Model, EVO, Feature-Driven Development, Extreme Programming, Scrum oder Test-Driven Development.Lebenszyklusprozesse in der Softwareentwicklung oder Projektmanagementprozesse können als „lean“ bezeichnet werden, wenn sie auf die Werte der Lean Software Development-Bewegung und die Prinzipien von Lean Software Development ausgerichtet sind.Wer jedoch hofft, einem einfachen Rezept namens Lean Software Development folgen zu können, wird enttäuscht.Mit dem Verständnis von Lean-Prinzipien und dem Anwenden der Grundwerte von Lean muss dann jeweils der eigene Softwareentwicklungsprozess gestaltet und angepasst werden.

Innerhalb von Lean Software Development gibt es verschiedene Denkrichtungen.Das größte und bestreitbar übergeben, Schule ist die schlanke System-Gesellschaft, die Donald Reinertsen, Jim Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick und David J umfasst.Anderson.Mary- und Tom-Poppendiecks Arbeit separat entwickelt vor der Bildung der Unternehmen und seiner Kredostände, wie die Arbeit von Craig Larman, von Bas Vodde [15,16] und wird, zuletzt von Jim Coplien [17].Suchen dieses Artikels, breit sein Vertreter des verschlankte System-Gesellschaftsblickpunkts, wie in den Kredo ausgedrückt und eine Synthese und eine Zusammenfassung der Ideen bereitzustellen.

Werte

Die schlanke System-Gesellschaft veröffentlichte sein Kredo [18] an den 2012 schlanke Software-u. System-Konferenz [19].Dies war auf einem Satz von Werten, die ein Jahr zuvor veröffentlicht wurden.Zu den Werten zählen: Wenn

• Die menschliche Natur akzeptieren

• Akzeptieren, dass Komplexität und Ungewissheit ein natürlicher Teil der Knowledge Work sind

• Auf ein besseres wirtschaftliches Ergebnis hinarbeiten

• Ein besseres soziologisches Ergebnis ermöglichen

• Konzepte aus einer Vielzahl von Disziplinen suchen, aufnehmen und hinterfragen

• Eine Community mit Wertgrundsätzen verbessert Tempo und Reichweite von positiven Änderungen

Die menschliche Natur akzeptieren

Knowledge Work wie Softwareentwicklung wird von Menschen durchgeführt.Als Menschen sind wir von komplexer Natur und werden solange wir logisch denkende Wesen sind auch von unseren Gefühlen und Instinkten gesteuert, die wir nicht ausschalten können.Beim Entwickeln von Systemen oder Prozessen, in denen wir arbeiten, muss unsere Psychologie und Neuropsychologie berücksichtigt werden.Ferner muss unserem Sozialverhalten entgegengekommen werden.Menschen sind von Natur aus Gefühls- und Gesellschaftswesen und unser Verhalten ändert sich bei Ermüdung und Stress.Erfolgreiche Prozesse kommen der menschlichen Natur entgegen anstatt sie zu verleugnen und ein logisches, maschinenähnliches Verhalten vorauszusetzen.

Akzeptieren, dass Komplexität und Ungewissheit ein natürlicher Teil der Knowledge Work sind

Es ist nicht vorhersehbar, wie sich Kunden und Märkte verhalten.Der Arbeitsfluss durch einen Prozess und eine Zusammenstellung von Arbeitskräften ist nicht vorauszusehen.Fehler und notwendige Nacharbeit sind unvorhersehbar.In der Softwareentwicklung existiert auf vielen Ebenen ein inhärenter Zufall oder ein scheinbar zufälliges Verhalten.Der Zweck, die Ziele und der Umfang von Projekten verändern sich häufig bei der Auslieferung.Einige dieser anfangs nicht erkannten Ungewissheiten und Variabilitäten sind zumindest insoweit erfassbar, indem sie untersucht, abgewägt und nach Risikorelevanz eingestuft werden können. Andere Variabilitäten sind jedoch von vornherein unbekannt und daher nicht einschätzbar.Daher müssen die Systeme des Lean Software Development auf aktuelle Ereignisse reagieren können. Das System muss sich auf verändernde Umstände anpassen können.Jeder Lean Software Development-Prozess muss daher innerhalb eines Frameworks existieren, das eine Anpassung (des Prozesses) auf sich entwickelnde Ereignisse ermöglicht.

Auf ein besseres wirtschaftliches Ergebnis hinarbeiten

Menschliche Tätigkeiten wie Lean Software Development sollten darauf ausgerichtet sein, ein besseres wirtschaftliches Ergebnis hervorzubringen.Kapitalismus ist insofern zulässig, wenn er sowohl zum Wert des Unternehmens als auch zum Vorteil des Kunden beiträgt.Investoren und Unternehmer verdienen eine Rendite.Angestellte und Arbeiter verdienen eine angemessene Bezahlung für ihren Arbeitseinsatz.Kunden verdienen gute Produkte und Dienstleistungen, die zu einem angemessenen Preis den versprochenen Nutzen liefern.Bessere wirtschaftliche Ergebnisse implizieren, dem Kunden mehr Wert zu geringeren Kosten zu bieten und dabei das von den Investoren und Unternehmern bereitgestellte Kapital so wirkungsvoll wie möglich zu verwalten.

Ein besseres soziologisches Ergebnis ermöglichen

Bessere wirtschaftliche Ergebnisse sollten nicht zulasten der Arbeitskräfte erzielt werden.Die Schaffung eines Arbeitsplatzes, der den Menschen unter Berücksichtigung seiner Natur respektiert und Arbeitssysteme bereitstellt, die die psychologische und soziologische Natur des Menschen anerkennen, ist von grundlegender Bedeutung.Ein attraktiver Arbeitsplatz, der kreatives und sinnvolles Arbeiten ermöglicht, gehört zu den wesentlichen Werten der Lean Software Development-Community.

Prinzipien

Die Lean Software & Systems-Community ist sich in Bezug auf einige Prinzipien einig, die Lean Software Development-Prozesse unterstützen.

• Einem Ansatz des Systemdenkens und Systemdesigns folgen

• Entstehende Ergebnisse lassen sich durch die Gestaltung des Kontextes für ein komplexes adaptives System beeinflussen

• Menschen respektieren (als Teil des Systems)

• Wissenschaftliche Methode einsetzen (um Verbesserungen voranzutreiben)

• Führungseigenschaften fördern

• Für Transparenz sorgen (bei der Arbeit, dem Workflow und dem Systembetrieb)

• Durchlaufzeit reduzieren

• Zur Effizienzverbesserung Verschwendung reduzieren

Einem Ansatz des Systemdenkens und Systemdesigns folgen

Diese Vorgehensweise wird in der Lean-Literatur häufig als „Optimize The Whole“ bezeichnet. Darunter wird verstanden, dass wir das sich aus dem gesamten System (oder Prozess) ergebende Resultat optimieren, und nicht fälschlicherweise Teilbereiche verbessern mit der Hoffnung, dass dadurch automatisch das ganze System optimiert wird.Die meisten Fachleute sind der Meinung, dass dieser Ansatz richtig ist. Sie gehen davon aus, dass die Optimierung von Teilbereichen (lokale Optimierung) nur zu einem suboptimalen Ergebnis führen kann.

Ein Ansatz des schlanken Systemdenkens und Systemdesigns erfordert, dass wir die von externen Beteiligten (z. B. Kunden) gestellten Anforderungen (Demands) an das System und das von diesen Beteiligten gewünschte Ergebnis berücksichtigen.Wir müssen die Art der Anforderung bzw. Nachfrage ermitteln und mit dem Potenzial vergleichen, das unser System für die Auslieferung bietet.Die Nachfrage beinhaltet Value Demand (Nachfrage mit Wertsubstanz), wofür Kunden bereit sind zu zahlen, und Failure Demand (Nachfrage aufgrund eines Fehlers oder Misserfolgs), normalerweise eine Nacharbeit oder eine zusätzliche Nachfrage, die durch einen Misserfolg beim Liefern von Value Demand entsteht.Failure Demand präsentiert sich häufig auf zwei Arten: Nachbearbeitung von zuvor ausgeliefertem Value Demand oder zusätzliche Serviceleistungen bzw. Support aufgrund eines Misserfolgs beim Liefern von Value Demand.In der Softwareentwicklung sind Fehlerbehebungsanfragen und das Anfordern von Kundenservice- oder Helpdeskfunktionen in der Regel Failure Demand.

Ein Systemdesignansatz erfordert, dass wir für Prozessdesign und Verbesserung auch einem PDSA-Ansatz (Plan-Do-Study-Act) folgen.W.Edwards Deming verwendet die Wörter „study“ (untersuchen) und „capability“ (Fähigkeit), womit er meint, dass wir die „Naturphilosophie“ vom Verhalten unseres Systems analysieren sollen.Dieses System besteht aus unserem Softwareentwicklungsprozess und allen daran beteiligten Personen.Es zeigt ein erkennbares Verhalten im Hinblick auf Vorlaufzeit, Qualität, Menge an bereitgestellten Features oder Funktionen (in der Agile-Literatur als „Velocity“ (Geschwindigkeit) beschrieben) usw.Da diese Messdaten Variabilität aufweisen, können wir beim Analysieren des Mittelwertes und des Umfangs der Abweichung ein Verständnis über unsere Fähigkeit entwickeln.Falls diese Daten mit der Nachfrage und den Kundenerwartungen nicht übereinstimmen, muss zum Schließen dieser Lücke das System erneut entworfen werden.

Deming meint auch, dass Fähigkeit zu 95 % durch das Systemdesign beeinflusst wird und die Leistung von Einzelpersonen nur 5 % dazu beisteuert.Das heißt, dass wir Menschen respektieren, indem wir ihnen erstens keinen Vorwurf machen, wenn zwischen Fähigkeit und Nachfrage eine Lücke besteht, und indem wir zweitens das System dahin gehend neu entwerfen, dass sie erfolgreich sein können.

Um ein Systemdesign verstehen zu können, brauchen wir ein wissenschaftliches Verständnis von der Dynamik der Systemfähigkeit und wie sich diese beeinflussen lässt.Modelle werden entwickelt, um die Dynamik des Systems vorauszuberechnen.Obwohl es viele mögliche Modelle gibt, kommen im Allgemeinen nur einige gängige zur Anwendung: das Verständnis von wirtschaftlichen Kosten, die sogenannten Transaktions- und Koordinationskosten, die sich auf die Her- oder Bereitstellung von Produkten und Dienstleistungen mit Kundenwert beziehen, die Theory of Constraints oder Engpasstheorie zum Erfassen von Engpässen und die Theory of Profound Knowledge zum Analysieren und Bestimmen der Variabilität als im Systemdesign geläufig (intern) oder ungewöhnlich und somit nicht darin enthalten (extern).

Entstehende Ergebnisse lassen sich durch die Gestaltung des Kontextes für ein komplexes adaptives System beeinflussen

Komplexe Systeme verfügen über Ausgangsbedingungen und einfache Regeln, die nach einer iterativen Ausführung ein Ergebnis hervorbringen.Die entstehenden Ergebnisse lassen sich mit den Ausgangsbedingungen nur schwer oder gar nicht vorhersagen.Das Informatikexperiment „The Game of Life“ ist ein Beispiel eines komplexen Systems.Ein komplexes adaptives System verfügt über ein gewisses Maß an Eigenwahrnehmung und eine interne Methode der Reflexion, womit es ermessen kann, inwieweit sein aktuelles Regelwerk dazu beiträgt, das gewünschte Ergebnis zu erreichen.Das komplexe adaptive System kann sich dann – durch Ändern seiner einfachen Regeln – zu einer Anpassung entscheiden, um die Lücke zwischen dem aktuellen und dem angestrebten Ergebnis zu schließen.Das „Game of Life“ passt sich so an, dass Regeln, die während des Spiels umgeschrieben werden können, ein komplexes adaptives System bilden.

In den Prozessen der Softwareentwicklung sind die einfachen Regeln von komplexen adaptiven Systemen die Richtlinien, die die Prozessdefinition ausmachen.Das Kernprinzip ist hierbei, dass die Entwicklung von Softwareprodukten und Softwareservices keine deterministische Aktivität ist und deshalb ein definierter Prozess, der sich nicht anpassen kann, keine angemessene Antwort auf unvorhersehbare Ereignisse ist.Deshalb muss der Prozess als Teil unseres Ansatzes des Systemdenkens und Systemdesigns anpassungsfähig sein.Der Prozess passt sich über die Änderung der Richtlinien an, aus denen er sich zusammensetzt.

Im Lean Software Development macht sich der Kanban-Ansatz dieses Konzept zunutze, indem die Richtlinien des Kanban-Pull-Systems als einfache Regeln behandelt werden. Als Ausgangsbedingungen gelten: Arbeit und Workflow werden visualisiert, der Fluss wird mit einem Verständnis von Systemdynamik verwaltet und die Organisation verwendet einen wissenschaftlichen Ansatz, um Prozessverbesserungen zu verstehen, vorzuschlagen und zu implementieren.

Menschen respektieren

Die Lean-Community übernimmt von Peter Drucker die Definition für Knowledge Work, die besagt, dass die Fachkräfte dann Knowledge Worker sind, wenn ihr Kenntnisstand bei der durchgeführten Arbeit größer ist als der ihrer Vorgesetzten.Diese Tatsache impliziert, dass Knowledge Worker dort eingesetzt werden, wo sie selbst entscheiden können, wie die Arbeit ausgeführt wird und wie Prozesse für eine optimale Arbeitsausführung geändert werden können.Die Meinung der Arbeitskraft sollte also immer respektiert werden.Die Arbeitskräfte müssen die Möglichkeit haben, die Durchführung ihrer Arbeit und das Erzielen gewünschter Ergebnisse selbst zu organisieren.Sie sollen dazu befähigt werden, Chancen zur Prozessverbesserung zu implementieren, die in der Lean-Literatur als Kaizen-Ereignisse beschrieben werden.Eine weitere Möglichkeit, Mitarbeiter zu respektieren, besteht darin, die Prozessrichtlinien klar und eindeutig hervorzuheben, damit jeder die auferlegten Regeln kennt.Eindeutig definierte Regeln befähigen zur Selbstorganisation, indem Sie Befürchtungen und das Verlangen nach risikofreudigen Aktionen beseitigen.Wenn wir unseren Arbeitskräften Möglichkeiten zur Selbstorganisation einräumen und eindeutige Regeln vorgeben, werden wir unserem Anspruch gerecht, die menschliche Natur zu respektieren.

Wissenschaftliche Methode einsetzen

Versuchen Sie, Modelle einzusetzen, damit Sie die Dynamik verstehen, wie die Arbeit durchgeführt wird und das System von Lean Software Development funktioniert.Verfolgen und analysieren Sie das System und seine Fähigkeit, und entwickeln und verwenden Sie dann Modelle zum Prognostizieren des Systemverhaltens.Sammeln Sie in Ihren Studien quantitative Daten, um die Funktionsweise des Systems zu verstehen und einzuschätzen, wie es sich beim Ändern des Prozesses verhält.

Die Lean Software & Systems-Community verwendet statistische Methoden wie Regelkarten der statistischen Prozesslenkung und Spektralanalysehistogramme von Rohdaten für Vorlaufzeit und Geschwindigkeit, um das Leistungsvermögen des Systems zu bestimmen.Daneben kommen auch folgende Modelle zum Einsatz: die Theory of Constraints oder Engpasstheorie zum Erfassen von Engpässen, die sogenannte Theory of Profound Knowledge zum Unterscheiden einer dem Systemdesign innewohnenden Abweichung von einer extern beeinflussten Abweichung und die Analyse der wirtschaftlichen Kosten, die nach dem Erzeugen von Produkten und Dienstleistungen mit Kundenmehrwert ausschließlich in der Form von Aufgaben anfallen, die für Koordinierung, Setup, Auslieferung oder Bereinigung vorgenommen werden.Es kommen auch einige andere Modelle wie die Realoptionsanalyse zum Einsatz, bei der versucht wird, Realoptionsmodelle aus dem Finanzrisikomanagement für eine realistische Entscheidungsfindung zu nutzen.

Die wissenschaftliche Methode suggeriert: Analysieren, Aufstellen bzw. Vorhersagen eines Ergebnisses auf Grundlage eines Modells, Beeinflussen des Systems auf Grundlage dieser Vorhersage und Beobachten, ob die Beeinflussung zu den im Modell vorhergesagten Ergebnissen führt.Sofern das nicht der Fall ist, werden die Daten und die Korrektheit des Modells überprüft.Mit dem Einsatz von Modellen erheben Sie die zuvor auf der Grundlage von Intuition ausgeführten Prozessverbesserungen zu einer wissenschaftlichen Aktivität.

Führungseigenschaften fördern

Führungsvermögen und Management sind nicht ein und dasselbe.Das Management vereint Aktivitäten zum Entwickeln von Prozessen, zum Erstellen, Ändern und Entfernen von Richtlinien, zum Treffen von strategischen und operativen Entscheidungen, zum Erfassen von Ressourcen, zum Bereitstellen von Finanzierungsmöglichkeiten und Einrichtungen und zum Weitergeben von Kontextinformationen wie Strategie, Ziele und gewünschte Ergebnisse.Beim Führungsvermögen geht es um Vision, Strategie, Taktiken, Mut, Innovation, Urteilsvermögen, Interessenvertretung und weitere Eigenschaften dieser Art.In einer Organisation darf und sollte jeder Führungseigenschaften besitzen.Kleine Demonstrationen von Führungsfähigkeit aus den Reihen der Arbeitskräfte haben eine Vielzahl von Verbesserungen zur Folge, die die Änderungen hervorbringen, die zum Schaffen eines Lean Software Development-Prozesses erforderlich sind.

Für Transparenz sorgen

Knowledge Work ist unsichtbar.Was Sie nicht sehen können, ist (nahezu) unmöglich zu verwalten.Es ist daher notwendig, die durchgeführten Arbeiten transparent zu machen und die Abläufe innerhalb eines Netzwerks von Einzelpersonen, Kompetenzen und Abteilungen bis zu ihrem Abschluss aufzudecken.Der Prozessentwurf muss transparent sein, indem nach Möglichkeiten gesucht wird, den Prozessfluss zu visualisieren und die Prozessrichtlinien für alle Beteiligten explizit darzustellen.Durch das Sichtbarmachen dieser Vorgänge wird die Verwendung der wissenschaftlichen Methode möglich. Über mögliche Verbesserungen lässt sich dann kollektiv und objektiv diskutieren.Eine kollektive Prozessverbesserung ist nahezu unmöglich, wenn Arbeit und Workflow nicht transparent und Prozessrichtlinien nicht explizit sind.

Durchlaufzeit reduzieren

In der Softwareentwicklung wird traditionsgemäß darauf geachtet, wie lange an einer Aktivität gearbeitet wird.In der Lean Software Development-Community wird es jedoch als sinnvoller angesehen, die tatsächlich abgelaufene Kalenderzeit zu messen, die die Bearbeitung einer Aktivität in Anspruch nimmt.Diese Zeit wird in der Regel als Zykluszeit bezeichnet und nach den Grenzen der ausgeführten Aktivitäten bewertet.Die Zykluszeit von der Analyse bis zur Bereitstellungsbereitschaft misst beispielsweise die insgesamt verstrichene Zeit, in der eine Arbeitsaufgabe wie z. B. eine User Story analysiert, konzipiert, entwickelt, auf verschiedene Arten getestet und dann als bereitstellungsbereit in die Warteschlange der Produktionsumgebung übergeben wird.

Auf die Zeit zu achten, in der die Arbeit den Prozess durchläuft, ist aus mehreren Gründen wichtig.Bei längeren Zykluszeiten nimmt die Fehlerquote nichtlinear zu.Kürzere Zykluszeiten führen deshalb zu besserer Qualität.Dies widerspricht der Intuition, da es merkwürdig scheint, dass ohne menschliche Intervention beim Warten Fehler in den Code gelangen können.Bisher wurde in der Softwareentwicklung bei diesem Phänomen diese Leerlaufzeit ignoriert.Empirische Daten belegen jedoch, dass Zykluszeit wichtig für die anfängliche Qualität ist.

Alan Shalloway spricht auch von dem Konzept einer „verursachten Arbeit“. Er stellt fest, dass durch eine Ausführungsverzögerung die jeweilige Aufgabe unter Umständen viel arbeitsaufwendiger wird.Beispielsweise dauert es möglicherweise nur 20 Minuten, einen erkannten Fehler sofort zu beheben. Wenn dieser Fehler aber selektiert und dann mehrere Tage oder Wochen nicht behoben wird, kann seine Korrektur mehrere Stunden in Anspruch nehmen.Die Zykluszeitverzögerung hat somit zusätzliche Arbeit „verursacht“.Da diese Arbeit vermeidbar ist, ist sie nach der Lean-Definition „Verschwendung“.

Der dritte Grund, den Fokus auf die Zykluszeit zu richten, ist von wirtschaftlicher Art.Feature, Funktion oder User Story haben alle ihren jeweils eigenen Wert.Dieser Wert mag unbestimmt sein, aber er existiert.Der Wert kann sich im Laufe der Zeit ändern.Das Konzept eines sich im Laufe der Zeit ändernden Wertes kann betriebswirtschaftlich als eine Payoff-Funktion ausgedrückt werden.Wird die Payoff-Funktion für eine Arbeitsaufgabe verstanden – auch wenn die Funktion einen Wertbereich zum Modellieren von Ungewissheit aufweist –, dann können Verzögerungskosten ausgewertet werden. Mit den Verzögerungskosten können wir dann der Zykluszeitreduzierung einen Wert zuordnen.

Bei einigen Arbeitsaufgaben setzt die Payoff-Funktion nicht vor einem in der Zukunft bekannten Datum ein.Beispielsweise hat ein Feature, das in den Vereinigten Staaten zum Nationalfeiertag am 4. Juli zur Anwendung kommen soll, vor diesem Datum keinen Wert.Die Verkürzung der Zykluszeit und die Fähigkeit, die Zykluszeit mit einem gewissen Maß an Sicherheit vorauszusagen, ist in einem solchen Beispiel dennoch nützlich.Idealerweise sollte die Arbeit zu einem Zeitpunkt beginnen, um das Feature genau dann auszuliefern, wenn es benötigt wird und nicht früher. Ein späterer Auslieferungstermin ist ebenfalls nicht wünschenswert, da dadurch Verzögerungskosten entstehen.Die rechtzeitige Auslieferung gewährleistet eine optimale Verwendung von verfügbaren Ressourcen.Eine vorzeitige Auslieferung bedeutet, dass an etwas anderem gearbeitet wurde und folglich Opportunitätskosten angefallen sind.

Wegen dieser drei Gründe wird im Lean Software Development versucht, die Durchlaufzeit zu reduzieren und Daten zu erfassen, die Prognosen hinsichtlich der Durchlaufzeit zulassen.Ziel dabei ist, aus Fehlern herrührenden Failure Demand und die aus Überlastung (wegen verzögerter Fehlerbehebung) resultierende Verschwendung zu minimieren sowie den ausgelieferten Wert durch Vermeidung von Verzögerungs- und Opportunitätskosten zu maximieren.

Zur Effizienzverbesserung Verschwendung reduzieren

Jede wertschöpfende Aktivität beinhaltet auch Setup-, Bereinigungs- und Auslieferungsaktivitäten, die zwar notwendig sind, aber nicht selbstständig Wert erzeugen.Eine Projektiteration, bei der z. B. das Inkrement einer funktionsfähigen Software entwickelt wird, erfordert Planung (eine Setupaktivität), eine Umgebung und möglicherweise eine Codeverzweigung in der Versionskontrolle (zusammen als Konfigurationsverwaltung bekannt und auch eine Setupaktivität), einen Freigabeplan und das Ausführen der tatsächlichen Freigabe (eine Auslieferungsaktivität), eine Vorstellung gegenüber dem Kunden (eine Auslieferungsaktivität) und möglicherweise ein Abbau der Umgebung oder eine Neukonfiguration (eine Bereinigungsaktivität.) Wirtschaftlich gesehen sind die Setup-, Bereinigungs- und Auslieferungsaktivitäten Transaktionskosten, die beim Ausführen wertschöpfender Arbeit entstehen.Diese Kosten (oder Mehraufwand) werden im Lean Software Development als Verschwendung angesehen.

Jede Form von Mehraufwand für Kommunikation kann als Verschwendung gewertet werden.Besprechungen zum Bestimmen des Projektstatus und zum Einplanen oder Zuweisen von Arbeit an Teammitglieder sind aus wirtschaftlicher Sicht Koordinationskosten.Im Lean Thinking sind alle Koordinationskosten Verschwendung.Die Methoden im Lean Software Development sind auf die Beseitigung oder Reduzierung von Koordinationskosten ausgerichtet. Typische Ansätze sind hier die gemeinsame Unterbringung von Teammitgliedern (Co-location), kurze persönliche Treffen wie Einsatzbesprechungen (Standups) und visuelle Kontrollen wie Kartenwände.

Die dritte häufige Art der Verschwendung im Lean Software Development ist Failure Demand.Failure Demand ist eine Belastung für das System der Softwareentwicklung.Failure Demand ist in der Regel einer Nacharbeit oder neue Formen von Arbeit als Folgeerscheinung minderer Qualität.Die häufigsten Arten von Failure Demand in der Softwareentwicklung sind Fehler, Produktionsmängel und Kundensupportaktivitäten, erforderlich aufgrund eines Fehlers, die Software wie beabsichtigt zu verwenden.Der Prozentsatz an Work in Progress, der Failure Demand ist, wird oft als Bruchlast bezeichnet.Der Prozentsatz von wertschöpfender Arbeit im Vergleich zu Failure Demand ist ein Maßstab für die Effizienz des Systems.

Der Prozentsatz von wertschöpfender Arbeit im Vergleich zum gesamten Arbeitsaufwand einschließlich aller nicht wertschöpfenden Transaktions- und Koordinationskosten bestimmt den Leistungsgrad.Ein System ohne Transaktionskosten, Koordinationskosten und Bruchlast kann als 100 % effizient angesehen werden.

Bisher wurde in der westlichen Betriebswissenschaft gelehrt, dass die Effizienz durch ein Steigern der Batchgröße optimiert werden kann.Normalerweise sind Transaktions-und Koordinationskosten aber feste Größen oder nehmen bei einer Erhöhung der Batchgröße nur leicht zu.Daher sind große Arbeitsbatches effizienter.Dieses Konzept ist als Skaleneffekt (economies of scale) bekannt. Bei Knowledge Work-Problemen neigen jedoch Koordinationskosten dazu, nichtlinear zur Batchgröße zu steigern, während die Transaktionskosten häufig linear zunehmen.Die im 20. Jahrhundert bisher übliche Vorgehensweise zur Steigerung der Effizienz ist daher für Knowledge Work-Probleme wie Softwareentwicklung nicht zweckmäßig.

Zur Effizienzsteigerung ist es viel besser, die Gemeinkosten zu senken und darauf zu achten, dass die Batchgrößen klein bleiben.Die Lean-Methode für Effizienz heißt daher: Verschwendung reduzieren.Lean Software Development konzentriert sich auf schnelle und kostengünstige Planmethoden, geringen Kommunikationsmehraufwand und effektive Koordinierungsmechanismen mit geringem Mehraufwand, wie beispielsweise die visuellen Kontrollen in den Kanban-Systemen.Mit automatisierten Tests und einer automatisierten Bereitstellung werden ferner die Transaktionskosten für die Auslieferung reduziert.Moderne Hilfsmittel zum Minimieren der Kosten für den Auf- und Abbau der Umgebung, wie die neuen Versionskontrollsysteme und der Einsatz von Virtualisierung tragen ebenfalls dazu bei, die Effizienz von kleinen Softwareentwicklungsbatches zu verbessern.

Verfahren

Das Lean Software Development gibt keine Verfahren vor.Es ist viel wichtiger darzustellen, dass die zurzeit gültigen Prozessdefinitionen mit den Prinzipien und Werten einhergehen.Gewöhnlich kommt jedoch eine Anzahl von Verfahren zur Anwendung.Dieser Abschnitt bietet eine kurze Übersicht über einige Verfahren.

Kumulierte Flussdiagramme

Kumulierte Flussdiagramme sind seit 2005 standardmäßig ein Bestandteil der Berichterstellung in Team Foundation Server.Kumulierte Flussdiagramme zeichnen ein Flächendiagramm der aufgelaufenen Arbeitsaufgaben in den einzelnen Phasen des Workflows.Mithilfe dieser aufschlussreichen Diagramme lässt sich sowohl die durchschnittliche Zykluszeit zwischen den Schritten eines Prozesses als auch die Durchsatzrate (oder „Geschwindigkeit“) ableiten.Verschiedene Lebenszyklusprozesse der Softwareentwicklung erzeugen in den kumulierten Flussdiagrammen unterschiedliche visuelle Signaturen.Über den im Flächendiagramm dargestellten Prozess können die IT-Kräfte verschiedene Muster von Funktionsstörungen erkennen.Ein echter Lean-Prozess weist gleichmäßig verteilte Farbflächen auf, die sanft und harmonisch ansteigen.Die Abbildung ist stufenlos ohne gezackte Schritte oder sichtbare Farbblöcke.

In ihrer einfachsten Form kommen kumulierte Flussdiagramme zur Anwendung, um die Work in Progress-Menge in jeder Phase des Lebenszyklus einer Arbeitsaufgabe visuell darzustellen.Dadurch lassen sich Engpässe erkennen und die Auswirkungen von „Mura“ (Variabilität im Fluss) verfolgen.

Visuelle Kontrollen

Neben den kumulierten Flussdiagrammen werden im Lean Software Development auch physische Tafeln oder Projektionen elektronischer Visualisierungssysteme eingesetzt, um Arbeit visuell darzustellen und den Fluss zu kontrollieren.Dank solcher Visualisierungsmöglichkeiten können Teammitglieder die sich anhäufende Work in Progress überwachen und Engpässe sowie die Auswirkungen von „Mura“ erkennen. Visuelle Kontrollen ermöglichen außerdem, dass Teammitglieder ihre Aufgaben in Eigenorganisation auswählen und zusammenarbeiten, ohne dass eine vorgegebene Planungsrichtung oder spezifische Vorgesetztenanweisung erforderlich ist.Diese visuellen Kontrollen werden häufig als Kartenwände und mitunter auch (fälschlicherweise) als Kanban-Tafeln bezeichnet.

Virtuelle Kanban-Systeme

Ein Kanban-System ist ein Verfahren aus dem Lean Manufacturing (schlanke Produktion).Das System bedient sich physischer Karten, um die Menge an Work in Progress in jeder Phase des Workflows zu begrenzen.Solche Systeme zum Begrenzen der Work in Progress erzeugen beim Start von neuer Arbeit nur dann ein „Pull“ (Abholsignal), wenn freie Kanban-Elemente anzeigen, dass neue Arbeit in eine bestimmte Phase zur Weiterverarbeitung übergeben (pulled) werden kann.

Im Lean Software Development sind die Kanban-Systeme virtuell und werden oft überwacht, indem ein Maximalwert für eine bestimmte Phase im Workflow eines Arbeitsaufgabentyps festgelegt wird.In einigen Implementierungen überwachen elektronische Systeme das virtuelle Kanban-System und geben ein Signal aus, wenn neue Arbeit gestartet werden kann.Das Signal kann visuell sein oder in Form einer Benachrichtigung wie z. B. als E-Mail ausgegeben werden.

Virtuelle Kanban-Systeme werden häufig mit visuellen Kontrollen kombiniert. Dadurch wird ein visuell- virtuelles Kanban-System zur Verfügung gestellt, das den Workflow von mindestens einem Arbeitsaufgabentyp darstellt.Solche Systeme werden häufig als Kanban-Tafeln oder elektronische Kanban-Systeme bezeichnet. Ein visuell-virtuelles Kanban-System steht für Team Foundation Server als das Plug-In Visual WIP[20] zur Verfügung.Dieses Projekt wurde von Hakan Forss in Schweden als Open Source entwickelt.

Kleine Batchgrößen / One-Piece-Flow

Lean Software Development erfordert, dass die Arbeit entweder in kleinen Batches (häufig als „Iterationen“ oder „Inkremente“ bezeichnet) durchgeführt wird, oder dass die Arbeitsaufgaben unabhängig den Fluss durchlaufen, was als One-Piece-Flow (Einzelstückfluss) bezeichnet wird. Der One-Piece-Flow setzt ein umfangreiches Konfigurationsmanagement voraus, damit die abgeschlossene Arbeit ausgeliefert werden kann, ohne dass die unvollständige Arbeit versehentlich freigegeben wird.Dies wird normalerweise mithilfe von Verzweigungsstrategien im Versionskontrollsystem erreicht.Ein kleiner Arbeitsbatch kann normalerweise von einem kleinen Team von maximal acht Leuten in weniger als 14 Tagen abgearbeitet werden.

Bei kleinen Batches und dem One-Piece-Flow ist eine häufige Interaktion mit den Unternehmern erforderlich, um bei Rückstand den Nachschub sicherzustellen oder die Warteschlange bzw. Arbeit zu ergänzen.Ferner muss eine häufige Freigabe möglich sein.Zur Gewährleistung eines oftmaligen Zusammenspiels mit Geschäftsleuten und einer häufigen Auslieferung sind bei beiden Aktivitäten die Transaktions- und Koordinationskosten zu senken.Dies lässt sich üblicherweise durch den Einsatz von Automatisierung erreichen.

Automatisierung

Für einen wirtschaftlich sinnvollen One-Piece-Flow, ein hohes Qualitätsniveau und die Reduzierung von Failure Demand wird im Lean Software Development ein hohes Maß an Automatisierung vorausgesetzt.Der Einsatz von automatisierten Tests, automatisierter Bereitstellung und Software Factorys zur Automatisierung der Bereitstellung von Entwurfsmustern und zur Erstellung von Quellcode mit sich wiederholenden Bereichen niedriger Variabilität wird in den Lean Software Development-Prozessen allgemein üblich sein.

Kaizen-Ereignisse

In der Lean-Literatur wird unter dem Begriff Kaizen „fortlaufende Verbesserung“ verstanden. Bei einem Kaizen-Ereignis wird eine Änderung an einem Prozess oder Werkzeug vorgenommen, mit der Erwartung, dass dies zu einer Verbesserung führt.

Im den Lean Software Development-Prozessen werden Kaizen-Ereignisse mithilfe verschiedener Aktivitäten erzeugt, dieim Folgenden aufgeführt werden.Alle Aktivitäten sind so konzipiert, dass sie zur Auseinandersetzung mit Problemen anregen, die das Leistungsvermögen nachteilig beeinflussen und sich somit negativ auf die Auslieferung im Verhältnis zur Nachfrage auswirken.Das Wesentliche von Kaizen in der Knowledge Work ist, dass über Gruppen aus unterschiedlichen Teams mit verschiedenen Kenntnissen hinweg eine Auseinandersetzung mit den Problemen gesucht wird.

Tägliche Einsatzbesprechungen

In der Regel treffen sich bis zu 50 Softwareentwickler in ihren Teams vor einem visuellen Kontrollsystem wie einem Whiteboard, auf dem die Work in Progress visuell dargestellt wird.Es werden dabei die Dynamik des Workflows und die ihn beeinflussenden Faktoren besprochen.Die aufgrund externer Faktoren blockierte oder sich wegen Fehlern verzögernde Arbeit erfährt besondere Beachtung.Nach einer Reihe von Einsatzbesprechungen werden die Probleme mit dem Prozess häufig ersichtlich.Als Folge bleibt nach der Besprechung noch eine kleinere Gruppe zurück, um das Problem zu erörtern und eine Lösung oder Prozessänderung vorzuschlagen.Ein Kaizen-Ereignis folgt.Diese spontanen Besprechungen werden in älterer Literatur häufig als spontane Qualitätszirkel beschrieben.Solche spontanen Besprechungen sind das Kernstück einer echten Kaizen-Kultur.Um die Einführung von Lean-Methoden in der Organisation voranzutreiben, fördern Vorgesetzte nach den täglichen Einsatzbesprechungen das Hervorbringen von Kaizen-Ereignissen.

Retrospektiven

Die Projektteams legen regelmäßige Treffen zum Auswerten der neuesten Ergebnisse fest.Diese Besprechungen finden oft nach dem Abschluss bestimmter Projektdeliverables oder nach festgelegten Entwicklungsinkrementen (in der agilen Softwareentwicklung als Iterationen oder Sprints bezeichnet) statt.

Bei einer Retrospektive wird gern ein anekdotenhafter Ansatz zur Diskussion genutzt, indem Fragen wie „Was ist gut gelaufen?“, „Was könnten wir anders machen?“ und „Was sollten wir besser unterlassen?“ gestellt werden.

Retrospektiven erzeugen in der Regel eine Fülle von Vorschlägen für Kaizen-Ereignisse.Das Team kann dann einigen dieser Vorschläge Priorität für die Implementierung geben.

Operations Reviews (dt. Überprüfung der Vorgänge)

Ein Operations Review ist in der Regel umfangreicher als eine Retrospektive. Es nehmen daran Vertreter von einem ganzen Wertstrom teil.Gewöhnlich präsentieren bis zu zwölf Abteilungen objektive, quantitative Daten, die die erhaltene Nachfrage belegen und zeigen, inwieweit das Leistungsvermögen ausreicht, um die Nachfrage mit der Auslieferung abzudecken.Operations Reviews finden in der Regel einmal im Monat statt.Die Hauptunterschiede zwischen einem Operations Review und einer Retrospektive bestehen darin, dass ein Operations Review eine größere Menge von Funktionen einbezieht, normalerweise auch ein Portfolio von Projekten und anderen Initiativen umfasst und objektive, quantitative Daten verwendet werden.Retrospektiven sind eher auf ein einzelnes Projekt begrenzt, beziehen nur wenige Teams wie Analyse-, Entwicklungs- und Testteams mit ein und sind im Allgemeinen anekdotenhaft.

Ein Operations Review führt zu einer Auseinandersetzung mit der Dynamik, die die Leistung zwischen den Teams beeinflusst.Möglicherweise generiert ein Team Failure Demand, der von einem anderen Team verarbeitet wird?Möglicherweise ist dieser Failure Demand störend und führt dazu, dass das zweite Team seine Verpflichtungen nicht einhalten kann und nicht erwartungsgemäß liefert?Bei einem Operations Review können solche Probleme besprochen und Änderungen vorgeschlagen werden.Operations Reviews erzeugen normalerweise eine Reihe von möglichen Kaizen-Ereignissen, die für die zukünftige Implementierung priorisiert und eingeplant werden können.

Einen einheitlichen Lean Software Development-Prozess gibt es nicht.Ein Prozess kann als „lean“ bzw. schlank bezeichnet werden, wenn er eindeutig auf die Werte und Prinzipien von Lean Software Development ausgerichtet ist.Lean Software Development gibt keine Verfahren vor, aber einige Aktivitäten haben sich als allgemein üblich etabliert.Lean-Organisationen fördern das Kaizen-System durch die Visualisierung von Workflow und Work in Progress sowie durch ein Verständnis der Dynamik des Flusses und der sich auf den Fluss auswirkenden Faktoren (wie Engpässe, keine unmittelbare Verfügbarkeit, Variabilität und Verschwendung).Die vorgeschlagenen Prozessverbesserungen werden als Möglichkeiten gerechtfertigt, die Quellen der Variabilität zu reduzieren, Verschwendung zu beseitigen, den Fluss zu verbessern oder die Wertbereitstellung und das Risikomanagement zu optimieren.Lean Software Development-Prozesse befinden sich aus diesem Grund immer in der Entwicklung und müssen jeweils auf die Organisation angepasst werden, in der sie zum Einsatz kommen.Wenn einfach eine Prozessdefinition von einer Organisation auf eine andere übertragen wird, kann nicht erwartet werden, dass diese Definition in einem anderen Kontext funktioniert.Wenn wir nach einigen Wochen oder Monaten wieder zu einer Organisation zurückkehren, ist es außerdem unwahrscheinlich, dass der eingesetzte Prozess noch der gleiche ist, wie zuvor.Prozesse werden sich immer entwickeln.

Die Organisation, die einen Lean Software Development-Prozess einsetzt, kann als „lean“ bezeichnet werden, wenn sie nur geringe Mengen von Verschwendung in allen drei Formen („Mura“, „Muri“ und „Muda“) aufweist und sich nachweisen lässt, dass sie die Wertbereitstellung durch ein effektives Risikomanagement optimiert hat.Im Lean Thinking ist das Streben nach Perfektion immer der Wegund nicht das Ziel.Die echte Lean-Organisation ist kontinuierlich auf der Suche nach weiteren Verbesserungen.

Lean Software Development ist noch ein im Wachstum begriffenes Fachgebiet und wird sich voraussichtlich im folgenden Jahrzehnt weiterentwickeln.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones & Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 updated edition, Free Press, 2007

4. Womack, James P., & Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary & Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary & Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary & Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James & Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

14. Shalloway, Alan & Guy Beaver & James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig & Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.& Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/