Der niederländische Top-Blogger Bas de Baar (über 32.000 Leser/innen via RSS !) hatte die Idee, seinen erfolgreichen Video-Podcast „Project Shrink“ auf den deutschsprachigen Raum auszuweiten. Vor einigen Wochen hat er mich hierzu kontaktiert, schon war „Projektmanagement TV“ geboren.
Wir werden zukünftig mindestens 2-wöchentlich eine kurze Skype-Konferenz abhalten, in der wir aktuelle Themen rund ums Projektmanagement diskutieren. Geplant sind in weiterer Folge auch Interviews mit interessanten Persönlichkeiten aus der PM-Szene.
Der Einführungs-Podcast mit der Bezeichnung „Episode 0“ ist als erster Test zu verstehen. Zukünftig werden wir Euch sicher noch gehaltvollere Video-Podcasts bieten können.
Themen der Episode 0:
Kurze Vorstellungsrunde (Was hat uns zum Bloggen gebracht? Welche Fragen beschäftigen uns? Was motiviert uns?)
Communities im Projektmanagement („real“ und „virtuell“)
Themen-Aufruf: podcast@pm-blog.com
Wir sind schon gespannt, wie sich dieses offene Lernprojekt entwickeln wird.
SCRUM ist eine agile PM Methodik und gleichzeitig ein Vorgehensmodell, das in den letzten Jahren stark an Bedeutung zugenommen hat. Gleichzeitig fällt es vielen Unternehmen schwer, die Scrum Prinzipien 1:1 umzusetzen. Diese sind beispielsweise (siehe hierzu auch die Grafik unten):
Ken Schwaber ist einer der Begründer von Scrum. Er erläutert im obigen Video, dass es unter gewissen Umständen legitim ist, von den definierten Scrum Prinzipien abzurücken und diese anzupassen. Schwaber nennt dies „ScrumBut“. Diese Bezeichnung kommt von der Aussage „Yes, we use Scrum, but…“.
Blogger-Kollege Jurgen Appelo geht sogar noch weiter und behauptet, dass das volle Potenzial von Scrum erst dann entfaltet werden kann, wenn ScrumBut angewendet wird, sprich wenn das Konzept den jeweiligen Rahmenbedingungen und vor allem dem jeweiligen Team angepasst wird.
Auch der von mir sehr geschätzte Kollege Pawel Brodzinski plädiert inständig für eine sinnvolle Anpassung von methodischen Ansätzen und Vorgehensmodellen. Sein Beitrag ist allerdings etwas ironisch geschrieben – ich musste ihn 2 mal lesen, um die Argumentation zu verstehen.
Verhältnismäßig wenige Expert/innen sehen ScrumBut kritisch und raten strikt davon ab, das Scrum-Konzept zu „verbiegen“. Es scheint sich die Meinung durchzusetzen, dass ScrumBut legitim oder sogar zwingend notwendig ist.
FAZIT: Ich denke, ScrumBut ist in den meisten Fällen sinnvoll und notwendig. Allerdings sollte man es sich in der Praxis nicht zu leicht machen. Denn das „Herz“ von Scrum – so wie es auch im agilen Manifest beschrieben ist – sollte niemals verloren gehen. Für ein differenziertes ScrumBut tritt auch Scrum-Experte Boris Gloger ein: „ScrumBut – Eine genauere Betrachtung„.
Nachtrag vom 19.11.2010: Boris Gloger hat recht. Die Formulierung „ScrumBut ist in den meisten Fällen sinnvoll und notwendig“ ist so nicht richtig. Ich stimme ihm zu, dass man die Implementierung von SCRUM als Entwicklungsprozess betrachten sollte. Natürlich ist das Ziel, agile Prinzipien so weit wie möglich bzw. soweit es Sinn macht zu implementieren.
„Ein Vorgehensmodell organisiert einen Prozess der gestaltenden Produktion in verschiedene, strukturierte Phasen, denen wiederum entsprechende Methoden und Techniken der Organisation zugeordnet sind. Aufgabe eines Vorgehensmodells ist es, die allgemein in einem Gestaltungsprozess auftretenden Aufgabenstellungen und Aktivitäten in einer sinnfälligen logischen Ordnung darzustellen.“ (Quelle: Wikipedia)
Kürzlich habe ich zu diesem Thema eine Blitzumfrage durchgeführt. An dieser Stelle ein herzliches Dankeschön an alle, die an der Umfrage bereits teilgenommen haben. Es zeigt sich nach 57 Rückmeldungen folgendes Bild (siehe oben):
44% der Befragten verwenden teilweise einheitliche Projektprozesse / Vorgehensmodelle
40% der Befragten verwenden keine Projektprozesse / Vorgehensmodelle, würden die Anwendung aber für sinnvoll erachten
12% der Befragten beurteilen das prozessorientierte PM für gut integriert
lediglich 4% wenden keine Prozessmodelle
Meines Erachtens ist es von entscheidender Bedeutung, in der Anwendung von Vorgehensmodellen / Projektprozessen sehr differenziert vorzugehen. Denn gerade bei sehr komplexen, neuartigen und dynamischen Projekten ist es wenig sinnvoll, nach einem verhältnismäßig starren Prozess vorzugehen. In solchen Anwendungsfällen eignen sich iterative und agile Vorgehensmodelle, die im Kern nur aus einigen sinnvollen Prinzipien und Grundregeln bestehen.
Sehr strukturierte Modelle machen dort Sinn, wo Projektaufgaben schon einen starken Routinecharakter haben. Dies ist beispielsweise häufig bei „Kundenprojekten“ der Fall. Aber auch hier gilt: Je neuartiger und komplexer ein Projekt ist, umso besser sollte geprüft werden, ob das jeweilige Vorgehensmodell anwendbar ist.
FAZIT: Vorgehensmodelle können im Einzelfall sehr viel Sinn machen, da sie das gemeinsame Verständnis für ein systematisches und strukturiertes Vorgehen in Projekten fördern. Gleichzeitig können Vorgehensmodelle aber auch sehr negative Auswirkungen haben, wenn sie starr und bürokratisch angewendet werden – insbesondere bei neuartigen, komplexen und dynamischen Projekten.
