Scrum | Kanban | Lean im Arbeitsalltag
Die Wellen schlagen hoch und die Möwen schreien es über das Meer hinaus: Das erste Agile Camp für den Norden hat stattgefunden und vor allem Spaß gemacht! Auf dem Blog vom Wer liefert Was? habe ich einen kurzen zusammenfassenden Beitrag meiner Eindrücke festgehalten.
Zu Besuch auf dem ersten Agile Coach Camp für den Norden Deutschlands
Sven, als Co-Organisator des Bar Camps, berichtet auf Scrum in der Praxis darüber.
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.
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.
Manchmal ist es erforderlich und hilfreich, die agilen Prinzipien und Scrum Werte erneut in das Bewusstsein des Scrum Teams zu rücken. Justin Hennessey hat dazu kürzlich einen Beitrag verfasst. Darin schreibt er, dass es wichtig ist, sich dann und wann auf die agilen Werte zu besinnen. Ob nun ein „Reset“ bei einem Team, welches schon länger zusammenarbeitet oder bei einem jungen Team, dass die agilen Werte noch nicht verinnerlicht hat. Es kann verschiedene Gründe geben, um über die agilen Werte und Prinzipien zu sprechen. Die Besinnung, bspw. in einer Retrospektive, unterstützt ein Scrum Team dabei wertbasiert zu agieren. Die Retrospektive zeigt allen auf, welche Werte in welcher Ausprägung gelebt werden. Die Grundidee dieser Retrospektive entstammt von John Miller und kann immer wieder in Abständen angewandt werden.
Im Folgenden möchte ich eine Retrospektive von ca. 60 Minuten vorstellen, wie ich sie mit einem Team von 8 Personen durchgeführt habe. Für die Durchführung von Retrospektiven verwende ich das Schema von Esther Derby und Diana Larsen. Dieses teilt das Event in fünf Phasen ein.
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.
Die Rolle des Product Owners ist unbenommen eine der herausforderndsten Rollen in der agilen Entwicklung. Daher ist es umso wichtiger, bei der Auswahl genau darauf zu achten, dass diese zentrale Rolle richtig besetzt wird, um den hohen Anforderungen und Herausforderungen zu entsprechen. Alles läuft durch die Hand des Product Owners – er trägt die Verantwortung für das Produkt. Er fungiert als Schnittstelle zum Management und zu internen und externen Projektinteressenten und –beteiligten, sowie zu seinem Team. Dabei stehen für den Product Owner die Bedürfnisse des Kunden im Vordergrund. Diesen Bedürfnissen entspricht er durch die Kenntnis der Marktanforderungen, der zeitlichen und monetären Wichtigkeit der kommenden produktspezifischen Themen. Deshalb plant und führt er das Projekt in enger Zusammenarbeit mit dem Team und dem Scrum Master.
Die Erfahrungen aus vielen Projekten zeigen, dass auf eine vernünftige Besetzung der Rolle als Product Owner großen Wert gelegt werden sollte. Die richtige Auswahl ist ein wesentlicher Erfolgsfaktor, da man sich ansonsten schnell auf einen kritischen Pfad begibt und damit
Starke Product Owner vereinen viele Talente in sich. Ich verrate kein Geheimnis wenn ich sage, dass es nur wenige gibt, die diese Rolle optimal ausfüllen und leben. Ich habe einige Product Owner kennengelernt und versucht, die Anforderungen an die optimale Ausgestaltung der Rolle in folgendem Schaubild festzuhalten.