Browse Category

Scrum

Der Agile Scrum Master Projekt Manager

Während meiner Arbeit in unterschiedlichen Unternehmen komme ich regelmäßig mit Scrum Mastern über ihre Rolle ins Gespräch. Der Ausgangspunkt sind häufig unklare Erwartungen an die Scrum Master, Unsicherheit was die Rolle angeht oder gefühlte Machtlosigkeit der Rolleninhaber. Woraus resultieren diese Probleme bei einem so einfachen Rahmenwerk wie Scrum? Meine Erfahrungen zeigen, dass viele Unternehmen Scrum lediglich team- oder abteilungsintern etablieren oder ihre existierende Projektmanagement-Methode gegen Scrum eintauschen, ohne die damit einhergehenden notwendigen Änderungen in der Organisation zu berücksichtigen. Dies hat zufolge, dass die Scrum-Teams bis zu einem gewissen Grad gut funktionieren, der Rest der Organisation aber unverändert beim Altbewährten bleibt. Gerade bei aufkommenden Herausforderungen und Unsicherheiten greifen Unternehmen gerne auf über Jahre etablierte, gelernte und gelebte Vorgehensmodelle zurück, was einen großen Druck auf die Scrum-Teams ausübt. Das Loslassen fällt vielen Unternehmen schwer und schnell fallen Sätze wie „Scrum funktioniert bei uns nicht“ oder keiner kann mehr etwas von „agil“ hören.

„If you find that your organization can’t make the hard decisions that Scrum demands, then high-risk, uncertain projects have very little probability of success in your organization.“ (Jim Highsmith)

An dieser Stelle ein kurzes Beispiel, dass ich vor einigen Jahren selbst erlebt habe. Ich arbeitete in der Software-Entwicklungsabteilung in der Rolle als Scrum Master. Bei der Einstellung legte ich Wert darauf, dass ich dem CTO direkt unterstellt bin, um mehr Durchschlagskraft zu haben und keiner Hierarchie-Kaskade zu folgen. Nach einiger Zeit begann ich, meine Fühler auch in andere Abteilungen auszustrecken. Nicht aus Langeweile, sondern weil es ein sinnvoller Schritt war. Es herrschte nämlich ein starkes „Wir“ und „Die“ im Unternehmen, dass ich aufzubrechen versuchte. Nach einigen erfolgreichen gesamtorganisatorischen Veränderungen, einschließlich aufgeklärter Mitarbeiter außerhalb der „IT“, wurde mir dann durch meinen Vorgesetzten zu verstehen gegeben, dass mein zu Hause in der Software-Entwicklung sei. Ergo „Die“ (anderen Abteilungen) sollten ihre Probleme alleine lösen. Mit dem Effekt, dass die gestartete Veränderungen, das erlangte Vertrauen in die IT und das Verständnis von „Agilität“ sich Schritt für Schritt zurückentwickelten.

Ein weiteres Beispiel zum unklaren Rollenverständnis der Scrum Master. Kürzlich entdeckte ich folgende Stellenausschreibung:

Keep Reading

100% Auslastung – alles Einstellungssache

Boris Gloger schrieb vor einiger Zeit, dass Denken in Auslastung blödsinnig ist. Angeregt durch den Beitrag und das Thema, fielen mir Situationen ein, bei denen Manager auf mich als Scrum Master oder meinen Product Owner zukamen und behaupteten, dass die Teams, mit denen ich arbeitete, nicht ausgelastet seien. Nach einem kurzen Gespräch mit den Managern und betroffenen Teammitgliedern, konnte ich mir dann schnell ein Bild von der eigentlichen Situation machen und die Kommunikation in die richtige Richtung lenken. Wie kam es zu der Annahme und was tue ich in diesen Situationen?

Das Missverständnis

Treffen sich ein Manager und Entwickler auf dem Flur. Sagt der Manager „Na, wie läufts bei euch im Team, kommt ihr voran?“ Darauf sagt der Entwickler „Diesen Sprint habe ich nicht wirklich etwas zu tun, da das Sprint Backlog nur Backlog Items für die Frontend-Entwickler enthält.“ Denkt sich der Manager „Hmmm…, da sitzt jemand rum und hat nichts zu tun!“.

Sie merken, dieser angedeutete Witz hat keine Pointe, weil diese Situation in vielen Unternehmen zum Alltag gehört. Was so nebenbei beim Small-Talk ausgetauscht wird, wirkt sich häufig in falschen Annahmen aus. Leider ist es bei vielen Managern immer noch so, dass sie annehmen, eine 100% Auslastung sei erstrebenswert. Wenn also jemand sagt, dass er „nichts zu tun hat“, dann bedeutet dies für den Manager, dass nicht effizient gearbeitet wird oder der Drang zum regulierenden Eingreifen steigt. Als Scrum Master ist es in diesen Situationen wichtig, in Richtung Management und Scrum Team zu kommunizieren. Keep Reading

