Einleitung

Agil ist nach wie vor in aller Munde und SCRUM als agiles Projektmanagement Rahmenwerk neben Kanban bereits relativ gut bekannt. Doch sehr häufig werde ich gefragt ob SCRUM/Kanban nicht ausschließlich etwas für die Softwareentwicklung ist und wie können man agile Prinzipien in eine Nicht-IT Organisation überführen?

Zunächst empfehle ich eine kleine Einführung in SCRUM und Kanban:

Zum Einstieg: SCRUM und Kanban

An einer kurzen Vorstellung von SCRUM kommen wir nicht vorbei um deutlich zu machen woher viele Erkenntnisse über die Wirkungsweise von agilem Arbeiten kommen. Wer sich das sparen möchte, liest im nächsten Abschnitt weiter.

SCRUM ist zunächst ein Rahmenwerk und keine Methode – wobei bei einem Rahmenwerk viel Raum für verwendete Praktiken und Tools gelassen wird – wird bei einer Methode die zu verwendenden Werkzeuge zum erreichen der Ziele „vorgeschrieben“. Scrum ist an sich einfach zu verstehen, es hat wenige Rollen, Events und Artefakte. Verschaffen wir uns einen kurzen Überblick.

 

SCRUM_Prozess

 

Die wichtigsten Kernaussagen zu SCRUM: SCRUM…

  • …dient dazu „komplexen Projekte“ zu managen. Und Komplex bedeutet das man eben nicht in der Lage ist das Projekt von Anfang bis Ende zu planen und steht damit im Gegensatz zur Wasserfall-Planung.
    • komplex = probieren – erkennen – reagieren
  • …ist ein iteratives Vorgehensmodell (in sich wiederholenden Schleifen – schrittweises vorgehen…)
  • …ist ein inkrementelles Vorgehensmodell (Lieferung erfolgt in funktionstüchtigen Teilen)
  • …ist Transparent durch ein ständiges Inspect & Adapt (Anschauen und Anpassen)
  • …hilft dabei Fehler frühzeitig zu erkennen, indem Fehler gemacht werden.
  • …ist ein Kontinuierliche Verbesserungs Prozess (KVP = DEMING-Cyle) durch die Integration entsprechender Praktiken wie Retrospektiven, Daily Scrum und das führen sogenannter Impediment-Listen (Hindernis/Störungsliste) wobei der KVP sowohl den Prozess als auch das Produkt anbelangt.
  • …stellt das selbstorganisierte Arbeiten (und Lernen) in das Zentrum.
  • Die Kommunikation läuft insbesondere face to face ab (entsprechende Events stehen zur Verfügung)
  • …bringt 3 Rollen mit sich: Product Owner (Produktverantwortliche), SCRUM Master (der Hüter des Prozesses) und das Team (selbstorganisiert)
  • …hat 3 Artefakte: Product Backlog (alle Anforderungen Priorisiert), Sprint Backlog (Anforderung für den nächste Iteration) und den Burndown Chart (Visualisiert der in in Abhängigkeit von Zeit geschafften/entwickelten Anforderungen)
  • …enthält folgende Events: Sprint Backlog Meeting 1 und 2, Daily Stand Up (15 Min), Sprint Retrospektive (pro Woche Entwicklungszeit etwa 1 Stunde Dauer), Sprint Reviews (Am Ende des Sprints wird das fertige Produkt-Inkrement dem Kunden präsentiert)

zusammenfassend kann man kurz sagen es geht vorallem um:

  • Menschen & Kommunikation
  • Schnelle hochwertige Produktlieferung
  • Kundenorientierung
  • Wertschöpfung

Dazu sollte man sich noch einmal die agilen Prinzipien vergegenwärtigen denen auch SCRUM folgt. Als da wären:

  1. Den Kunden zufrieden stellen
  2. Änderungen willkommen heißen
  3. Häufige Auslieferung
  4. Crossfunktionale Zusammenarbeit
  5. Unterstützung leisten und vertrauen schenken
  6. Direkte persönliche Kommunikation
  7. Funktionierende Software (hochwertige Produkte)
  8. Streben nach (technischer) Exzellenz

Im folgendenden widme ich mich den wichtigsten Kernaussagen zu Kanban, hier beginnen wir einmal mit den Prinzipien von Kanban:

  • Beginne dort wo Du dich momentan befindest
  • Einige Dich mit Anderen auf evolutionäre Veränderungen
  • Respektiere initial Prozesse, Rollen, Job-Titel und Verantwortlichkeiten
  • Sorge für Leadership

Entsprechend dazu sind erwähnenswert die Kanban-Praktiken, die sehr griffig wirken und pragmatisch sind:

  • Visualisiere
  • Limitiere den „Work in Progress“
  • Messe und Manage den Flow
  • Mache Regeln explizit (Wie lange wollen wir StandUps, Retrospektiven etc. durchführen?)
  • Implementiere Feedbackloops (Retrospektiven und Reviews)
  • Verwende Modelle

Agiles Arbeiten – 3 agile Praktiken, 3 mal 100% Nutzen für mehr Produktivität im Office

Bei der kurzen Vorstellung von Scrum und Kanban (in aller Kürze) geht es insbesondere darum noch einmal den Kontext deutlich zu machen in dem agile Praktiken eingesetzt werden bzw. wo diese Ihre Wirkung entfalten. Um die Eingangs angesprochene Fragestellung noch einmal aufzunehmen – es geht immer häufiger also nicht nur in der Softwareentwicklung darum wie agile Werkzeuge nutzen stiften können, nein – agile Methoden, Praktiken und auch agile Werte werden immer mehr auch dahingehend hinterfragt – wie können wir in unserem Unternehmen davon profitieren, wie können wir „agiler“ werden?  Ganz bewusst/unbewusst begibt man sich da genau auf den richtigen Weg – der Beginn und Übergang zur agilen zu einer „agileren“ Organisation.

So habe ich in einer meiner letzten Beratungen einem kleinen Unternehmen mit 3 agilen Praktiken echten Mehrwert stiften können ohne das sonderlich viel Aufwand gewesen wäre.

  1. Das Kanban-Board – visualisieren, visualisieren, visualisieren

Machen Sie Ihre Arbeit sichtbar. Nichts ist hinderlicher als immer wieder in irgendwelchen Online-Tools nach Tickets fahnden zu müssen, die Aufgaben im CRM sind dann wieder nur vertriebsbezogen, na ja und nicht zu vergessen das Selbstmanagement macht ja jeder mit seinem eigenen Methode und sind wir ganz ehrlich so können mit Mails heute immer noch weniger Leute souverän umgehen als es gut wäre. Kurz: Wie kann man die Aufgaben im Office nicht nur transparent machen, nein man erhält darüber hinaus viele nützliche Informationen dazu? Mit einem Kanban-Board – ja richtig gehört!

physical_scrum_board2

Beispielsweise erhält man ein gutes Gefühl über die Bearbeitungsdauer einer Aufgabe/Tasks. Die Aufgaben kann man bsp. auf Stattys schreiben (die halten statisch an der Wand) Weiterhin bekommt man endlich auf einen Blick ein gutes Gefühl wieviel noch zu tun ist, dabei einfach die Tickets der größeren Projekten mit eindeutigen Farben versehen und man sieht quasi auf einen Blick wer an was arbeitet und mit welchem Status! Viel schöner ist am Ende der Woche die Spalte „Done“ die dann am Freitag Nachmittag gerne auch mal gefeiert werden darf. Und zu guter letzt, kann man an so einem „Board“ die täglichen Daily-StandUp-Meetings anhand der relevante Tickets und Aufgaben herrlich kurz halten. Daily StandUp – was ist das jetzt gleich wieder?

  2. Daily StandUp

