Browse Tag

Scrum

Meine Eindrücke zum Agile by Nature Camp 2016

Im Camp Reinsehlen fand vom 6. -8. Oktober 2016 das Agile by Nature Camp zum zweiten Mal statt. Wie im vergangenen Jahr, entschieden wir uns als Organisatoren für einen Rahmen von 50 Teilnehmern für die Unkonferenz. Das dies die richtige Entscheidung war, erhielten wir während (und nach den drei Tagen) wiederholt als positive Rückmeldung.
Die Stimmung beim diesjährigen Barcamp war erneut hervorragend. Viele der Teilnehmer haben die Chance genutzt, um den Termin erneut wahrzunehmen und sich ganz im Sinne einer Unkonferenz die drei Tage selber zu gestalten.

Tag 1 – Vorfreude & Ankommen

Am Donnerstagabend starteten wir mit etwas Auflockerung und Kennenlernen in den Abend. Bei leckerem Abend-Buffet erhielt man einen guten Vorgeschmack auf die kommenden 1,5 Tage. Im Anschluss an das Essen waren die Teilnehmer aufgefordert, sich in Teams zusammenzufinden, sich vorzustellen, einen Teamnamen zu geben und mit dem Hashtag #abnc16 eine Willkommensnachricht zu posten. Im Anschluss fand die Begrüßung und einige Lightningtalks statt. Hier bekamen alle einen tiefergehenden Eindruck von dem, was die Teilnehmer beschäftigt. Der Abend klang an der Bar mit netten Gesprächen und gewisser Vorfreude am Kaminfeuer aus. 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