Manager in Retrospektiven

Ich hatte vor einigen Tagen eine Unterhaltung mit einem Kollegen darüber, ob Manager an Retrospektiven teilnehmen sollten oder nicht. Mein Kollege war der Meinung, dass es zu mehr Transparenz führen würde und die Manager ruhig mitbekommen sollten, was das Team bewegt. Ich bin hier anderer Meinung, da die Retrospektive dem Team gehört und das Event Raum für einen offenen Austausch innerhalb des Teams schafft.

Es fällt jedoch auch hier schwer zu generalisieren und es kommt auf verschiedene Faktoren an, wie bspw. die aktuelle Situation im Team oder dem Unternehmen, die zwischenmenschlichen Beziehungen, die Firmenkultur oder der Grad des agilen Verständnisses bei den Beteiligten. 

Einen Schritt zurück

Wofür sind Sprint Retrospektiven da? Während des Events schaut das Scrum Team auf den gerade vergangenen Sprint zurück und entwickelt zusammen einen Plan, um aufgedeckte Schwächen in Stärken umzuwandeln oder zu beseitigen. Im Vordergrund stehen dabei nicht nur die zwischenmenschlichen Beziehungen, sondern vor allem die Steigerung der Qualität der Arbeit und somit des Produkts. Die Inspektion der Dinge, die verbessert werden sollen und die Ausarbeitung von Maßnahmen zur Verbesserung, obliegen dabei den Beteiligten – dem Scrum Team.  Das Event bildet eine Art Schutzraum für das Team, um jegliche Schritte zu besprechen, die dazu führen, dass ein Team sich professionalisiert. Dieser Schutzraum muss meiner Meinung nach erhalten bleiben, denn nur das Team kann sich im Sinne der Selbstorganisation Ziele setzen.

Keep Reading

Scrum praxisnah erläutert

Es ist geschafft! Sven und ich haben in den letzten Wochen und Monaten an einem für uns ganz speziellen Großprojekt gearbeitet – unser gemeinsames Buch. Es war eine tolle Idee, ein kurzer Entschluss und ein langer Weg bis hierher. Doch es hat sich unserer Meinung nach gelohnt, vor allem für die späteren Leser von „Scrum in der Praxis“ (www.scrum-in-der-praxis.de).

Erfahrungen, Problemfelder und Erfolgsfaktoren lautet der Untertitel und spiegelt damit auch im wesentlichen den Inhalt des Buches wieder. Wir wollten ein Buch schreiben, dass unsere Erfahrungen aus der alltäglichen Arbeit mit Scrum Teams zusammenfasst und die Scrum Theorie erleb- und greifbar macht. 

Agil Vor(an)gehen

Viele Unternehmen haben mittlerweile die Vorteile agiler Vorgehensweisen erkannt und wagen den Schritt weg vom traditionellen Projektmanagement hin zur Agilität. Die mit großem Abstand am weitesten verbreitete Methode ist aktuell Scrum. Allerdings bietet Scrum in seiner Reinform lediglich ein Rahmenwerk, innerhalb dessen eigene Ideen und Kreativität erforderlich und sogar erwünscht sind, sofern sie die gegebenen Rahmenbedingungen nicht verletzen. Um Scrum möglichst effizient mit Leben zu füllen, bedarf es einiger praktischer Erfahrung und eines grundlegenden Verständnisses des agilen Wertesystems. Beides ist nicht durch den Besuch eines zweitägigen Zertifizierungskurses zu erlangen, sondern muss durch operative Arbeit in agilen Projekten erlebt und erlernt werden. Keep Reading

Versuchs mal Feature-Driven

Gastbeitrag: Katja Roth www.katjaroth.com

Das Team sitzt im Sprint Planning 2 zusammen und befasst sich mit der Frage, wie die im Sprint Planning 1 gezogenen User Stories umgesetzt werden sollen. Es klärt die technischen Details, stellt architektonische Fragen und schreibt das, was zu tun ist als Tasks auf Karteikarten. Typische Tasks sind: „Controller anpassen“ oder „Service schreiben“.

Nun beginnt der Sprint. Zwei Teammitglieder ziehen den Task „Controller anpassen“. Im Daily Scrum berichten sie am folgenden Tag darüber, was sie schon alles am Controller verändert haben und dass sie noch einen weiteren Tag benötigen, um die Arbeit zu beenden. Andere Teammitglieder wundern sich, warum dieser Task so viel Zeit in Anspruch nimmt, erinnern sich aber auch nicht mehr daran, was im Sprint Planning 2 zu diesem Task vereinbart wurde. Am Ende des Sprints ist die User Story nicht fertig, weil auch bei den anderen Tasks nicht klar war, was konkret getan werden sollte. Keep Reading