Techniken für IT-lastiges (?) Projektmanagement im Vergleich.
von Elisabeth Göhring
Scrum und Kanban sind intelligent konstruierte IT-Projektmanagement-Systeme, die sich aber auch in anderen Bereichen einsetzen lassen.
Die Techniken sind in der IT-Welt nichts Neues mehr. Man kann also gespannt sein auf die Bewertung derer, die diesbezüglich Erfahrungen machen konnten.
Zunächst zu Scrum:
Das ist ein Regelsystem, das aus der agilen Entwicklerszene, namentlich von Ken Schwaber und Jeff Sutherland, stammt. Kundenwünsche und Nutzerbedürfnisse werden so beschrieben und zerlegt, dass sie in einer Sammlung von abschätzbaren Aufgaben katalogisiert werden können. Diese Aufgaben werden dann in Abhängigkeit von ihrer Dringlichkeit in überschaubaren Zeiträumen abgearbeitet.
Jeder dieser überschaubaren Zeiträume wird Gegenstand von gepflegter Reflexion, so dass eine stetige Verbesserung und das Eingehen auf Veränderungen gewährleistet sind.
Bei Scrum gibt es nicht nur die Regeln, sondern auch besondere Rollen: den Productowner, der den/die Kunden repräsentiert, und den Scrummaster, der im Team für den Ablauf sorgt.
Tägliche, kurze Meetings sorgen dafür, dass innerhalb eines dieser überschaubaren Zeiträume, die in Scrum „Sprints“ genannt werden, nichts aus dem Ruder läuft.
Die inkrementelle Entwicklung schafft stets bewertbare Ergebnisse, was eine optimale Anpassung an die Kundenbedürfnisse und seine Wünsche im Verhältnis zum Aufwand ermöglicht.
Kanban ist noch einfacher.
David Anderson münzte das von Toyota entwickelte Lean-Produktion-System auf die IT-Welt. Man kann Kanban auf fünf „Gebote“ reduzieren:
Respekt vor dem Bestehenden
Mut zur Verbesserung
Visualisierung des Workflows
Arbeit nach Bedarf und Möglichkeit
Ständige Reflexion
Der Witz besteht hierbei darin, dass Arbeit in kleine berechenbare Happen so aufgeteilt wird, dass sich niemand daran verschluckt, aber auch niemand zu „hungern“ braucht.
Die Visualisierung ermöglicht, Engpässe auszumachen.
Die Arbeiten werden nach ihrem Geschäftswert und ihrer Notwendigkeit priorisiert.
Stetige Beobachtung und Reflexion sorgt für ein evolutionäres Verbesserungsmanagement.
Wenn man bedenkt, dass zehn Gebote schier uneinhaltbar sind, dann müsste es doch mit fünf einfacher zu schaffen sein. Aber das genau ist der springende Punkt: bei Geboten handelt es sich um mächtige, richtungsweisende, kulturschaffende Ideen.
Sie gehen ans Eingemachte.
Kanban eignet sich laut heise-online (http://www.heise.de/developer/artikel/Kriterien-fuer-eine-Entscheidungfuer-Scrum-oder-Kanban-1071172.html ) für kleine, überschaubare Teams, weil es im Gegensatz zu Scrum aus weniger starren Regeln besteht. Man kann sich einfacher direkt von Schreibtisch zu Schreibtisch austauschen.
Leopold und Kaltenecker empfehlen in ihrem praktischen Handbuch “Kanban in der IT”, Hanser 2012, Knaban auch in großen Unternehmen für den Beginn eines kulturellen Change.
Sollte evolutionäres Verbesserungsmanagement gewünscht werden, ist der Einsatz von Kanban in einzelnen Teams sinnvoll. Von dort kann es sich dann ausbreiten und andere Bereiche quasi “anstecken”.
Was denken IT-Manager darüber, die Praxis in beiden Techniken haben?
Ingo v. Komorowski,
Head of IT bei magari-internet (www.daparto.de)
„Ich arbeite seit ca. zwei Jahren mit Scrum.
Sollten viele Service-Arbeiten anfallen – wie zum Beispiel Ad-Hoc-Fixes – rate ich zu Kanban. Scrum eignet sich eher für Entwickler-Teams.
Man muss aber unbedingt die Konstellation im Unternehmen mit in Betracht ziehen: Scrum ist vor allem dann schwerer einzuführen, wenn die Geschäftsführung oder das Produktmanangement mit wenig technischem Verständnis sprunghaft agieren. Dort ist Kanban eher die Wahl, weil die Beteiligten sich in stetigem Prozess aneinander annähern können.
Das Gute an Scrum ist meiner Meinung nach:
· Planbarkeit (insbesondere für das Management)
· Überprüfbarkeit der Zielerlangung und damit mehr Ansatz für Verbesserung/Beschleunigung
· stärkeres Teambuilding
· stärkere Know-How-Verteilung aufgrund der Plannungs- bzw. festen Meetings und der größeren Notwendigkeit, Details der Entwicklung vorab zu besprechen
· detailliertere Aufgabenstellungen wegen Userstorys und klar definierten Sprint-Zielen
· stärkere Einbindung anderer Unternehmensbereiche durch Rollenverteilungen und Reviews
· ‘gute Gefühl’ bei den Entwicklern, wenn Ziele erreicht wurden
Eher negativ an Scrum ist meiner Meinung nach:
- größerer Overhead durch viele Meetings
- Wasserfallmodell im Kleinen: genaue Festlegung, was in einem Zeitraum umgesetzt werden soll. Punktgenaue Festlegung funktioniert aber kaum, was entweder verlorene Zeit oder nicht erreichte Ziele, die in den nächsten Sprint rutschen, mit den Folgeproblem doppelten Planungsaufwands zur Folge haben kann. Dadurch entstehen insgesamt größere Reibungsverluste und Opportunitätskosten
- ‘schlechtes Gefühl’ bei den Entwicklern, wenn die Ziele nicht erreicht wurden – Erfolgsdruck
Viele der genannten Pluspunkte bei Scrum können auch mit Kanban erreicht werden. Scrum gibt einem hierfür allerdings so klare Regeln, dass man im Zweifelsfall auf das Handbuch verweisen kann.
Mir fällt so spontan kein Unternehmensbereich ein, in dem Scrum oder Kanban keinen Sinn macht.
Andere Unternehmensbereiche sollten auch Prozesse installieren, die die Arbeiten transparent machen und
stetig voranbringen. Ob nun Kanban oder Scrum ist dabei eher nebensächlich.
Vor allem die Technik der regelmäßigen Retrospektiven sollte überall eingesetzt werden. Wenn dieser Prozess
in Gang gesetzt wird, dann wird kaum etwas den weiteren Erfolg bremsen können!“
Dr. Johannes Mainusch,
Leiter Softwareentwicklung eCommerce Solutions & Technology bei Otto Gmbh &
Co. KG
„Scrum ist besonders sinnvoll, wenn man etwas Neues entwickeln will – also für das
Projektgeschäft. Derzeit arbeiten wir mit sieben großen Teams parallel. Das geht sehr gut Ich weiß nicht, ob es eine Obergrenze für die Größe des Projekts gibt. Eine Untergrenze gibt es aber sehr wohl. Schließlich muss man sich in die Techniken erst einarbeiten und als Team zusammenfinden. Das Projekt sollte also über einen Zeitraum von mindestens drei Monaten gehen und Teamarbeit erfordern.
Kanban habe ich auch kennen gelernt. Kanban eignet sich besonders, wenn man auf bestehende Prozesse aufsetzt und mit unerwarteten Ereignissen rechnen muss: also beispielsweise für betriebsnahe Entwicklungen.
In beiden Methoden halte ich die Retrospektive für das wichtigste Meeting, da das Team über die Retrospektiven die Möglichkeit hat, den Arbeitsprozess anzupassen und so optimal zu gestalten. Ebenso entscheidend für den Erfolg waren stets die Einbindung aller Beteiligten quer über die Abteilungen hinweg. Der Schlüssel zum Erfolg ist also wie in jedem System: Kommunikation, Kommunikation und Kommunikation.“
Dr. Martin Mandischer,
Prokurist, Bereichsleiter Projektmanagement, Scrum Trainer, itemis AG
„Wir setzen sowohl Scrum als auch Kanban ein.
Zunächst einmal: Kanban ist ja ursprünglich keine agile Methode. Kanban kommt aus dem Lean-Management und wurde erst später Teil der agilen Toolbox.
Ich würde Kanban vor allem für Wartungsteams, die kontinuierliche Arbeiten abzuleisten haben, empfehlen.
Kanban ermöglicht mehr Freiheiten als Scrum. Außerdem können die Beteiligten selbst ihre Wertschöpfungskette abbilden und an ihr arbeiten. Das ist natürlich auch gleichzeitig die Gefahr: Da es keine expliziten Rollen gibt wie bei Scrum, muss das Mindset stimmen. Alle müssen an der kontinuierlichen Verbesserung arbeiten und sich dafür öffnen. Das kostet Zeit und erfordert Vertrauen.
Scrum entstand dagegen aus dem agilen Gedanken. Voraussetzung für Scrum sind feste Teams von 3 bis 9 Personen, die an einem längeren Entwicklungsprojekt arbeiten.
Henrik Kniberg vergleicht übrigens sehr lesenswert und übersichtlich Kanban mit Scrum. Für alle, die mehr wissen wollen: http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf oder die neuste Version: http://www.infoq.com/minibooks/kanban-scrum-minibook Kanban, aber auch Scrum, lassen sich auch in anderen Bereichen sehr erfolgreich einsetzen. Ich selbst habe es bereits in einem Logistikzentrum und in der Automobilindustrie eingeführt.“
