Was sind agile Methoden?

Im Motorsport und beim Boxenstopp muss es schnell gehen. Ein eigespieltes Team wechselt Reifen, tankt das Auto und in 90 Sekunden ist es wieder auf der Strecke. Häufig wird agil mit Schnelligkeit gleichgesetzt. Aber stimmt das?

Was ist eigentlich agil? Was haben die agilen Methoden gemeinsam? Was unterscheidet sie? Klar ist, dass agile Methoden die Arbeitswelt in den letzten Jahren verändern. Im dynamischen Arbeitsumfeld der heutigen Zeit ist es essentiell, flexibel und reflexartig auf Änderungen eingehen zu können.

Spätestes mit der New-Work- Bewegung ist Agiles Arbeiten aus dem Arbeitsleben nicht mehr wegzudenken: Die Status quo agile Studie von 2019/2020 hat ergeben, dass 20% der Befragten durchgängig agile Arbeitsweisen verwenden und bis zu 43% der Befragten hybrid (sozusagen als „Mischform“). Schlusslicht sind hier die (durchgängig) klassischen Methoden, deren Einsatz in den letzten Jahren gesunken und nun bei 9% liegt (bei den Befragten)

Agile (Arbeits-)Methoden sind ein geeigneter Weg, um ein Team in der digitalen und schnelllebigen Welt flexibel und effektiv aufzustellen. Das selbstständige Arbeiten im Team in enger Zusammenarbeit mit den Kunden innerhalb iterativer Phasen ermöglicht es dem Team, trotz sich verändernder Rahmenbedingungen und unklarer Anforderungen erfolgreich ein gemeinsames Produkt zu entwickeln. Den Ursprung haben die agilen Methoden im agilen Manifest für Softwareentwicklung aus dem Jahr 2001. Die daraus entstandenen Werte und Prinzipien haben jedoch längst die Grenzen der Softwareentwicklung überschritten.

Agile Methoden siedeln sich nun auch in anderen IT-nahen oder sogar IT-fremden Bereichen an, in denen es um die Entwicklung von neuen Produkten in komplexen Situationen geht. So ergibt die oben genannte Studie, dass bei durchgängiger Verwendung agiler Methoden, 52% der Befragten diese für „IT-nahe“ Themen und 39% für „IT-neutrale“ Projekte verwenden.

Ausführlichere Ausführungen zum agilen Manifests finden Sie unter unserem Beitrag „Agilität im Unternehmen“. Dort erklären wir auch im Einzelnen die 12 Prinzipien des agilen Manifests auf.

Der Vorteil von agilen Methoden

Doch was ist nun die Motivation für den Einsatz von Agilen Methoden?  Wann und warum sollte ich agile Methoden für mein Vorhaben in Betracht ziehen?

In der Praxis heißt es dazu  häufig, „Wir haben keine Zeit ein Lastenheft zu schreiben, daher gehen wir agil vor“ Oder: „Es muss schnell gehen, daher nutzen wir agile Methoden.“ Regelmäßig werden agile Methoden zur Eierlegendenwollmilchsau hochstilisiert oder es wird Buzz-Word-Bingo gespielt.  Wenn das passiert, zeigt sich, dass viele Unternehmen den eigentlichen Sinn einer agilen Arbeitsweise nicht begriffen haben. Es fehlt wahrscheinlich auch an der richtigen Einstellung, dem agilen Mindset.

Um die Schlussfolgerung zu unterfüttern und etwas anschaulicher zu gestalten, stellen Sie sich folgendes Szenario vor:

    • Ihr Team möchte ein neues Produkt entwickeln und auf den Markt bringen
    • Dafür wurde ein klares Ziel definiert und ein ausgeklügelter Plan entwickelt
    • Die Produktentwicklung verläuft problemlos, der Plan wird zu 100% eingehalten
    • Das Produkt wird innerhalb des Zeit- und Budgetrahmens fertiggestellt und auf den Markt gebracht
    • Ihre Kunden sind glücklich und Ihr Team ist glücklich – eigentlich alles gut.

Und nun überlegen Sie bitte, wie häufig ist Ihnen das in den letzten Jahren in der Praxis passiert. Und warum kommen die meisten Projekt in der Realität nicht an das perfekte Projekt heran.

Anders als in der Utopie des perfekten Projektes, kämpfen sie in echten Projekten mit vielen Unschärfen, falschen Annahmen und wechselnden äußeren Einflüssen. Es ist häufiger der Fall, dass keine klaren Ziele definiert werden. Auch treten regelmäßig allerlei Einflüsse wie eine geänderte Regulatorik, neue Unternehmensstrategien, Erkrankung von Ressourcen oder ähnliches von außen und von innen auf, die nicht eingeplant waren und ein Projekt gefährden können. Besonders große und langwierige Projekte, also Projekte mit einer Laufzeit von mehr als 3-6 Monaten, sind anfälliger für Störungen und Fehlschläge.

Klassische Methoden verlangen klar definierte und stabile Rahmenbedingungen sowie unveränderte Strukturen oder Funktionalitäten. Jede Varianz zwischen Planung und Realität erfordert die Anpassung des Plans. Der Plan wird regelmäßig mit einer (Schein-)Genauigkeit bis zum Ende durchentwickelt.  Denn auf dem Papier bedeutet ein genauer Plan ein reduziertes Risiko und eine hohe Erfolgswahrscheinlichkeit für das Projekt. Es gilt, je genauer der Plan, desto geringer das Risiko und damit eine hohe Wahrscheinlichkeit für Erfolg.

