Run on Scrum

Zunehmend kommt man mit sogenannten „agilen“ Entwicklungsmethoden in Berührung wenn man Innovation mit IT Komponenten plant – immer öfter wird Scrum verwendet. Diese Methoden haben sich in den letzten 10 Jahren immer mehr bemerkbar gemacht.

Agile Methoden haben aber nicht nur Vorteile – nach unserer Recherche sollte ihr Einsatz erwogen werden, wenn

  • schnelle Entwicklung einen Marktvorteil bedeutet,
  • viele Einflüsse auf ein Entwicklungsprojekt zu geänderten Anforderungen führen, und
  • die Zufriedenheit der Kunden und Mitarbeiter oberstes Kriterium ist.

Der Einsatz agiler Methoden sollte überdacht werden, wenn

  • komplexe Sachverhalte zu bewältigen sind oder sehr hohe Qualität erforderlich ist,
  • die andauernde Pflege der Systeme bedacht werden muss, und wenn
  • fachliche Kreativität und disruptive Innovation gewünscht sind

Was sind agile Entwicklungsmethoden?

Im Jahr 2001 wurde von einigen Entwicklern, das “Agile Manifesto” veröffentlicht und unterzeichnet. Das Manifest legt Prinzipien fest, die bei kunden- und ergebnisorientierten Arbeiten beachtet werden sollten. Das Manifest charakterisiert die Ziele vieler agiler Methoden und fasst diese zusammen mit

  • “Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan”

Agile Methoden stellen deswegen das eigentliche Programmieren in den Vordergrund und nicht häufig diskutierte klassische Themen wie Dokumentation, umfangreiche Abstimmungen und Struktur. Gelegentlich kann es bei agilen Methoden deshalb auch dazu kommen, dass Programme neu erstellt werden müssen.

Agile Entwicklungsmethoden

Stellt man die Dimensionen „Anzahl der Iterationen“ und „Komplexität pro Zyklus“ gegenüber, so lässt sich argumentieren, dass agile Methoden dort gut angesiedelt sind, wo Geschwindigkeit vor Komplexität geht. „Wassferfall“ Methoden sind eher auf ausführliche Abstimmungsprozesse ausgelegt um die bestmögliche Lösung in wenigen Iterationen zu erreichen.

Was ist Scrum?

Scrum wurde in den 90er Jahren von zwei Unterzeichnern des Agilen Manifests Ken Schwaber und Jeff Sutherland entwickelt. Letzterer hat 2003 mit zwei Partnern die “Scrum Alliance” ins Leben gerufen. Diese ermöglicht eine Zertifizierung und trägt zu der Popularität von Scrum bei.

Teammitglieder organisieren ihre Arbeit hier weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -methoden. Mittels eines Product-Backlog werden kleinere Entwicklungspakete abgegrenzt, die von einer überschaubaren Mannschaft (z.B. 5 Entwickler in einem Monat) in so kurzer Zeit umgesetzt werden können, dass das System getestet und einsatzbereit ist. Mit vielen, klar strukturierten Meetings zum Teil auf täglicher Basis wird ein intensiver Kontakt zwischen der fachlichen und der technischen Seite des Projekts hergestellt. Diese Gespräche werden nur grob und oft handschriftlich dokumentiert und ersetzten so oft die Dokumentation.

Jeff Sutherland erklärt Scrum auch so: „Scrum is …

  • an agile process to manage and control development work …
  • a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
  • a process that controls the chaos of conflicting interests and needs
  • a way to improve communications and maximize co-operation …
  • a way to maximize productivity.
  • Scrum is scalable from single projects to … projects with over a thousand developers and implementers.

Pro und Contra

Schnelle Entwicklung

Agile Methoden sind im Vorteil, wenn die Geschwindigkeit der Entwicklung wesentlich ist. Die Abstimmung zwischen Entwicklern und den anfordernden Parteien erfolgt schnell und wird nur dokumentiert, wo dies nötig erscheint.

Unabhängigkeit von externe Einflüssen

Projekte werden in kleine Einheiten unterteilt. Gerade bei Scrum sind diese Einheiten auch so gestaltet, dass nach kurzer Zeit bereits Produkte entstehen, die getestet und lauffähig sind.  So ist auch bei grundlegenden Änderungen ein Produkt vorhanden, das funktioniert.

Zufriedene Kunden und Mitarbeiter

Kunden können in Abstimmungen stark einbezogen werden. Damit haben sie viel Einfluss auf die Entwicklung und sind gut informiert. Mitarbeiter werden bei agilen Methoden gefordert. Gerade bei Scrum wählt das Team Entwicklungstechniken und Arbeitspakete gemeinsam aus.

Komplexe Sachverhalte

