Kanban ganz kurz erklärt
Richard Joerges am 19. April 2010
In einem früheren Posting habe ich versprochen, hier auf MacPM Kanban vorzustellen. Kanban kommt, wie viele andere neuartige Produktions-, Management- und Organisations-Ideen aus dem Toyota-Produktionssystem und dient der Organisation der Just-in-time-Produktion. Es bedeutet wörtlich übersetzt “Signalkarte”. Doch die Kartenidee hat im (Software-) Projektmanagement ausgedient, statt dessen wird mit Klebezetteln bzw. Haftnotizen gearbeitet. Die Idee ist folgende:
An einem Kanban-Board, das kann eine Tafel oder ein Whiteboard sein, werden die Prozessschritte (z.B. Planung, Programmierung, Implementation, Roll-out, etc. ) in Spalten angeordnet. Die Anforderungen, sprich Aufgaben, Features oder – Scrum lässt grüßen – Userstories werden horizontal angeordnet. Das heißt, das Kanban – sprich die Haftnotiz – wandert von Spalte zu Spalte bis der Aufgabe erledigt ist.
Damit die Teamarbeit reibungslos klappt, empfiehlt sich für jede Spalte eine zusätzliche “Erledigt”-Spalte. Diese hat unter anderem die Aufgabe, quasi als Auffangstation oder Zwischenspeicher zu dienen. Das ist notwendig, denn jede Station (repräsentiert durch die jeweilige Spalte) holt sich a) das Kanban selbst aus der vorhergehenden Spalte (Pull-Prinzip) und b) nur dann, wenn es Kapazitäten frei hat. Diese Kapazitäten werden vorher festgelegt. Mit anderen Worten: Man sieht sofort ob es Engpässe gibt und wenn ja, wo sie liegen. Nämlich dort, wo sich die Kanban-Zettel häufen.
Wichtig: Kanban ist keine Projektmanagement-Methode, sondern lediglich eine Organisationsform – quasi eine getunte To-do-Liste – und kann dem entsprechend mit Projektmanagement-Methoden wie etwa dem guten alten Wasserfall oder Scrum kombiniert werden. Klar, dass daraus sofort der Begriff Scrumban entstanden ist.
Kanban macht gerade in letzter Zeit nicht nur im Projektmanagement Furore, sondern auch als Tool für die Selbstorganisation und das Zeitmanagement. Das heißt dann Personal Kanban und ist quasi eine abgespeckte Form des Ganzen. Mehr dazu in einem späteren Blog-Posting).
Zugegeben, das hier ist eine arg verkürzte Beschreibung von Kanban. Falls Sie mehr darüber wissen wollen, hier ein paar deutschsprachige Ressourcen:
- Kanban in der IT auf Wikipedia
- Ergänzend dazu Kanban allgemein auf Wikipedia
- Was ist Kanban
- Fragen zu Kanban
- Kanban Schritt-für-Schritt grafisch dargestellt
- Kanban auf einen Blick als PDF zum Ausdrucken
Tags: Agiles Projektmanagement, Kanban, Management, Organisation, Projektmanagement 2.0, Scrum
Agil: Kanban in der Systemadministration
Richard Joerges am 22. März 2010
Zugegenben, was agile- oder schlanke Projektmanagement-Methoden und Arbeitsweise betrifft, haben wir auf MacPM zwar sehr viel über Scrum, aber nicht viel über Kanban geschrieben. Ich werde das asap nachholen.
Einstweilen möchte ich schon mal auf einen sehr interessanten Beitrag im Xing-Blog hinweisen. Dort beschreibt Kai Lippok der Chef-ITler bei Xing, wie er Kanban für die hausinterne Systemadministration, also die gängigen IT-Aufgaben “von der Mailserverwartung bis zum Ad-hoc-Support bei Mitarbeitern, deren Notebook streikt” einsetzt.
Die Gründe für den Kanban-Einsatz sind laut Kai Lippok:
- Redundanz: Durch die aktive Zusammenarbeit entsteht im positiven Sinne eine Redundanz. Dadurch wird vermieden, dass nur eine Person im Team die Kompetenz für ein Produkt hat
- Transparenz: Durch das offene Taskboard weiß jeder im Team, woran der andere gerade arbeitet. Das tägliche „Stand-Up Meeting” verstärkt dieses noch.
- Mehr Geschwindigkeit: Das mag kurz nach der Einführung noch nicht der Fall sein, sollte sich aber durch die Zusammenarbeit schnell einstellen.
- Erfahrungswerte: In der Software-Entwicklung hat es sich als effektiv erwiesen.
Alles in allem scheint das Fazit sehr positiv zu sein, auch wenn es für diesen eher untypischen Einsatz einiger Anpassungen des Kanban-Systems gebraucht hat. Aber Kreativität hat sich schon immer ausgezahlt. Ich finde es jedenfalls faszinierend, wie sich agile Methoden immer mehr aus der Software-Entwicklung heraus in andere Bereiche ausdehnen.
Tags: Agiles Projektmanagement, Kanban, Scrum
CeBIT 2010: Interview mit Frank Blome
Richard Joerges am 8. März 2010
Auch wenn die diesjährige CeBIT alles andere als geruhsam war, so haben sich doch ein paar freie Minuten gefunden, um mit Frank Blome, dem Geschäftsführer von ProjectWizards, ein kurzes Interview zu führen. Es geht, wie sollte es anders sein, um Projektmamagement, Merlin und die CeBIT allgemein.
Tags: Agiles Projektmanagement, Interview, Messe, Video, Wasserfall-Modell
Alles 3.0 oder was?
Richard Joerges am 17. Dezember 2009
Ich muss heute schon wieder auf einen Beitrag von Andreas Heilwagen Bezug nehmen. Allerdings schwebte das Thema ebenfalls schon seit längerem vor meinem geistigen Auge herum. Höchste Zeit also, es jetzt aufzugreifen. Es geht um die Unsitte alles mögliche 2.0 und neuerdings 3.0 zu nennen.
Ich muss es ein für alle mal sagen: Es gibt kaum echtes “2.0″ und schon gar kein “3.0″, zumindest wenn es sich nicht um Software handelt!
Um das zu erklären, muss ich etwas ausholen. Die Nummernfolge 2.0 tauchte zum ersten mal in Zusammenhang mit dem Begriff Web 2.0 auf. Das “neue” Web mit einem 2.0 gegen das “alte” abzugrenzen war und ist absolut in Ordnung gewesen. Tim O`Reilly, der diesen Begriff geprägt hat, hat das damals sehr gut begründet, denn es hat sich wirklich etwas getan: (weiterlesen …)
Tags: Agiles Projektmanagement, Enterprise 2.0, Projektmanagement 2.0, Social, Web 2.0
Scrum: Die Position des Teams mit “Ready” stärken
Richard Joerges am 19. August 2009
Neulich habe ich wieder einmal im Blog von Scrum-Erfinder Jeff Sutheland gestöbert. Dabei bin ich auf einen interessanten Beitrag über die Position des Teams in einem Scrum-Prozess gestossen. Es geht dabei um die Definition von “Ready” im Sinne von bereit, analog zum Done, also fertig sein mit einer Aufgabe.
Der Hintergrund ist der: In Scrum ist normalerweise das Team der “Lieferant” und der Product-Owner der “Kunde”. Will heissen, das Team liefert das Produkt/die Funktionen, der Product-Owner nimmt ab. Ready dreht die Sache zunächst quasi ins Gegenteil.
Der Hintergedanke: Ein Team kann erst dann erfolgreich seine Arbeit tun, wenn es alles an Wissen und Ressourcen hat, um seine Arbeit gewissenhaft und erfolgreich zu erledigen. Es also bereit, sprich “Ready” für einen Sprint ist.
Serge Beaumont hat auf dem Xebia-Blog dazu einen interessanten und erschöpfenden Beitrag gepostet. Lesenswert! Vertiefende Literatur gibt es ausserdem in Form eines PDFs mit dem schönen Untertitel “Are you ready-ready to be done-done?“
Tags: Agiles Projektmanagement, Scrum, Team
Scrum beim sozialen Netzwerk Xing
Richard Joerges am 30. Juli 2009
Auf dem Corporate-Blog von Xing gibt es einen dreiteiligen Beitrag über die Erfahrungen bei und nach der Einführung von Scrum (via Danny Quick). Lesenswert für alle, die mehr über Scrum bzw. dessen Implementierung wissen wollen. Ein interessantes Zitat aus dem zweiten Teil:
Die erste Herausforderung war es, Scrum innerhalb des ganzen Unternehmens zu verstehen. Wenn Scrum als Projektmanagement-Methode oder als Vorgehensmodell wie etwa das Spiralmodell missinterpretiert wird, bleiben die meisten Vorteile ungenutzt. Vorboten solcher ungünstigen Voraussetzung ist das Beibehalten klassischer Projektstrukturen und Planungsmethoden. Die Herausforderungen liegen daher nicht in komplexen Prozessen, methodischen Ansätzen oder Tools. Es stellt sich eher als Hürde dar, die agilen Werte – wie im Agilen Manifest beschrieben – und die neuen Prinzipien (adieu Projektmanagement-Dreieck!) zu verstehen und die neuen Rollen und Verantwortlichkeiten umzusetzen. Diese Prämissen verändern Teile des Produktentwicklungsprozesses grundlegend.
Mehr muss man zu diesem Thema fast nicht sagen. Siehe auch meinen vorigen Beitrag zu diesem Thema: Agil ist nicht für Alle geeignet. Allerdings würde es mich interessieren, welche Erfahrungen andere Firmen bei der Einführung einer agilen Methode wie Scrum oder/und XP gemacht haben. Über entsprechende Kommentare würde ich mich freuen.
Agil ist nicht für Alle geeignet
Richard Joerges am 29. Juli 2009
Zur Zeit habe ich es mit einem Software-Projekt zu tun, das nicht agil erstellt wurde. Die Ergebnisse sind vorhersehbar: Die gelieferte Software macht weitgehend das, was in der Leistungsbeschreibung steht, aber nicht das, was der Kunde ursprünglich haben wollte und schon gar nicht das, was er eigentlich gebraucht hätte. Schwamm drüber, jetzt gilt es nachträglich Änderungen durchzuführen, was natürlich wiederum mit Zeit- und Kosten-Aufwand verbunden ist.
Für mich erstaunlich: Weder Auftraggeber noch Softwareschmiede scheinen etwas über agile Methoden zu wissen. Nach mehreren Gesprächen ist mir aber auch klar, dass weder der eine, noch der andere für ein agiles Vorgehen geeignet wären. Beide Firmen sind zu hierarchisch und zu starr organisiert um jemals erfolgreich agil werden zu können.
Und während ich so über die Problematik sinniere, läuft mir ein dazu passender Blog-Eintrag über den Weg. Es geht um eine große Firma, die ihre Software-Entwicklung auf agile Techniken umstellt. Bei der Einführung spricht der Abteilungsleiter vor immerhin rund 3.000 Mitarbeitern und findet dabei recht harsche, aber ehrliche Worte:
…und während wir agil werden, wird es mich nicht wundern, wenn ein Drittel (am Ende des Prozess) nicht mehr bei uns sein werden. … einige von Ihnen sind Manager. Sie sind (unter Umständen) nicht der Typ von Manager, den wir brauchen. Einige von Ihnen sind Angestellte. Sie werden es (eventuell) nicht mögen auf diese Weise zu arbeiten. Der Druck wird steigen. Aber das gilt auch für die Motivation und den Lohn. … Das ist ok. Es ist der Weg den wir gehen. Wir stehen dazu. Ich akzeptiere, dass das passiert und ich respektiere Sie genug, um Ihnen das jetzt zu sagen. Viele von Ihnen haben hart gearbeitet um uns dahin zu bringen, wo wir jetzt sind, aber es bedeutet nicht, dass (diese Firma) auch in Zukunft die richtige für Sie sein wird.
Wie wahr! Agil ist nicht für Alle geeignet. Leider…
P.S.: Im oben genannten Fall ist tatsächlich das Prognostizierte eingetreten. Nicht nur das Unternehmen hat sich geändert, auch viele Mitarbeiter sind entweder weg oder haben ganz andere Rollen.
Flugzeugbau mal anders
Richard Joerges am 16. Juli 2009
Nachdem das agile Projektmanagement und da insbesondere Scrum zu unseren Steckenpferden gehört, schreiben wir entsprechend oft darüber. Natürlich vorwiegend positiv, weil wir an diese Methode glauben. Das gibt und die Selbstsicherheit auch mal über unseren Schatten springen zu können und kräftig über uns selbst zu lachen. Deshalb gefällt uns das folgende Werbe-Video besonders gut. Stellen Sie sich vor, man würde ein Flugzeug mit einer agilen Methode bauen. Natürlich im Flug. 
(via ArmerKater.de)
Tags: Agiles Projektmanagement, Humor, Scrum, Video
Je agiler, desto erfolgreicher ist das Projekt
Richard Joerges am 14. Juli 2009
Dr. Eberhard Huber vom projekt (B)LOG hat 178 Software-Entwicklungsprojekte ausgewertet und erfreuliches festgestellt: Je stärker auf agile Methoden gesetzt wird, desto wahrscheinlicher ist, dass das Projekt erfolgreich abgeschlossen wird. Seine Erkenntnis:
Die durchschnittliche Erfolgsquote aller Projekte liegt bei 28%. Werden einzelne der Scrum Elemente eingesetzt steigt die Quote an. Werden alle Elemente eingesetzt steigt die Erfolgsquote auf 58%. Zum Vergleich – Projekte, die keine der genannten Praktiken einsetzen, liegen bei 18%. Damit haben Scrum Projekte eine ca. 3 mal so große Erfolgsquote als Projekte ohne agile Elemente.
Tags: Agiles Projektmanagement, Scrum, Studien
Certified Scrum Master Training mit Jeff Sutherland
Richard Joerges am 13. Juli 2009
Alle, die zertifizierter Scrum-Master werden wollen aufgepasst: Wie wäre es mit einem CSM-Training direkt beim Scrum-Erfinder Jeff Sutherland selbst? Wer sich das nicht entgehen lassen will, hat am 5. und 6. Oktober in Stuttgart die Gelegenheit dazu. Allerdings ist der Spass nicht ganz billig: Bei Anmeldung bis Ende Juli gilt der Frühbucherpreis von 1.500 Euro netto. Danach werden 1.700 Euro netto fällig. Die Anmeldung ist über ScrumCoach.de möglich.
Tags: Agiles Projektmanagement, Scrum, termin, Veranstaltung
MacPM
Auf Twitter
Auf YouTube
Merlin Project