Allerdings gilt diese Regel in der Realität nicht. Bereits im 18./19. Jahrhundert wussten die Militärstrategen zu formulieren:

„Kein Plan überlebt die erste Feindberührung.“

- Unbekannt -

„Pläne sind nichts. Planung ist alles.“

- Dwight D. Eisenhower -

34. Präsident der Vereinigten Staaten

Ein Schlüsselelement einer erfolgreichen Militärstrategie scheint also das flexible Reagieren auf eine veränderte Situation zu sein. Aber wie ist das in der Wirtschaft und bei Projekten.

Agilität ist gefragt

Hier kommen agile Methoden ins Spiel, die Entwicklungsprozesse mit unklaren Anforderungen und Vorgehensweisen effektiv angehen.  Hier liegt der Fokus auf Effektivität. Das sollte nicht mit Effizienz verwechselt werden. Denn das iterative Vorgehen, das „Fahren auf Sicht“, ermöglicht es zwar das Ziel sicher zu erreichen. Es ist aber Ressourcen und Zeit intensiv. Je weniger Unschärfen ein Projekt hat und je mehr Klarheit herrscht über die Anforderung sowie die Technologie und Methode, desto weniger sind agile Methoden für das Projekt zu empfehlen. Die Stärke der Agilen Methoden kommt erst zum Tragen, wenn innerhalb eines Projektes mit vielen Veränderungen zu rechnen ist.

Die Wahl der richtigen Methode für das Projekt ist der erste Schritt zum Projekterfolg. Eine gute Hilfe dafür ist es, das Projekt auf der sog. Stacey Matrix zu verorten. Die Stacey Matrix wurde von dem britischen Organisationstheoretiker und Professor für Management Ralph Douglas Stacey entwickelt. Er stellt in der Matrix die Anforderungen, also das „Was soll mein Produkt können?“ und die Technologie bzw. Methode, also das „Wie erzeuge ich das Was? “ gegenüber.

Je klarer das „Wie“ und das „Was“ sind, desto simpler ist das Projekt. Ist es nicht mehr glasklar, sondern nur noch eher klar als unklar, wird es kompliziert. Sobald aber die Anforderungen mehr unklar als klar sind und die Technologie oder Methode auch mehr unklar als klar ist, beginnt der komplexe Bereich. Wenn alles eher völlig unklar ist, herrschen chaotische Verhältnisse. Graphisch lassen sich die Bereiche wie folgt darstellen:

Mit dieser Erkenntnis lässt sich die passende Methode für das jeweilige Projekt auswählen. Es geht darum die Methoden entsprechend ihrer Stärken einzusetzen. Klassische Methoden haben sich im simplen und komplizierten Bereich bewährt. Es gibt also keinen Grund sie dort zu ersetzen.

Agile Methoden haben ihre Stärken im komplexen Bereich. Je nach Situation Ihres Projektes wählen Sie dort die Agile Methode, die Sie ein Stück näher Richtung Simpel bringt. Wenn sich das Projekt in einer frühen Phase eher im chaotischen Bereich befindet, können Methoden wie Design Thinking helfen, eine Projektvision zu erzeugen und mit ersten Funktionalitäten eine Grundlage schaffen. Diese wiederum kann als Grundlage für ein Scrum Projekt dienen, um ein erstes Minimum Viable Product (MVP) zu entwickeln.

Wenn sich ein Unternehmen Gedanken um die „richtige Arbeitsmethode“ macht, ist eine Einordnung des Projektes in die Bereich der Stacey Matrix eine Navigationshilfe.

Agile Methoden weisen viele Vorteile auf. In der Quintessenz bestehen die Vorteile insbesondere den folgenden Punkten: Zeit, Flexibilität und Risikominimierung. Das möchten wir kurz erörtern:

Zeit

Nach dem Parkinsonschen Gesetz „dehnt Arbeit sich immer so lang aus, wie man ihr Zeit zur Erledigung einräumt.“ Eine Maßnahme dagegen sind Timeboxes, feste Zeitintervalle von z.B. 2 Wochen. Denn damit haben alle Aufgaben ein Endtermin. In diesen Timeboxes fahren die Teams auf Sicht. Dies erlaubt den Teams „häppchenweise“ vorzugehen und sich iterativ an die Projektvision heranzuarbeiten. Dadurch ersparen sie sich unnötige Planungen und damit Zeit. Das heißt jedoch nicht, dass in einer Iteration oder einem sog. Sprint Zeit- und Geschwindigkeitsrekorde gebrochen werden sollen oder müssen. Es geht darum, die vorhandene Zeit möglichst effektiv zu nutzen, um den maximalen Mehrwert für den Nutzer des Produktes zu erzeugen.

Flexibilität

Innerhalb eines Projektes kann es zu Missverständnissen, Ausfällen oder Fehlern kommen. In klassischen Projekten kann dies erhebliche Konsequenzen mit sich führen. Dem wirken Agile Methoden entgegen. Durch kurze Iterationszyklen kann neuer Input innerhalb eines Projektes unmittelbar und flexibel durch das Team in der folgenden Iteration umgesetzt werden. Dies führt dazu, dass auf sich verändernde Prioritäten schneller eingegangen werden kann. Auf diese Weise erhält das Team mehr Kontrolle über den unmittelbaren Wertbeitrag der laufenden Iteration und kann ggf. die Anforderungen optimieren oder anpassen. Die ständige Kommunikation sowie das häppchenweise Vorgehen ermöglichen somit dem Team auf Änderungen innerhalb des Projektes ohne größere Probleme einzugehen.

