Scrumbug, Humban und Klarsicht-Methoden - It’s not the spice, it’s the cooking itself
79 / 100 SEO Punktzahl

Irrglaube 7: Planen? Brauchen wir nicht

  • „Wir machen schon Sprints – Zeit für langfristige Planung bleibt da nicht.“
No. That doesn’t work nor well.

O-Ton: „Wir planen nur agil von Sprint zu Sprint – Langfristig können wir noch nicht sagen, was getan werden muss.“ Sorry, das ist der glatte Beweis von mangelndem Wissen der Beteiligten und somit ein Irrtum, der auf einer Verzerrung in der Wahrnehmung basiert. Wenn ein Vergleich zur klassischen Projektplanung gemacht wird, verzichtet Sie auf das umfassende „Vorab-Planen“ zu Beginn (und genau da ist die Abrenzung) und planen kleinteiliger, aber stetig im überschaubaren Maße. Der Fokus ist hier: Kurzfristig klar, mittel- und langfristig unklarer werdend. Aber dennoch im vorraus. Es gibt keine Stelle im Scrum Guide, wo eine Planung ausgeschlossen wird. Ganz im Gegenteil, nur anders.

Ganz einfach dargestellt ist der Unterschied bei funktionierenden Scrum-Teams folgender. Anders als bei der klassischen Planung, wo versucht wird, alle Eventualitäten, auch die, die zeitlich weiter in der Zukunft sind, schon zu erfassen und zu planen. In Scrum wird ein evolutionäre Vorgehen und die Einteilung in kurze Zeiteinheiten und kleinteiligen Arbeiten forciert. Letztendlich fängt jedoch jedes Scrum-Team mit einer Vision und einem klaren Zielpunkt (also weiter hinten in der Zukunft) an. Klar in dem Sinne, dass ein sinnvolles, erreichbares und geteiltes Ziel im Mittelpunkt der Bemühungen (also vorne) steht. Etwas, auf das ein Scrum-Team fokussiert zuarbeiten kann; mit der Option, den Weg dorthin stetig anzupassen. Um dieses Verständnis herzustellen, hat sich bewährt, eine Story-Map, basierend auf der Vision, zu erstellen.

Dieser erste Wurf einer Lösung hilft einem Team, sowohl den Umfang als auch das Ziel fokussiert anzugehen. Es gilt das Prinzip: „Das Richtige richtig tun.“ Jetzt, erst jetzt, wie bei einem Wein oder einer aufwändigen Speise, fangen die einzelnen Themen an zu reifen (oder zu garen). Heißt, es kommen zu einem einzelnen, kleinen Thema immer mehr Details und Abhängigkeiten hinzu. So, im Laufe der Zeit, das kann durchaus über zwei oder 3-5 Sprints gehen, wird dieses einzelne Thema regelrecht „reif“ – bis zu dem Punkt (gegart), wo es aus der Planung heraus (oder beim Garen von Herd) genommen wird, damit es weiter ver- oder bearbeitet werden kann.

Der kleinste gemeinsame Planungs-Nenner ist das tägliche Synchronisieren des Teams während des Daily Stand-Ups. Im Mittelpunkt für das Team steht die Klärung der Frage „Wie sind wir dabei, das Sprintziel zu erreichen?“ Und wie Daily schon sagt, für diesen Tag. Damit sind wir bei der mittelfristigen Planung der Sprints, die heruntergebrochen auf die Vision oder Teilziele des Projekts einzahlen. Ein gern gemachter Fehler ist, der Planung für die kommenden Anforderungen zu wenig Raum zu geben. Hierbei werden zwischen dem Team und dem Product Owner mit dem Ziel eines gemeinsamem Verständnisses die Umsetzbarkeit besprochen. Hier, in diesem Raum der Planung führt ein gut gemachtes Product Backlog Grooming unweigerlich IM Team dazu, eine mittelfristige Planung von mindestens 2-5 Sprints im voraus vor Augen zu haben.