Vorgelagerte Schritte zur Abstimmung von komplexen Sachverhalten erfordern häufig hohe Konzentration. Funktionale Gesichtspunkte zu durchdenken und abzustimmen, User Experience Tests oder Markttests können lange dauern.
In diesen Fällen ist es oft empfehlenswert, die fachliche und die technische Entwicklung zu entkoppeln und ausgearbeitete Konzeptionen über Testbedingungen abzusichern.

Pflege der Systeme

Je weniger Dokumentation vorhanden ist, desto schwieriger ist die Pflege bestehender Systeme. Bei der Pflege von Systemen sind ursprünglichen Experten selten dann verfügbar, wenn man sie braucht. Dann wird vor allem fachliche Dokumentation benötigt.

Kreativität und disruptive Innovation

Oft wird erwähnt, dass Scrum gerade für Situationen geeignet ist, in denen Kreativität gewünscht ist. Dabei bezieht man sich auf Ikujiro Nonaka und Hirotaka Takeuchi, die Ihren Artikel “The New New Product Development Game” 1986 im Harvard Business Review eben solche Situationen untersucht haben. Sie haben zwar ein sinnvolles Vorgehen mit dem Rugby-Spiel verglichen woraus sich der Name Scrum ableitet. Aber ansonsten bestehen wenige Parallelen. Die auffälligste ist, dass Nonaka und Takeuchi interdisziplinäre Teams fordern. Dies ist bei Scrum nur eingeschränkt der Fall.
Kreativität und disruptive Innovation bedingen, dass sich ein Team Zeit dafür nimmt, Fehlschläge einkalkuliert und unter Hochdruck arbeitet.

 

Teilen/Share