Risikominimierung

Schlussendlich läuft alles auf ein erfolgreiches Projekt hinaus. Der Projekterfolg kann aber durch eingangs erklärte Veränderungen im Entwicklungsprozess gefährdet oder sogar ganz annulliert werden. Hier minimieren agile Methoden effektiv Risiken. Die große Angst am Ende ohne ein fertiges Produkt dazustehen, besteht bei einem agilen Projekt nicht. Durch die fest definierten Iterationszyklen wird dem Team ein regelmäßiger Liefertermin auferlegt, der ein funktionsfähiges Zwischenergebnis fordert. Mit jeder Iteration wird ein funktionsfähiges Teilergebnis geliefert. Mit jeder Lieferung reduziert sich das Liefer- bzw. Erfüllungsrisiko. Die regelmäßige Lieferung eines solchen funktionsfähigen (Teil-) Inkrements führt dazu, dass im Falle eines Ausfalls oder Fehlers innerhalb des Projektes das Team nicht wieder von Null anfangen muss. Dies führt zu einer erheblichen Senkung des erwarteten Risikos entlang dem Projektforschritt.

Welche Agile Methoden gibt es?

Design-Thinking

 Probleme aus Kundensicht

Design Thinking stammt ursprünglich aus dem Designer-Bereich. Im Ergebnis zielt die Methode auf die Entwicklung von Produkten oder Produktideen ab. Design Thinking ist das produkt- und marktorientiert. Vor allem müssen aber solche Produkte aus Anwender und Nutzersicht überzeugen, also überzeugende Lösungen für echte Probleme des Nutzers anbieten.

In den 1990er-Jahren wurde Design Thinking von 3 Standford Professoren entwickelt. Einer der 3 Professoren, David Kelly, gründete die internationale Design- und Innovationsagentur IDEO, welche Design Thinking als Methode anwendet und entscheidend geprägt hat. U.a. hat IDEO die erste Computermouse für Apple entwickelt. Die 3 Standford Professoren leitete aus ihren Erfahrungen Best Practice Leitsätze ab und fassten diese unter dem Begriff des Design-Thinking zusammen. Sie gründeten an der Universität Standford die „d.school“, welche später in das Hasso Plattner Institute of Design umbenannt wurde.

Im Vordergrund steht das Problem aus Kundensicht. Es geht darum, Produkte und Lösungen anzubieten, die gezielt einen bestimmten Kundenstamm ansprechen sollen, ohne dabei vorerst auf die Umsetzbarkeit und Wirtschaftlichkeit zu achten. Die Kunden sind daher klarer Fokus des Design Thinkings.

Basis von jedem Design Thinking Projekt ist ein Team mit unterschiedlichen Expertisen. Dies garantiert, dass Probleme in unterschiedlichsten Sichtweisen gesehen und angegangen werden können.

 

Der Design Thinking Prozess läuft so ab

Der Prozess wird auch als „doppelter Diamant“ bezeichnet lässt sich in mehrere Phasen unterteilen. Er startet mit der Design Challenge. Daraus wird mit dem Point of Views die Perspektive für die Entwicklung der Lösung festgelegt. Sowohl im Lösungs- als auch im Problemraum wird dabei zunächst sehr weit und offen gedacht, um möglichst viele Perspektiven zu sammeln. Später wird dann Schritt für Schritt auf dem jeweilige Ergebnis angenähert.

Im sog. Problemraum liegt der Fokus auf dem zu lösenden Problem. Er enthält die folgenden drei Phasen:

    • Beobachten: Zu Beginn wird der Wille des Kunden ermittelt. Die Gruppe muss sich in den Kunden hineinversetzen und seine Wünsche in den Vordergrund setzen. In diesem Rahmen kann ein Interview oder ein Rollenspiel sinnvoll sein. Entscheidend ist nur, dass die Gruppe aufmerksam zuhört, um Missverständnisse vorzubeugen.
    • Verstehen: Im nächsten Schritt soll die Gruppe Muster erkennen. Bei diesen kann es sich um Probleme, Informationslücken oder aber auch um Wünsche handeln. Diese Muster werden in Kategorien unterteilt und auf ihre Gemeinsamkeiten untersucht.
    • Sichtweise definieren: Es werden die Ergebnisse aus dem ersten und zweiten Schritt zusammengefasst, um einen Standpunkt (Point-of-View) zu definieren. Er ist der Ausgangspunkt für die Ideenfindung bzw. die für Lösungsfindung bei Design Thinking. Je schärfer der Point-of-view formuliert ist, desto besser werden die Ergebnisse der Lösungen entwickelt