Jeden Morgen trifft sich das Team für 15Min. – na ja es wurden sicherlich schon mal 30 Min. – um sich vor der großen weißen Wand (die fix in ein Kanban-Board umfunktioniert wurde) einen Überblick über den aktuellen Tag zu verschaffen. Am Anfang war es gar nicht so einfach alte Gewohnheiten abzulegen und die Meetings sind Anfangs recht lang geworden. Sehr positiv wurde bewertet das nicht nur  deutlich sichtbar wird was ansteht, nein – man hat auch das Gefühl endlich zu wissen was die Kollegen alles so treiben. Gut informiert in den Tag ist neben dem Team auch der Chef und der hört plötzlich viel öfter auch mal zu, was die Kollegen zu berichten haben. Zugegeben am Anfang war es nicht leicht die Spielregeln festzulegen und einzuhalten. Beispielsweise die Spielregel, daß keine Probleme diskutiert werden sondern lediglich der Status einer Aufgabe angegeben wird. Das war schon eine echte Hürde. Irgendwann hat das Team dann tatsächlich die 3 Fragen beantwortet: „Was hast Du seit gestern geschafft/gemacht/bearbeitet?“, „Was hat dich gestört/behindert oder sogar genervt?“,“Was wirst Du heute tun?“

   3. Retrospektiven – Mit Fehlern lernen

In wievielen Abteilungen, Büros und Agenturen habe ich beobachten können, das im Vergleich zum gesamten Kommunikationsaufkommen man relativ wenig ergebnisorientiert kommuniziert. Also Status-Meetings ok – das ist man gewohnt – Mitarbeitergespräch mit dem Vorgesetzten und natürlich unterhält man sich in der Cafeteria mit den Kollegen über die Missstände und/oder schlecht bis mäßig laufenden Projekte. Bei Projekten ist ja meistens alles recht gut durchorganisiert, zielorientiert… Aber halt! Was hat man eigentlich aus dem letzten Projekt gelernt, mitgenommen? Wieviel wurde dokumentiert und wieviel wurde darüber gesprochen was gut lief und/oder was schlecht lief. Gesprochen? Oder gar ausgewertet? Wahnsinn das geht? Also ich bin immer wieder erstaunt das Projektauswertungen, wenn Sie überhaupt statt finden am Ende des Projekts so ablaufen wie Sie ablaufen. Langatmig, umfangreich und häufig wird man das Gefühl nicht los – irgendeiner wird gesucht der „Schuld“ sein muss. Wichtig wäre doch die Frage: „Was haben wir gelernt – was wollen wir beim nächsten mal besser machen?“

Retrospektiven sind eine Möglichkeit es besser zu machen. Sie werden wöchentlich oder zweiwöchentlich durchgeführt, das ganze Team ist mit an Board. Man geht in einen eigenen Meeting-Raum dafür, alles ist vorbereitet – belegte Brötchen – etwas zur trinken – 8-10 Leute. Dann geht es los. Im Kern geht es darum das jeder Mitarbeiter die Möglichkeit besitzt 4-5 Post-Its zu den folgenden Perspektiven zu schreiben:

  • Was sollen wir beibehalten?
  • Was sollten wir ab sofort lassen?
  • Was möchte ich positiv hervorheben?
  • Was ist mir negativ im Gedächtnis geblieben?
  • Wovon mehr?
  • Wovon weniger?

Jeder hat also die Möglichkeit sich mit 5 Post-Its in den entsprechenden Feldern mit seiner Beobachtung zu positionieren. Zu Beginn wurde die Retrospektive auf vielfachen Wunsch anonym durchgeführt. Gemeinsam hat man aber recht schnell festgestellt, dass man keinerlei Konsequenzen fürchten muss – wenn das Feedback möglicherweise zu negativ ausfällt. Im Gegenteil – irgendwann wollten alle mitwirken und zwar namentlich weil Sie festgestellt haben, das so wirkungsvoll an den Problemen gearbeitet wurde die ja schließlich alle angehen. Am Ende hat man ganz konkrete Aufgaben  verteilt um die „Probleme“ zu beseitigen. So wurden beispielsweise einige überflüssige Meetings beseitigt und das Beste – eine offene, respektvolle, konstruktive Atmosphäre geschaffen bei der die Mitarbeiter das gute Gefühl hatten Ihre Erfahrung in den Projekten dazu nutzen zu können, auch sehr direkt an den Verbesserungen mitwirken zu können.

1 Comment

Schreibe einen Kommentar

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

%d Bloggern gefällt das: