Neulich war ich mit ein paar Kollegen in der Kneipe verabredet. Wir unterhielten uns über dies und jenes – natürlich auch über die Arbeit. Als Evangelist propagierte ich SCRUM als die heilsbringende Methode, mit der Teams nun endlich in der Lage sind, Software zu liefern, die funktioniert und dem Auftraggeber gefällt, was wiederum das Team zu einer perfekt funktionierenden Einheit zusammenschweißt – alles Früchte meiner Arbeit als SCRUM-Master. Aber nach dem x-ten Bier kam das dicke Ende …
Bei meinen ersten Gehversuchen als SCRUM-Master war eines sehr einfach, nämlich die SCRUM-Prozesse und -Rollen einzuführen. Das ist deshalb der leichte Teil von SCRUM, weil die Prozesse und Rollen klar definiert und daher auch nicht verhandelbar sind. Schwer getan habe ich mich dagegen bei der SCRUM-Retrospektive, wenn es darum ging, dem Team die richtigen bzw. notwendigen Informationen zu entlocken, um sinnvolle Verbesserungen einzuführen.
Plant man eine Umsetzung der IT-Prozesse nach ITIL, landet man sehr schnell bei PRINCE 2. Beide Frameworks scheinen eng miteinander verknüpft zu sein. Auf der einen Seite Best Practices für eine IT-Organisation (ITIL) und auf der anderen Seite ein Projekt-Framework. Aber warum einen Best Practice-Ansatz mit einem relativ starren Projekt-Framework verbinden?