An den Problemraum schließt sich dementsprechend der sog. Lösungsraum an. Im sog. Lösungsraum wird sukzessive die Lösung erarbeitet, getestet, verworfen und verbessert. Innerhalb dieses Raums erfolgen die folgenden Phasen:

    • Ideen finden: In diesem Schritt werden jegliche Ideen ohne irgendeine Wertung gesammelt. Anschließend werden die Resultate nach ihrer Priorität sortiert. Kriterien, wie Effizienz, Umsetzbarkeit, Wirtschaftlichkeit oder Vergleichbarkeit bei der Konkurrenz werden im Prozess der Priorisierung herangezogen. Denken Sie also „ja, und dann könnten wir noch X machen““ statt „ja, aber das geht nicht“.
    • Prototyp entwickeln: Nun wird ein Prototyp erstellt. Dieser soll weder perfekt noch vollendet sein. Er soll die Lösung des Problems des Kunden veranschaulichen können. Geeignete Techniken zur Erstellung eines Prototypen sind Storyboards, Modelle oder auch Post-Ist.
    • Testen: Im letzten Schritt müssen die Arbeitsergebnisse getestet werden. Hier ist das generierte Feedback von besonderer Wichtigkeit, da anhand dieses weitere Ideen und Verbesserungen entwickelt werden. Die Gruppe muss flexibel und offen für neuen Input sein. Es ist nicht unüblich mehrere Testphasen zu durchlaufen, bis eine Freigabe des Produkts durch den Kunden erfolgt.
Auch wenn die einzelnen Phasen vorstehend linear als serielle Sequenz beschrieben sind, die der Design-Thinking-Prozess genau das Gegensteil. Wie alle agilen Methoden ist er iterativ. Nach Jeder Phase werden die gewonnen Erkenntnisse reflektiert. Sofern es sich ergibt, dass für den Schritt in die nächste Phase wichtige Informationen fehlen, springt das Team in die Phase zurück, in der es diese Information sammeln kann. Beispiel: Beim Testen des Prototyps stellt sich die Frage, ob der Anwender groß genug ist, um eine Anzeige zu lesen oder den Prototyp richtig einzusetzen. Dann geht das Team wieder in die Phase „Sichtweise Definieren“ zurück, um diese Information zu erheben. Daher lässt sich der iterative Prozess mit seinen 6 Phasen und Rückkopplungen auch wie folgt darstellen:

Lean-Start-Up

Das Lean-Start-Up ist eine Methode, bei der ein Produkt möglichst „schlank“ entwickelt werden soll, bis es zum Erfolg kommt. Jede Idee für ein Produkt oder ein Start-Up gilt als eine unbewiesene Hypothese und damit als unsicher, bis sie empirisch validiert worden ist. Mit anderen Worten: In der Praxis gehe ich wegen der hohen Unsicherheit kleinschrittig und ressourcensparend vor. Als erstes stecke ich als Start-Up daher Zeit und Ressourcen in den iterativen Aufbau von Produkten oder Dienstleistungen, um die Bedürfnisse früher Kunden zu erfüllen und Marktrisiken zu reduzieren. Dadurch reduziert sich der Bedarf umfangreicher, anfänglicher Projektfinanzierung und teuren Produkten. In die Skalierung des Produktes und es Modells steigt das Start-Up erst ein, wenn der Beweis dafür vorliegt, dass das Produkt erfolgsversprechend ist, wenn also alle erfolgskritischen Hypothesen validiert worden sind. Ist der Verlust zu hoch oder die Umsetzung nicht sinnvoll, dann kann ohne Weiteres eine andere Produktidee umgesetzt werden.

Kernessenz ist hierbei, sich nicht mit langwierigen Entwicklungsprozessen zu belasten und das Produkt zu detailliert zu konzipieren. Überprüfung der Hypothese soll möglichst schnell und kostengünstig erfolgen. Daher legt das Start-Up mit einer groben Idee los und tastet sich kleinschrittig (ergänzt durch das Feedback des Kunden) an das Produkt bzw. Geschäftsmodell heran. Frei nach dem Motto: „Nicht reden, machen!“.

Beispiel: Fitnessstudio nach Lean-Start-Up

    • Sie merken, dass die Menschen in einem Finanzdistrikt sehr gestresst sind
    • Ihre Lösung/Produktidee: Ein Fitness- und Entspannungscenter fürs Gemüt!
    • Dafür müssten Sie Räume anmieten, Trainer einstellen, Geräte anschaffen, Verträge abschließen und vor allem: Marketing betreiben! Das alles, ohne zu wissen, ob es überhaupt das Richtige ist. Sie gehen enorme Risiken ein.
    • Besser: Führen Sie Umfragen/Interviews o.ä. in dem Distrikt durch, um überhaupt herauszufinden, ob Ihre Idee überhaupt Anklang finden würde
    • Falls ja: Jackpot! Sie haben Ihre Hypothese bewiesen. Alle erfolgskritischen Annahmen waren korrekt. Sie beginnen die Umsetzung, dass das Produkt/Geschäftsmodell trägt.
    • Falls nein: Finden Sie eine andere Lösung und versuchen es nochmal! Fail fast! Fail cheap!

Diese Methode ist besonders bei Start-Ups beliebt, da mit wenig Ressourcen und Mitteln, viele Erkenntnisse und sogar Erfolge erzielt werden können. Auch Unternehmen, wie Twitter oder Dropbox sind mit der Lean-Start-Up Methode groß geworden. Ein gutes Beispiel für die angewandte Lean-Start-Up-Methode, der vermehr im Intrapeneur-Bereich Anwendung findet ist die Adobe Kickbox.

SCRUM

SCRUM als agiles Modell

Die bekannteste agile Methode ist SCRUM. Es benutzt ebenfalls einen iterative Ansatz. Der erste Konferenzbeitrag zur SCRUM wurde im Jahr 1995 durch Jeff Sutherland und Ken Schwaber veröffentlicht. Daraus hat sich sukzessive Scrum als Projektmethode entwickelt. Die SCRUM-Guidelines werden stetig weiterentwickelt und auf scrum.org aktualisiert.

SCRUM ist ein leichtgewichtiges Framework. Bei Scrum geht es darum, dass ein Team in mehreren Iterationen, sog. „Sprints, funktionierend Produktinkremente entwickelt. Mit jedem Sprint nähert sich das Team Schritt für Schritt dem Endprodukt.

Diese grobe Erklärung von SCRUM gibt eine erste Idee. Sie umfasst jedoch nicht das ganze Framework mit allen Details. SCRUM besteht im Kern aus 3 Rollen (Accountabilitites), 5 Ereignissen (Events) und 3 Artefakten (Artefacts).

Die Rollen im SCRUM

Im SCRUM gibt es keine Hierarchie. Jede Rolle ist für die Erfüllung Ihrer Aufgaben selbst verantwortlich. Daher ist wichtig verschiedene Rollen und Ihre Aufgaben zu unterscheiden und zu leben:

    • Der SCRUM Master ist der „Hüter der Methode“ während des ganzen Prozesses. Er ermöglicht dem Team bestmögliche Arbeitsergebnisse zu erzielen, indem er auf die Umsetzung der Methode achtet und etwaige Hindernisse aus dem Weg räumt. Der SCRUM-Master sorgt für die Einhaltung der agilen Prinzipien und stellt sicher, dass sein Team nicht von äußeren Einflüssen negativ beeinflusst wird.
    • Der Product Owner ist der „Anwalt des Produkts“. Er ist die Person, die dafür sorgt, dass das Team das wertvollste Produkt schafft, das es schaffen kann. Er definiert die Produkt Idee und beschreibt die notwendigen Funktionalitäten. Diese hält er als User Stories im sog. „Product Backlog“ fest. Um den besten Wertbeitrag zu erreichen, priorisiert er das Product Backlog und stellt dem Team vor, welche Funktion er als nächstes im Produkt braucht. Er entscheidet am Ende vom Sprint auch, ob das Team die Funktion geliefert hat. Er kann jedoch nicht vorgeben, welche Aufgabe das Team innerhalb des Sprints erledigen soll.

Das Team besteht aus einer festen Anzahl an Personen, die für die Erledigung der Aufgaben eingeteilt wurden. Der Product Owner stellt dem Team das priorisierte Product Backlog vor. Das Team entscheidet selbständig und nach eigenem Ermessen, welche und wie viele Aufgaben in einem Sprint erledigt werden können. Diese Aufgaben werden dann im „Sprint Planning“ als machbar festgehalten. Das Team arbeitet dabei nach dem „Pull-Prinzip“. Das heißt, es entscheidet nach eigenem Ermessen welche Aufgaben es als machbar innerhalb des Sprints einschätzt und verpflichtet sich zu deren Lieferung.

Sind die Rollen besetzt, kann die Arbeit beginnen. Dabei läuft folgender Prozess ab:

    • Innerhalb von iterativen Sprints (Dauer z.B. 2 Wochen) werden die von dem Team ausgewählten Aufgaben (User Stories) umgesetzt. Dazu bricht das Team die User Stories in einzelne Aufgaben herunter.
    • Während des Sprints organisiert sich das Team im „Daily“ oder „Daily SCRUM“. Dort tauscht sich das Team untereinander über den Fortschritt austauscht und gibt sich Hilfestellung.
    • Der SCRUM Master achtet darauf, dass das Team die Regeln des SCRUM Frameworks befolgt und die agilen Prinzipien einhält. Sollten Hindernisse entstehen, gehört es zu seinen Aufgaben, die sog. Impediments zu beseitigen. Das Team soll seine beste Leistung erbringen und sich voll auf die Umsetzung der User Stories konzentrieren können.
    • Nach jedem Sprint wird dem Product Owner im Sprint Review vorgestellt, was vom Team umgesetzt wurde.
    • Der Product Owner prüft, ob die zu User Stories des Sprints entsprechend der Akzeptanzkriterien und der sog. „Definition of Done“ umgesetzt wurden. Erachtet er User Stories als nicht erledigt, werden diese zurück in das Product Backlog gelegt. Wurden die Aufgaben hingegen zufriedenstellend erledigt, nimmt der Product Owner diese als „done“ ab.
    • Die Sprint Retroperspective ist der Haltepunkt zum Reflektieren des Sprints. Das Team überlegt, wie an welchen Stellen Probleme aufgetreten sind und entwickelt Ansätze wie diese Probleme im nächsten Sprint behoben werden können. Es ist das Element zum organisationalen Lernen, zur Verbesserung des Teams. Denn ohne Lernen und stetige Verbesserung kann sich kein Hochleistungsteam entwickeln oder halten.
    • Am Ende des Sprints steht ein fertiges Produkt bzw. ein potenziell, auslieferbares Produktinkrement. Alle geleiferten Inkremente zusammen ergeben über die erbrachten Sprints hinweg das Produkt.

Kanban

Der Begriff Kanban

Eine weitere agile Herangehensweise bietet die sog. Kanban-Methode. Ursprünglich aus dem Japanischen und bedeutet Karte. Es wurde bereits 1947 von Toyota eingesetzt. Heutzutage wird Kanban auch in anderen Branchen erfolgreich eingesetzt.

Bei Kanban geht es darum, mithilfe eines sog. Kanban Boards, den Arbeitsprozess eines Teams zu visualisieren. Dies ermöglicht einen genauen Überblick über den Workflow eines Teams, dessen Analyse und iterative Verbesserung. Der „Flow“ durch das System wird ständig angepasst und verbessert. Der Zustand eines perfekten „Flows“ wird zwar angestrebt ist aber nicht erreichbar. Denn die äußeren und inneren Faktoren verändern sich ständig.