12 Gedanken zu „Run on Scrum

  1. Hallo Jürgen,

    danke für diesen Artikel. Es ist gut, Scrum nicht immer und überall blind anwenden zu wollen, nur weil es gerade Mode ist ;). Allerdings kann ich zwei Deiner drei genannten Fälle für eine Absage an Scrum als Prozeß nicht nachvollziehen:

    “Komplexe Sachverhate”
    Hier bin ich bei Dir. In solchen Fällen ist eine Trennung zwischen fachlicher und technischer Lösung sinnvoll. Ich sehe diesen Fall vor allem zu Beginn komplexer Projekte. Im späteren Verlauf kann man evtl. zu Scrum übergehen.

    “Pflege der Systeme”
    Die Dokumentation im Scrum findet vor allem über Tests (am besten BDD) statt. Werden diese Tests gewissenhaft erstellt – nicht nur als Alibi-Tests ;) -, so stellen sie eine sehr gute und verständliche Dokumentation dar. Jeder Entwickler (auch ohne Scrum-Erfahrung) versteht diese Dokumentation und kann sie verwenden.

    “Kreativität und disruptive Innovation”
    In meiner Auffassung sind interdisziplinäre Teams gerade ein Kernbestandteil von Scrum – es gibt explizit keine Trennung nach fachlichen Gesichtspunkten. Das Einkalkulieren von Fehlschlägen ist ebenfalls Kern der agilen Philosophie, in der man für das “Unplanbare plant” – ein Stichwort: Rapid Prototyping. Ich persönlich sehe Scrum sogar besonders geeignet nicht nur für die Entwicklung, sondern für die grundlegende Organisation von Unternehmen, um eben disruptive Innovationen zu unterstützen. Gerade bei disruptiven Innovationen geht es um Neues und Unvorhergesehenes, dem mit agilen Strukturen super begegnet werden kann – Stichwort: Agile Enterprise.

    Falls Du Anmerkungen zu meinen Kommentaren hast, würd ich das Thema gern weiter diskutieren. Denn auch ich bin stetig auf der Suche nach Verbesserungen von Entwicklungsprozessen :).

    Viele Grüße aus dem Zelt,

    Matthias

    1. Zunächst einmal vielen Dank für Deinen Kommentar, Matthias!

      Ich möchte Scrum durchaus keine Absage erteilen, sondern deutlich machen, wann ein Einsatz sinnvoll ist.

      Pflege der Systeme:

      Die Dokumentation über Testergebnisse kann ein Entwickler sicherlich gut nachvollziehen. Meines Erachtens kann dies aber dazu führen, dass der “rote Faden” auf der fachlichen Seite verloren geht. Viele der Probleme, die ich mit Scrum (aber auch mit anderen Methoden ) hatte, lassen sich darauf zurückführen (wenn man einmal ein System prüfen muss, das seit Jahren in Betrieb ist, versteht man möglicherweise eher, was ich meine). Naturgemäß finden bei Scrum häufig inhaltliche Änderungen statt. Gerade der intensive Kontakt zwischen Entwicklern und der Fachseite eröffnet Möglichkeiten, die man zuvor nicht immer wahrnimmt.

      Es erfordert einen hohe Disziplin diese Änderungen immer in fachlichen Dokumentationen nachzuhalten, weswegen dies oft unterbleibt. Ich meine, dass die Gefahr dazu bei Scrum noch höher ist als sonst schon, weil es eigentlich der Regelfall sein dürfte, dass fachliche Texte mehrfach überarbeitet werden müssen.

      Die technische Dokumentation ist wichtig, wenn aber nur diese existiert ist die fachliche Seite bei der Pflege der Systeme immer auf Entwickler angewiesen, die diese übersetzt. Hier habe ich schlechte Erfahrungen gemacht, denn Entwickler haben meist anderes zu tun.

      Kreativität und disruptive Innovation:

      Im Prinzip bin ich bei Dir, genau darum geht es in dem Artikel von Hirotaka Takeuchi, Ikujiro Nonaka . Nach meinem Wissen beschränkt sich der Anteil verschiedener Disziplinen bei Scrum aber auf einen Product Owner und verschiedenen technische Ausrichtungen. Nach meinem Dafürhalten geht dies viel weniger weit, als im Artikel vorgeschlagen. Dort waren im Entwicklungsteam auch fachlich unterschiedlichste Disziplinen vertreten, oder nicht?

      1. Hallo Jürgen,
        Bezug nehmend auf “Kreativität und disruptive Innovation” -“…Nach meinem Wissen beschränkt sich der Anteil verschiedener Disziplinen bei Scrum aber auf einen Product Owner und verschiedenen technische Ausrichtungen….” -> in Scrum haben wir ja die Rolle des Teams. und hier handelt es sich um um ein so genanntes “Cross Fuctional Team” das mehere Disziplinen der Softwareentwicklung abdecken soll.
        Also wenn man es auf die Softwareentwicklung reduziert haben wir durchaus ein Interdisziplinäres Vorgehen.

        viele Grüße
        JP

        1. Hallo JP,

          vielen Dank für den Kommentar.
          Scrum ist interdisziplinär wenn man es auf Softwareentwicklung beschränkt – hier stimme ich zu. Ein Produkt oder ein Service besteht aber nicht nur aus Software. Das wird meist vergessen.

          Beste Grüße
          Jürgen

      1. sagt:[…] früheren Artikeln (z.B.: IT-Spezifikation: Haben Sie einen krelan Auftrag? oder IT-Spezifikation: Schlüssel für die erfolgreiche Kooperation zwischen Fachseite und IT) habe ich Ihnen Anregungen für die Spezifikation der funktionalen Anforderungen gegeben. Heute […]

  2. 28. I’m not sure where you are getting your information, but great topic. I needs to spend some time learning much more or understanding more. Thanks for wonderful information I was looking for this info for my mission.

  3. Hallo Jürgen,
    Bei meiner Recherche zu Agilen Entwicklung bin ich auf diese Seite gestoßen.

    Man liest meist nur von Agiler Softwareentwicklung, wie sieht es mit Agiler Hardwareentwicklung aus? Gibt es hierzu auch Erfahrungen bezüglich Vorgehensweise und Umsetzung? Ein Pilotprojekt hat gezeigt, dass die Potentiale hier wohl nicht in der agilen Vorgehensweise liegen sondern eher an der externen und internen Schnittstellen der Organisation und Prozesse zu finden sind.

    Wie können Hardwareprojekte effizient mit Hilfe der agilen Entwicklungsmethode geplant und umgesetzt werden? Gibt es hierzu bereits Erfahrungsberichte die sie empfehlen können?

    Vielen Dank
    Nico

    1. Hallo Nico,

      in der Tat ist agile Hardware-Entwicklung kein geläufiger Begriff. Betrachtet man aber einige Ziele der agilen Softwareentwicklung, so lässt sich dies durchaus übertragen. Nach Erfahrungsberichten müsste ich allerdings wieder suchen:

      Reduktion von Komplexität war einer der ursprünglichen Treiber für agile Softwareentwicklung. Man konzentriert sich zunächst auf wenige aber wesentliche Funktionen, testet diese und entscheidet dann über den weiteren Ausbau.

      Prototyping / user tests sind ein möglicher Anwendungsfall für agile Development auch im Hardwarebereich. Man kann den Begriff Prototyping auch für das Innenleben einer Hardware anwenden und z.B. Kunden testen lassen, wie sie mit einer bestimmten Funktion zurechtkommen, bevor man weiterentwickelt.

      Interdisziplinäre teams sind ein wesentlicher Bestandteil von scrum (der Name ist einem Artikel über Softwareentwicklung entnommen). Man sollte Interdisziplinarität allerdings weiter fassen als Scrum dies tut, und z.B. sämtliche organisatorische Schnittstellen, Kunden und ggf. Partner mit einbeziehen. Letzteres ist auch bekannt unter early supplier involvement (siehe dazu auch dieses Blog).

      Ich hoffe das hilft!

      Beste Grüße
      Jürgen

  4. Even more if it is needed a Microsoft Project integration then the new product must also be able to export data in MS Project Data Exchange format.
    Absolutely no distinct software program is fitted to most venture
    requirements. The remainder of the article will discuss how each application can help you with your project management tasks.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>