In einer idealen Welt ist jeder Projektteilnehmer zu 100% dem Projekt verschrieben. Damit kann er seinen kompletten Fokus auf die Umsetzung seiner Aufgaben legen und erreicht ein höchstes Maß an Produktivität.
Die Realität sieht leider oft so aus, dass Projektmitarbeiter für 2,5 Tage pro Woche in ein Projekt delegiert sind (Stichwort Matrix-Organisation). Im schlimmsten Fall sind nicht einmal die 2,5 Tage einheitlich und jeder Mitarbeiter für mindestens ein Meeting pro Tag in ein anderes Projekt eingebunden.
Was sich folglich in solchen Strukturen etabliert hat, ist die exzessive Nutzung von Terminkalendern (mit Terminfindungsassistent, Raumplanung etc.). Anders ist der Projektalltag für viele nicht mehr handhabbar.
Des Weiteren passiert es regelmäßig, dass zentrale Personen wie der Product Owner zum Flaschenhals werden. Betrachtet man seine durchaus vielfältigen Tätigkeiten, bestehen diese hauptsächlich darin, User Stories zu schreiben, Konzepte voranzutreiben und das Backlog zu priorisieren – das Tagesgeschäft des Product Owners. Doch was, wenn sein Kalender tagein, tagaus voll ist mit Terminen? Was, wenn er Entscheidungen erst mit dem Fachbereich besprechen muss? Mit den Kollegen, die zu 1,5 oder zu 2 Tagen pro Woche ins Projekt delegiert sind? Genau! Es gibt auch dafür einen Termin. Und da dies häufiger vorkommt, gibt es Folgetermine. Nach zwei Wochen wiederholter Termine mit denselben Teilnehmern wird ein Regeltermin etabliert. Mehrmals pro Woche. Nachmittags zu je drei Stunden. Da aufgrund der fachlichen Regeltermine kaum noch Zeit für die Arbeit am Backlog bleibt, werden Regeltermine für’s Tagesgeschäft eingestellt. Täglich, morgens von 10 bis 12.
Nach zwei Wochen fängt man an, andere Termine in diesen Zeitraum zu planen … nach drei Wochen übersieht man den ersten Regeltermin im Kalender …
Von diesem Zustand können sicher viele ein Lied singen. Es handelt sich hierbei um ein klassisches Fokus-Problem, und die Maßnahmen liegen auf der Hand. Leider muss in solchen Situationen oft erst das Projekt in Schieflage geraten, bevor die Mitarbeiter adäquaten Freiraum bekommen, um sich auf die Ausübung ihrer rollenspezifischen Aufgaben zu konzentrieren.
Fazit: Sobald ein Projektteilnehmer das Wort Regeltermin in den Mund nimmt, läuft mit Sicherheit etwas schief.
Hallo Peter,
das von Dir beschriebene Problem kenne ich ja auch, das Regeltermine aber die Quelle des Übels oder auch nur ein guter Indikator sind, da stimme ich nicht überein, im Gegenteil, ich halte diese für sehr wertvoll. (Und Scrum ist ja sogar vollständig über Regeltermine definiert.)
Viele Grüße, Markus
Hallo Markus,
danke für Deinen Kommentar!
Ich muss Dir dahingehend Recht geben, dass die Überschrift sehr pauschal gehalten ist – soll ja auch ein wenig polarisieren.
Ich würde strikt trennen zwischen Regelterminen die durch die Methode dem Projekt eine Struktur geben und solchen die einen Versuch darstellen einen Engpass im Tagesgeschäft zu managen.
In meinem aktuellen Projekt haben wir Daily Stand-Ups, Sprint Plannings, Reviews, Retros, Estimations und Backlog Groomings als feste Termine im Kalender. Ob man die letzten beiden braucht ist denke ich Ansichtssache, ich halte sie in den meisten Fällen für sehr sinnvoll.
Die „bösen“ Regeltermine die ich meine sind solche die das normale Tagesgeschäft betreffen.
Man stelle sich ein wenig überspitzt vor das Entwicklungsteam würde sich montags, mittwochs und donnerstags von 10:30 Uhr bis 12:15 Uhr und dienstags und freitags von 13 Uhr bis 16 Uhr zum Regeltermin „Software entwickeln“ treffen. Klingt absurd, oder?
Ähnlich absurd finde ich es, wenn sich der Product Owner für sein Tagesgeschäft Regeltermine einstellen muss, weil er sonst zu nichts kommt. Die Konsequenz ist, dass er vom Scrum Master und anderen Rollen stärker als normal unterstützt werden muss. Was wiederum nur funktioniert, wenn das Team „sehr gut“ ist und die Stakeholder verhältnismäßig pflegeleicht sind. Die Absurditäten die ich im Artikel beschrieben habe treten wohl trotzdem auf.
Ich denke für ein Antipattern reicht das, oder was meint Ihr?