Die Teammitglieder ziehen die Aufgaben bei freier Kapazität jeweils in Ihren Arbeitsbereich bzw. in den nächsten Prozessschritt (Pull-Prinzip). So werden die Aufgaben Stück für Stück abgearbeitet. Dabei geht es darum, erst die begonnene Aufgabe zuerst fertigzustellen. Erst danach kann bei freigewordenen Kapazitäten eine neue Aufgabe begonnen (quasi „heranzuziehen“). Dies verhindert Multitasking und die damit verbundenen „Rüstzeiten“.

Die Visualisierung von Kanban

Dabei visualisiert ein Kanban-Board den ganzen Prozess (End-to-End-Sicht). Das erleichtert dem Team, den Überblick zu behalten und sich nicht im operativen Geschäft zu verlieren. Das Board selbst ist in verschiedenen Spalten, den unterschiedlichen Arbeitsprozessen, unterteilt (wie „Backlog“; Work in Progress“; „Testing“ „Done“). Wichtig ist dabei, dass  innerhalb der Spalten gewisse Limits (Work in Progress Limits) aufgestellt werden, um der Übersichtlichkeit nicht zu schaden. Erst wenn es das Limit erlaubt, werden Aufgaben aus der vorherigen Spalte „gezogen“.

Stück für Stück arbeiten Sie die Aufgaben ab und garantieren so, dass am Ende eines Prozesses fertige Produkte statt unvollständiger Teilprodukte entstehen.

Takeaway

Nehmen Sie hinsichtlich Kanban folgende 5 Punkte mit:

    • Visualisierung: Das Kanban-Board veranschaulicht Ihren Arbeitsprozess.. Sie entscheiden, welche Gestalt das Board annimmt. Sorgen Sie also dafür, dass es übersichtlich und verständlich aufgebaut ist. Ein Board, welches überflutet wird mit Farben, Formen und Schriften sorgt genauso für Chaos, wie gar kein Board.
    • Kapazitäten: Kanban dient dazu, Aufgaben schrittweise abzuarbeiten und fertigzustellen. Dies kann jedoch nur gelingen, wenn der Fokus darauf gesetzt Aufgaben erst fertigzustellen bevor neue begonnen werden. Also „Stop starting, start finishing“. Sorgen Sie bei Engpässen daher dafür, dass innerhalb der Arbeitsschritte Limits gesetzt werden, um nicht den Fokus zu verlieren und die Ressourcen nicht zu überlasten (Work-in-Progress-Limit oder WIP-Limit).
    • Feedback: Kanban lebt von Veränderungen. Tauschen Sie sich innerhalb des Teams über Erfolge, Misserfolge und Verbesserungsmöglichkeiten aus. Es geht nicht darum von Anfang an Perfektionismus anzustreben, sondern darum, sich stetig zu verbessern. Bauen Sie daher regelmäßige Möglichkeiten zur Retrospektive und Analyse ein!
    • Nehme Sie ihr Team mit: Starten Sie mit Ihrem Prozess und nicht mit dem Prozess einer anderen Organisation. Denn Sie wissen weder, wo die andere Organisation steht, noch haben Sie das gleiche Team oder die Rahmenbedingungen.
    • Management: Natürlich darf die Person nicht fehlen, die einen geschmeidigen Workflow garantiert. Während sich das Team um die eigentlichen Aufgaben kümmert, sollten Sie eine Person beauftragen, die bei Fragen und Problemen weiterhelfen kann und auch den Überblick über das Board behält.

Liberating structures

 Alles andere als Spielerei

Feedback, Diskussionen und Meet-Ups sind wichtig, um agil richtig durchstarten zu können. Es kann jedoch vorkommen, dass ebendiese Treffen nicht zielführend sind, weil sich das Team nicht ausreichend beteiligt. Es mangelt an cleveren Ideen und konstruktiven Wortbeiträgen, am Ende ist das Team genau so schlau, wie vorher.

Die Idee von Liberating Structures ist daher so simpel wie genial: Es handelt sich bei dabei um eine Zusammenstellung von vielen (insgesamt 33) Arbeitsmethoden, eine Werkzeugkiste für bessere Entscheidungsfindungen. Mit einem Zeitaufwand von 15 Minuten bis zu mehreren Stunden sind dort eine Bandbreite von kombinierbaren Strukturen enthalten, um Meetings zielgerichtet zu gestalten. Das Team soll von gesetzten Hierarchien und Kontrollen befreit werden (deshalb auf Deutsch „befreiende Strukturen“), um sein Potential auszuschöpfen. Die Teilnehmenden werden motiviert, in einer freien Umgebung aktiv zu werden und mitzuarbeiten. Das sorgt wieder für frischen Wind in den nächsten Meetings und auch zu Motivationssteigerung bei den Teammitgliedern.

Es handelt sich jedoch nicht um bloße Kennenlernspiele oder kurze Fitnesseinheiten. Liberating Structures haben Bezug zu den Themen, sie sind lösungsorientiert. Der in der App enthaltene Matchmaker spart dabei nicht nur Zeit, sondern auch Nerven!

Was muss ich bei liberating structure beachten?