Pfiffige Product Owner planen noch viel weiter als das und haben bis zu 10 Sprints im Blick. Ausgefeilte Tools, z.B. Portfolio-Tools (Atlassian), visualisieren Monate, Quartale oder Jahre im vorraus. Das wollen Unternehmen und Führungsetagen sehen. Scrum-Teams setzen also viel daran, der Unschärfe in die Zukunft mit Kommunikation (meiner Domäne) entgegenzuwirken. Sehr gute Teams nehmen sich innerhalb eines Sprints auch die entsprechende Zeit – dafür, um ein möglichst klares Bild in Zusammenarbeit mit Stakeholdern zu erzielen. Das verhindert mittelfristige Irritationen, denn jeder Stakeholder möchte sein(!) Thema (Was scheren mich andere Themen? (What’s in for me? Bias)) bearbeitet wissen. Was wissen Sie oder die Scrum-Teams, wohin der der Stakeholder (zusätzlich) berichten muss?

Irrglaube 8: Scrum schafft Manager ab. Manager – wozu?

Anfänglich, gerade bei Scrum, wurde im Fokus das selbstorganisierte Team postuliert. Verantwortungen wurden in die Teams gegeben, der Team Lead, Abteilungsleiter, usw. wurde als funktionslos angesehen. Und die ‚keine Funktion (in Scrum)‘ braucht man nicht. Trugschluss, was die Interpreation von Autonomie angeht. Übler Fehler (Nicht immer, aber regelmässig). So wurde es seinerzeit in den Scrum-Guide hinein-interpretiert und von den Führungskräften empfunden. Aber so steht es nicht geschrieben, es wurde vermutet. Was trat ein? Siehe weiter oben, ich schrieb über Schmerzen. Dazu die Angst vor Macht- und Arbeitsplatz-Verlust (Verlustaversion) hat auf der mittleren Managementebene zu einem starken Widerstand gegen Scrum gebildet. Später wurde erst erkannt, dass dieser Fehler real ist – Die Selbstorganisation ist nämlich keine Ticket oder Arbeit, die einfach gemacht wird, sondern eine innere Haltung, die auch Selbstverantwortung beinhaltet. Das wurde nicht oder selten vermittelt, weil es ein Kultur-Thema ist. Und man hat diese Führungsebene mehr oder weniger ‚ENT-täuscht‚ sich selbst überlassen, anstatt sie in die neue Arbeitswelt einzubeziehen.

Fakt ist: Eine Organisation braucht weiterhin Manager, nur mit anderen Aufgaben. Es ist so, dass sich die Rolle des Managers erheblich gewandelt hat – weg von einem reinen Entscheider, Arbeitszuweiser und Kontrolleur hin zu einem Unterstützer, Mentor und Coach. Die Formulierung „Es ist sein Team“ impliziert das Geschmäckle der Leibeigenschaft. Dann ist der Manager aber auch für die Ergebnisse verantwortlich. Genau das soll(te) sich ändern. Die Verantwortung in dieser Rolle sollte bei Null liegen und alle (alt-) Lasten liegen somit nicht mehr auf dem Schultern des Managers.

Er sorgt dafür, dass  z. B. das Umfeld, in dem gearbeitet wird, stimmt. Er kümmert sich darum, dass die Mitglieder des Teams gut ausgebildet sind und sich ständig weiterentwickeln. Er ermuntert sie, Verantwortung für ihren Arbeitsbereich zu übernehmen und schafft eine fehlertolerante Kultur des Respekts und Vertrauens untereinander. Je nach Entwicklungsstand (Reifegrad-Modell) des Teams oder des einzelnen Mitgliedes nutzt er die volle Bandbreite der Delegation (vgl. u.a. Delegation Poker). Sein Ziel muss es nun sein, seine die Teams vollumfänglich arbeits- und entscheidungsfähig zu machen. Auch hier wird wieder (aus etwas skurriler, überspitzter Sicht) offensichtlich: Es ist die Aufgabe des Managers, diese Mitarbeiter zu entwickeln, dass diese aktiv mitdenken, selbst Vorschläge machen und auch mal Dinge ausprobieren. Spontan: Das Kochen, nicht nur das Würzen (siehe Einleitung) beizubringen und dafür Verantwortung zu übernehmen. Und Kochen (ein Koch muss selber denken und entscheiden) ist nichts, was man per Dekret anordnen kann, stattdessen muss der Team-Lead aktiv vorangehen und das Umfeld ER -schaffen.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend