• Home
  • |
  • Blog
  • |
  • Agile Produktentwicklung #1: Einführung

25. April 2017

Agile Produktentwicklung #1: Einführung

Was ist für ein Unternehmen teurer: eine nicht ausgelastete Ressource (Maschine, Mitarbeiter), oder eine Aufgabe bzw. ein Material, das nicht bearbeitet wird?

Sowohl in der Produktion, wie auch in der Produktentwicklung ist die Erkenntnis vorhanden, dass eine Störung im Durchfluss teurer ist, als eine nicht ausgelastete Ressource. Doch nicht überall hat diese Erkenntnis auch zu Veränderungen in der Praxis geführt

Agile Produktentwicklung ist aus verschiedenen Quellen entstanden, ein paar Grundlagen möchte ich in diesem Kapitel darstellen.

Toyota Produktions-System (TPS)

In den 1940er Jahren begann Taichi Ohno bei Toyota damit die Fertigung zu optimieren. Sein Antrieb war die schlechte Ressourcenlage in Japan während des zweiten Weltkriegs und in der Zeit danach. Sein Ziel war es, Verschwendung zu vermeiden. Neben dem durch schlechte Qualität verursachten Ausschuss war für Ohno eine weitere Verschwendung die damals übliche Pufferbildung. Puffer wurden verwendet um störanfällige Maschinen kompensieren zu können, um Qualitätsprobleme und fehlerhafte Planung auszugleichen. Ohno begann damit, die Probleme die zur Pufferbildung führten nachhaltig zu lösen, um so den Puffer zu minimieren oder ganz wegfallen zu lassen. Dies ging auch einher mit der Reduzierung der Losgrößen, was dann zum einen teuren Puffer reduzierte und zum anderen mehr Flexibilität gegenüber den Kunden bzw. dem Markt erzeugte.

Für mich ist dabei folgender Aspekt wesentlich: Ohno wandelte die Sichtweise auf die Produktion von der lokalen Optimierung der einzelnen Prozessschritte hin zur End-to-End-Betrachtung:  Halbfertige Erzeugnisse verursachen Kosten (Wert der Bestände, Lagerkosten) und verlangsamen gleichzeitig den Durchsatz in der Fertigung (große Losgrößen), was neben der Erhöhung der Kosten auch den Zeitpunkt des Geldeingangs nach hinten verzögerte.

Alleine die Verringerung der Losgröße hin zur Losgröße eins („One Piece Flow“) reduzierte die Durchlaufzeit um 90%. Diese Verringerung der Losgröße erfordert natürlich große Anstrengungen um die Rüstkosten zu senken.

Neben der Verringerung der Losgrößen war für Ohno zentrales Element, die Qualität innerhalb des Prozesses zu erzeugen und nicht nach dem Prozess zu abzusichern. In der neuen End-to-End-Betrachtung war es nun für das Unternehmen günstiger, bei Qualitätsproblemen die Fertigung zu stoppen um das Problem sofort und nachhaltig zu lösen anstatt den Schwerpunkt auf Auslastung zu setzen und die problembehafteten Fahrzeuge am Ende des Bandes nachzubearbeiten. Neu war auch, dass nun der Arbeiter am Band über den Bandstopp entscheiden konnte ohne seinen Vorarbeiter oder eine andere Management-Instanz konsultieren zu müssen.

Eine der Kernaussagen des TPS ist damit für mich: Die Kosten die durch Verringerung der Bestände und von Verschwendung eingespart werden sind deutlich größer als die Kosten die z.B. bei einem Bandstopp durch geringere Auslastung entstehen.

Die Organisation, also Mitarbeiter und Manager, müssen damit umgehen können, dass es vollkommen in Ordnung ist, wenn ein Mitarbeiter einmal nichts zu tun hat oder eine Produktionsmaschine stillsteht. Vorrang hat das sofortige Angehen von entdeckten Problemen und die Aufrechterhaltung der Durchlaufzeit bei gleichbleibender Qualität.

In den 1980er Jahren wurden die Prinzipien von James Womack und anderen aufgegriffen und sind seither unter dem Begriff „Lean Manufacturing“ in den Sprachgebrauch eingegangen.

Agile Entwicklung

Agile Ansätze in der Softwareentwicklung sind aus einer anderen Motivation entstanden als das TPS bzw. das sogenannte „Lean Manufacturing“. Nachdem in den 1980ern und 1990ern viele Software-Projekte aufgrund ihrer Komplexität gescheitert sind, ist eine Bewegung entstanden, die seit 2001 unter dem Begriff „Agile Entwicklung“ bekannt geworden ist.

Die in der Historie verwendeten wasserfallartigen phasengetriebenen Vorgehensmodelle für Entwicklungsprojekte sind nicht geeignet in Umgebungen zu operieren, in denen die Produktanforderungen oder die verwendete Technologie oder gar beides unbekannt ist.

Während bei unbekannten Technologien bisher eher schon intuitiv mit Prototypen und Feedbackschleifen gearbeitet wurde, waren Organisationen lange der Meinung, dass sich Anforderungen an das zu entwickelnde Produkt bei Projektbeginn eindeutig festlegen lassen.

Im folgenden Diagramm ist die Entwicklung eines Produktes schematisch dargestellt:

Feedbackpfade

 

