In der Vielzahl der Publikationen finden Sie überall die Beschreibung der Regeln und Artefakte. Meistens bleibt das sehr theoretisch, weil es nur schwer ist, alle möglichen Fälle und Probleme bei der Einführung von Scrum in Ihrem Unternehmen zu berücksichtigen. Auch ich kann an dieser Stelle unmöglich umfassend Auskunft geben (wenn Sie Rat suchen, sprechen sie mich an), aber ich kann hier einen Punkt herauspicken, der immer wieder Schwierigkeiten bereitet: Die Etablierung von Scrum im Team.
Monat: Juni 2015
Wenn Sie ein Scrum Buch aufschlagen und zum Kapitel kommen, in dem der Ablauf der einzelnen Meetings beschrieben wird, werden Sie immer wieder lesen, dass der Scrum Master diese Treffen moderiert und eingreifen soll, wenn die Diskussion abschweift oder sich die Gemüter erhitzen. Das ist leichter gesagt als getan. Wenn offener Streit ausbricht oder sich das gesamte Team auskotzen möchte, dann genügt es nicht, einfach zu sagen: »Ok, beruhigen wir uns wieder, zurück zum Thema.«
»Wir glauben, dass es so funktionieren müsste, also machen wir es auch so. Und Glaubensdinge sollte man sowieso nicht in Frage stellen.« Wen wollt ihr eigentlich verarschen? Eure Kunden, euch selbst, eure Geschäftsleitung? Sie glauben wahrscheinlich, dass ich hier gerade völligen Quatsch schreibe. Sie werden sich wundern, in wie vielen Unternehmen (und damit meine ich nicht die kleinen Hinterzimmer-Entwicklerbuden) nach dem theologischen Prinzip gearbeitet wird.
Wenn Sie sich bereits mit Scrum beschäftigt haben, werden Sie wissen, dass wir für alle Meetings einen festen Zeitrahmen definieren, damit wir nicht einfach endlos plappern, sondern zügig durch die Agenda gehen. Doch was soll man machen, wenn man sich verschätzt hat, und der Review dauert einfach länger als angenommen? Bricht man dann den Review ab? Und was dann?
Bei sehr komplexen Projekten oder bei einem Schritt in bisher unerforschte Technologien für ein neues Projekt kann es sinnvoll sein, vor dem eigentlichen Projektbeginn einen oder mehrere Explorationssprints einzufügen, die dazu dienen, notwendiges Wissen zu erwerben und ggf. Architekturentscheidungen zu treffen. Solche Dinge sind jedoch kaum planbar, was uns vor ein größeres Problem stellt.
© 2024 Markus Leitner Agile Consulting & Coaching
Theme von Anders Norén — Hoch ↑