Probieren Sie sich an einer dieser Methoden aus! Wir setzen z.B. 1-2-4-all gerne zur Erarbeitung von Ergebnissen in Gruppen. Liberating Structures enthalten einfache Schritt-für-Schritt-Anleitungen, mit denen Sie direkt durchstarten können. Die Kurzbeschreibung erklären wofür die Structure am besten geeignet ist.

Der Vorteil: Es erfordert keine umfangreiche Umstrukturierung oder ein gesondertes Meeting. Mit einer kurzen, moderierten Einführung (vielleicht auch ein Infoflyer vor dem Meeting) holen Sie alle Teammitglieder ab und helfen Ihnen ihr potential freizusetzen. Machen Sie sich dabei folgende Gedanken:

    • Haben Sie das Meeting geplant und die nötigen Personen eingeladen? Gibt es bereits ein Gesprächsthema?
    • Was benötigen Sie für das Meeting an Materialien, Zeit und Kapazitäten?
    • Wie wollen Sie die Teilnehmenden in das Meeting einbinden?
    • Wie soll das Meeting strukturiert sein? Wie lange soll es insgesamt dauern? Wie viel Zeit benötigen Sie?

Die kostenfreie LISA-App mit Match-Maker und Workshop-Kompagnon können Sie hier herunterladen.

DevOps

Aus 2 mach 1

DevOps ist ein Kunstwort. Es setzt sich aus Development (Entwicklung) und Operations (Vorgänge) zusammen. Besonders im IT-Bereich wird das DevOps-Modell wirkungsvoll eingesetzt. Je nach Ergänzung um Fachprozesse (Business = Biz) oder Sicherheitsprozesse (Security = Sec) gibt es auch BizDevOps oder DevSecOps. Ziel ist es, Softwareprodukte schnell und effizient zu entwickeln sowie sicher zu betreiben. Dazu arbeiten Entwicklung, Betrieb sowie ggfs. andere Bereiche eng und kontinuierlich zusammenarbeiten. Jeder zieht dabei am gleichen Strang!

Dies fängt bereits mit der richtigen Unternehmenskultur an. Die Teams arbeiten mit hoher Transparenz zusammen. Sie legen untereinander Pläne und Prioritäten offen. Alles zum Wohle der schnellen Anpassung und dem stabilen Betrieb der Software.

Bei einem größeren Team sollte auch eine klare Rollenverteilung nicht zu kurz kommen. Legen Sie fest, welche Person für welchen Bereich zuständig ist. Erweitern Sie gegebenenfalls diese Zuständigkeiten, wenn es die Situation erfordert. Machen Sie sich klar: Jedes Teammitglied ist immer für irgendetwas zuständig. Die Arbeit des Teams ist nicht erledigt, sobald die zugewiesene Arbeit eines Beteiligten erledigt wurde! Es ist ein stetiger Prozess, der die Aufmerksamkeit aller erfordert.

Deswegen DevOps

Das hat den Vorteil, dass dadurch die „Time-to-Market“-Zeit, also die Produkteinführungszeit“ verringert wird. Damit geht einher, dass Sie dadurch flexibler auf Marktänderungen oder Kundenwünsche eingehen können.

Fehlschläge sind dabei nicht auszuschließen, sollten jedoch nicht falsch interpretiert werden, Stichwort „Fail fast, fail cheap“: Lernen Sie aus Fehlern und integrieren Sie die daraus gewonnene Erkenntnis in ihre Prozesse. Nur so verbessern Sie Ihre Produkte und Ihr Team. DevOps ist kein abschließender Prozess, sondern eine Reise, begleitet von Erfolgen und Misserfolgen.

Wenn Sie über eine DevOps-Kultur hinausgehen wollen, dann können Sie diese durch verschiedene DevOps-Methoden (wie Continiuous Monitoring; Agile Softwareentwicklung oder Infrastruktur als Code) anwenden.

Lean

Das Kernprinzip von Lean ist „Waste-Reduction“. Die vorhandenen (knappen) Ressourcen möglichst gezielt und sparsam einsetzen, nur so viel, wie nötig. Das heißt aber nicht, dass Sie einen strengen Sparkurs fahren müssen. Es hießt nur, dass Sie das Input-Output Verhältnis im Blick behalten.

Bekannt wurde diese Methode (wieder) durch Toyota. Die Ressourcen und Landknappheit in der japanischen Nachkriegszeit ließen ein Umdenken nicht lange auf sich warten. Jeder einzelne Mensch, jedes Gut und jeder Schritt war wichtig im Produktionsablauf und musste so effizient wie möglich eingesetzt werden, ohne dabei Abstriche bei der Qualität machen zu müssen. Dabei muss der Prozess weiterhin kundenorientiert sein.

Eine schlanke Produktentwicklung war gefragt. Es wurde hinterfragt:

    • Brauchen wir das wirklich?
    • Wie kann ich eine Verschwendung verhindern?
    • Werfen Sie einen kritischen Blick auf Ihre Geschäfts- und Produktionsabläufe und filtern Sie das Wesentliche heraus.

Das Gute an Lean: Sie können es auch mit anderen agilen Methoden, wie Kanban kombinieren.

Zwar fußt Lean auf das Logistik- und Produktionsmanagement, es wird mittlerweile auch in weiteren Branchen eingesetzt. Vermehrt ist es daher z.B. im Projekt-, Prozess- und Qualitätsmanagement zu finden. Doch auch im Büroalltag können Sie „lean“ denken, indem Sie auf Zeitfresser achten und diese vermeiden.

Fazit und Navigationshilfe:
Welche Methode ist für mein Projekt richtig?

