Don’t do Agile! Be Agile! – Scrum@EGIT

Don’t do Agile! Be Agile! – Scrum@EGIT

Agiles Mindset: Wir bei Erste Group IT wenden nicht nur agile Methoden an, wir leben auch danach. Es reicht nicht nur agile Frameworks wie zum Beispiel Scrum einzuführen, sondern wir halten uns an das agile Manifest und die agilen Prinzipien, arbeiten ständig daran uns zu verbessern und haben dabei die Werte ständig im Fokus. Diese bilden das Fundament bei der Zusammenarbeit in Projekten zwischen den Umsetzungsteams und dem Fachbereich. Wir sprechen dabei vom agilen Mindset, das notwendig ist, damit „Agile“ auch in der Praxis funktioniert. Dabei reicht es nicht nur in der IT agile Methoden zu verwenden, das gesamte Unternehmen ist an der agilen Transformation beteiligt. Von der Organisation, den Führungskräften, den Fachbereichen bis hin zur Personalabteilung, alle müssen am Änderungsprozess teilhaben, damit der Wechsel zu einem agilen Unternehmen gelingen kann.  

Scrum – agiles Framework: Scrum bietet uns dafür eine Struktur in der Umsetzung von Softwareprojekten. Es ist nicht die Lösung aller Probleme, sondern hilft dabei, Probleme schneller sichtbar zu machen und gibt den Rahmen, damit fortlaufend das Produkt, das Team und die Arbeitsumgebung verbessert werden kann.

Diese agile Methode ist bereits seit den 90er Jahren im Einsatz und wurde von Ken Schwaber und Jeff Sutherland entwickelt und ständig verbessert. Die Idee dahinter ist es dem Kunden frühzeitig Wert mit seinem Produkt zu liefern, und zwar durch eine iterative Umsetzung, den sogenannten Sprints, die bei uns einen 2-wöchigen Rhythmus haben. Weiters wollen wir die Kundenzufriedenheit steigern und entwickeln was wirklich gebraucht wird. Dies erreichen wir durch rasches Feedback des Fachbereichs, zum Beispiel durch tägliches Einbinden in Form des Product Owners. Dies ist eine der 3 Rollen in Scrum. Er ist für die Wertmaximierung des Produktes, für das Erstellen der Anforderungen und für die Priorisierung verantwortlich. Dabei ist er eine Einzelperson und kein Komitee und muss die Fähigkeiten und die Befugnisse von der Organisation bekommen, diese Entscheidungen treffen zu können. Eine sehr wichtige und zeitintensive Aufgabe, die im Fachbereich angesiedelt ist und sich hauptsächlich um die Weiterentwicklung des Produkts kümmert. Demgegenüber steht der Scrum Master, der verantwortlich ist Scrum und Agilität zu fördern und zu unterstützen. Er ist der Servant Leader und Facilitator des Teams und unterstützt und coacht nicht nur das Umsetzungsteam, sondern auch den Product Owner und das Unternehmen und hilft bei der Einführung von Scrum. Dies macht diese Rolle so spannend und abwechslungsreich.

Die dritte Rolle ist das Umsetzungsteam. Es agiert selbstorganisiert, interdisziplinär und liefert am Ende eines jeden Sprints ein fertiges potenziell auslieferbares Produkt. Der große Unterschied zu herkömmlichen Teams ist es, dass sie ihre Arbeit selbst managen und ihnen niemand vorgibt wie sie ihre Arbeit zu erledigen haben.

Der Arbeitsalltag eines Scrum Teams: Der Sprint beginnt mit einer Aktivität, genannt „Sprint Planning“. Hier gibt der Product Owner das Ziel für den Sprint vor und erklärt die Anforderungen in Form von User Stories, die im Backlog ganz oben gereiht sind und für das Erreichen des Ziels notwendig sind. Das Umsetzungsteam entscheidet danach alleine, welche User Stories sie davon in das Sprint Backlog nehmen und setzen alles daran dieses Commitment als Team einzuhalten. Die Anforderungen werden in kleine Tasks (Arbeitsschritte) aufgeteilt und auf das Scrum Board übertragen. Dann beginnt die Umsetzungsphase. Hierbei werden die  Anforderungen zuerst designed, entwickelt, reviewed, getestet und dann vom Product Owner abgenommen und dies alles innerhalb eines Sprints. Dies ist gar nicht so einfach und benötigt einige Erfahrungen. Der Tag wird mit dem „Daily Standup“ begonnen, einer weiteren Aktivität von Scrum. Hier plant das Team den Tag und verschiebt die Tasks auf dem Scrum Board. Hier steht der Product Owner täglich als Ansprechpartner zur Verfügung. Am Ende des Sprints wird im „Review“ den Usern und Stakeholdern das fertige Produkt vorgeführt. Der Abschluss ist die „Retrospektive“, wo das Team gemäß „Inspect and Adapt“ reflektiert und Verbesserungen beschließt. Dann beginnt der nächste Sprint.