Aus einem Business-Kontext heraus wird eine Spezifikation aufgeschrieben (erste Transition). Aus der Spezifikation wird dann ein Produkt entwickelt (zweite Transition). Während sich die ganze Industrie gut darauf versteht, die zweite Transition („Entwicklung“) über Tests abzusichern, wurde die erste Transition traditionell nur einmal am Projektende überprüft, in dem das Produkt an den Kunden übergeben wurde. Die Wahrscheinlichkeit, dass das Produkt dann für das Business des Kunden maximal nützlich ist, ist eher gering. Aus einer erkannten Aufgabe oder einem erkannten Problem heraus eine umfassende und eindeutige Spezifikation zu erstellen ist eine nahezu unlösbare Aufgabe, auch wenn das klassische Requirements-Engineering davon ausgeht, dass es mit genügend ausreichend Aufwand möglich wäre. Eine weitere Herausforderung ist die Veränderung des Business-Kontext während der Entwicklungsphase.

Damit wird auch der Nachteil dieses Ansatzes offensichtlich: Zu dem Zeitpunkt zu dem der Kunde das Produkt für seinen Einsatz evaluieren kann und wichtige Anpassungen an der Spezifikation vornehmen kann, sind in der Regel Zeit wie auch Geld im Entwicklungsprojekt zu Ende. Sowohl Kunde wie auch Entwickler haben mit diesem Ansatz verloren.

Agile Entwicklung akzeptiert, dass die korrekten Anforderungen erst aus dem praktischen Einsatz entstehen und strebt daher an, die im Diagramm dargestellte Feedbackschleife möglichst oft zu durchlaufen. Mehrfaches Überarbeiten des Produkts wird dazu in Kauf genommen, um ein optimales Produkt zu liefern und auch schon frühe Versionen des Produkts für den Kunden operativ einsetzbar zu machen („früher Wert“).

Das agile Manifest

Das Agile Manifest, im Original „Manifesto for agile Software Development“, kurz „Agile Manifesto“ entstand 2001 auf einer Konferenz in Utah. 17 bedeutende Software „Gurus“ haben sich in einer Diskussion darauf geeinigt, was für sie agile Softwareentwicklung ausmacht.

Das Agile Manifest gliedert sich in 4 Werte (bzw. Wertepaare) und 12 Prinzipien, auf die ich im Folgenden kurz eingehen möchte.

Werte

Die vier Wertepaare im agilen Manifest lauten:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Wenn Sie dies zum ersten Mal lesen, sind Sie vielleicht verunsichert, denn vermutlich sind bei Ihrer bisherigen Arbeit die Werte die jeweils rechts des Wortes „over“ stehen von zentraler Bedeutung gewesen. Auch wenn es von vielen anders interpretiert wird, das Agile Manifest streitet die Bedeutung dieser Werte auch nicht ab, sondern bekräftigt im letzten Satz deren Bedeutung.

Interessant ist dabei der Gedanke, dass Werte alleine keine Bedeutung haben können, sondern sich nur als Wertepaare anwenden lassen. Betrachten Sie zum Beispiel den Wert „Ehrlichkeit“ isoliert. Ehrlichkeit klingt gut, kann aber für sich alleine genommen keinen Wert bilden. Denn wenn Sie einer Person die Sie nicht mögen ehrlich die Meinung sagen, hat das vermutlich negative Auswirkungen auf das soziale Gefüge zwischen Ihnen. Der balancierende Wert wäre in diesem Fall zum Beispiel „Respekt“. In der Regel werden Sie unbewusst versuchen in diesem Beispiel, also dem Umgang mit dem ungeliebten Mitmenschen, die Werte Ehrlichkeit und Respekt in eine Balance bringen. Wobei immer einer der Werte leicht dominieren wird.

Sehen wir die Wertepaare des agilen Manifests mit diesem Blickwinkel, lesen wir nicht mehr (was leider oft geschieht), dass funktionierende Software wichtiger ist als umfassende Dokumentation, sondern dass umfassende Dokumentation (als isolierter Wert) ohne funktionierende Software in die Sackgasse führt. Beide Werte in einem Wertepaar müssen immer zusammen wachsen um in Balance zu bleiben. Keine Seite darf alleine gefördert werden.

Ich erlebe oft dass das Agile Manifest gegen die Agilität verwendet wird, weil es in seiner sehr kompakten Formulierung oft falsch interpretiert wird. Vor allem von Berufs wegen konservative Kolleginnen und Kollegen aus den Bereichen Qualitätssicherung, Funktionale Sicherheit und Prozessreifegradmodelle verwenden das Manifest als Beweis, dass agile Entwicklung in Ihrer Branche nicht funktionieren kann. Diskussionen anhand des Manifests sind also unter Umständen gefährlich. Der Ansatz mit den balancierten Wertepaaren hilft dabei eine ausgewogene Interpretation der kurzen Statements zu erreichen. Versuchen Sie die Wertepaare in Ihrer Branche, in Ihrem Business zu interpretieren.

Prinzipien

Neben den vier Wertepaaren führt das Manifest auch 12 Prinzipien auf. Diese geben einen Leitfaden für die Gestaltung der täglichen Arbeit. Auch die Prinzipien sind kein abstrakter Denkansatz, sondern eine Sammlung von „Best Practice“ Aspekten von erfahrenen Software-Entwicklern und Projektleitern. Die Prinzipien sind nützlich um die aktuelle Vorgehensweise zu reflektieren oder zu verändern.

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 

Ähnliche Beiträge

Agiles Buch: Erstes Print-Release

Agiles Buch: Responding to change over following a plan

Agiles Buch – die ersten Inkremente

Agiles Buch – erste Schritte