Diese kleine Aufzählung zeigt es: Agile Methoden zielen auf eine effektivere Herangehensweise bei Projekten im komplexen Bereich ab. Wenn Sie geklärt haben, dass ein agiles Vorgehen für Ihr Projekt Sinn ergibt, bleibt die Frage, welche Methode konkret in Betracht kommt. Dabei steckt der Teufel im Detail. Jede einzelne Methode ist anders und abhängig davon, welchen Nutzen Sie ziehen wollen.

Wir erinnern uns an die Stacey-Matrix am Anfang dieses Beitrags. Stellen Sie sich für die Auswahl der richtigen Methode folgende Frage: Wo befinden Sie sich in der Stacey Matrix? Mit welcher Unsicherheit hinsichtlich Anforderungen und Technologie bzw. Methode setzen Sie Ihre Projekt um?

Es erleichtert Ihnen die Suche nach einer geeigneten agilen Methode, wenn Sie Ihr Projekt auf der Stacey Matrix verorten.

Ist Ihr Projekt mit sehr unscharfen Anforderungen zu charakterisieren und die Methode der Umsetzung noch völlig unklar, so befinden Sie sich im sehr komplexen oder sogar im chaotischen Bereich. Hier gibt es kaum bis gar keine vorhersehbaren Vorgänge. Die Situation ist „offen und lebendig“, also ständig den äußeren Einflüssen ausgesetzt. Hier empfiehlt es sich mit Design-Thinking  eine Basis zu legen. Mit der kundenorientierten Herangehensweise, besonders die Charakteristik vom Problem zur Lösung hinzuarbeiten, ohne ein klares, vorher definiertes Ziel zu verfolgen, hilft Ihnen eine klare Vision und eine erstes Backlog von Funktionalitäten zu entwickeln. Vielleicht sind Sie mit Ihren bisherigen Endprodukten nicht zufrieden und fragen sich „Wie kann ich es anders machen?“. Auch hier kommt Ihnen die Design-Thinking-Methode zugute.

Sind Sie im sehr komplexen Bereich könnte auch Lean (Start-Up) Abhilfe schaffen. Insbesondere können Sie damit sukzessive Ihre Hypothesen validieren und Ihr Produkt entlang des Marktfeedbacks entwickeln.

Vielleicht haben Sie bereits eine klare Vision für Ihr Produkt und erste Funktionalitäten für Ihr Backlog. Dann wäre sicher SCRUM eine gute Wahl, um durch den komplexen Bereich navigieren. Bei großen Projekten mit SCRUM könnte ein Blick auf Skalierungsansätzen wie LeSS, Nexus, SAFe oder Scrum of Scrums (Scrum@Scale) arbeiten. Wichtig für die Skalierung ist aber nicht nur die Wahl des Frameworks sondern auch wie die Skalierung durchgeführt wird. Also fangen sie auch hier klein an und lernen Sie. So kommen Sie Schritt für Schritt Ihrem Endprodukt näher.

Ähnlich ist es auch bei DevOps. Hier führen Sie die Teams von Entwicklung und Betrieb zusammen und sorgen für einen direkten Austausch untereinander.

Schließlich kann es auch sein, dass Ihr Projekt weitaus sicherer bzw. klarer ist. Sie befinden sich am Übergange vom komplexen zum komplizierten Bereich. IEs gibt bereits vorhandene Variablen und Prozesse, an die man sich orientieren kann. Die Ursache-Wirkung-Verbindung sind klarer. Die Kanban-Methode kann dann die Methode der Wahl sein. Durch kleinschrittige und klare Arbeitsschritte können Sie sich an den vorhandenen Variablen orientieren und dabei stets den Überblick behalten.

Ebenfalls im Übergang zwischen komplex und kompliziert aber auch im nur komplizierten Bereich ist Lean eine gute Wahl. Hier steht das Ressourcenmanagement im Vordergrund, insbesondere, wenn Sie Ihr Input-Output-Verhältnis verbessern wollen, ohne direkt das Endprodukt verändern zu müssen.

Wie Sie sehen, gibt es nicht DIE eine agile Methode, um Erfolge zu garantieren. Ebenso wenig gibt es DAS agile Projekt. Vielmehr ist es eine Bedürfnisfrage. Wie ist Ihre Situation? Wie erfahren mit agilen Methoden sind Ihre Mitarbeiter? Sind Sie und Ihr Unternehmen bereit für agile Herangehensweisen? Wo ist Ihr Ansatz? Was wollen Sie erreichen? Diese Zusammenfassung ist nur die Spitze des Eisbergs. Daneben gibt es noch weitere agile Methoden, maßgeschneidert für die unterschiedlichsten Situationen.

Natürlich müssen Sie bei der Beantwortung dieser Fragen nicht im Dunkeln tappen. Auch wir waren wohl schon einmal dort, wo Sie sich eventuell jetzt befinden – kommen Sie also gerne auf uns zu! Wir unterstützen Sie gerne, insbesondere bei Ausschreibungen, Verhandlungen und Vertragsgestaltungen von agilen Projekten.

Kristian Borkert

Kristian Borkert

Autor

Kristian Borkert ist Gründer der JURIBO Anwaltskanzlei und hat sich insbesondere auf den Bereich IT, Wirtschaftsrecht und Datenschutz spezialisiert.

Sie brauchen rechtliche Unterstützung? Kontaktieren Sie uns für eine kostenlose Erstberatung oder rufen Sie uns an.