Warum dauert es so lange? Wieso ist der Fehler noch keinem aufgefallen? Warum wusste sonst niemand was davon? Und was bringt uns das jetzt hier konkret?
Vielleicht habt ihr auch schon mal die ein oder andere Frage bei euch im Projekt gehört und euch gefragt, ob ihr euren Arbeitsfluss etwas optimaler gestalten könnt.
Lasst euch hier gerne inspirieren, die Themen mitnehmen und im Team demokratisch voten. Wichtig ist auch, dass alle im Team wirklich das gleiche Verständnis haben. Die Team Agreements sollten daher auch unbedingt explizit formuliert werden.
In diesem Artikel gehe ich auf Team Agreements ein, die auch Methodik unabhängig sind. Es spielt also keine Rolle, ob ihr Scrum, SAFe oder auch einfach nur agil im Team unterwegs seit.
Die ersten drei Regeln sollten vielen bekannt sein:
Bedeutet neue Stories (Arbeitspakete) nur dann aufzunehmen, wenn die in Bearbeitung bereits abgeschlossen wurden. Dabei ist es auch unabhängig, ob es die eigenen Stories oder die der Kollegen sind. Voranging gilt es Unterstützung anzubieten.
Jeder Change sollte von mindestens vier Augen gesehen werden.
Pair oder Code Review.
Jede Story sollte in sich geschlossen sein und Themen darunter beinhalten.
Beim refinen der Story oder spätestens im Kickoff sollte man den Business-Value hinterfragen und eine Formulierung aus Business-Value-Perspektive verwenden. Davon nicht betroffen sind klassische Anwendungsszenarien die entsprechend aus User-Perspektive in User-Stories dokumentiert werden.
Aufkommende Bugs kommen ganz nach oben im Backlog und werden durch Tests abgesichert. Prod. sofort, alles andere spätestens im Folgesprint. Um die Transparenz im Team zu gewährleisten, sollten eine potenzielle Lesson Learned kommuniziert werden.
Ein Kickoff hat das Ziel einen vorausschauenden Arbeitsmodi im Team zu etablieren. Es beugt Irrtürme vor, reduziert Redundanzen und unterstützt beim weiteren Verlauf der Themen.
Im Refinement werden die Themen grob besprochen und oftmals im Team dann auch direkt gevotet. Um die gemeinsamen Meeting-Sessions aber nicht zu sprengen und zielführend abzuschließen sollten die Themen daher auch nicht zu detailliert besprochen werden.
Der Kollege, der sich das entsprechende Thema dann schnappt, sollte dieses dann zunächst selbst tieferlegen und anschließend mit weiteren Kollegen aus dem Team besprechen. Im Vordergrund steht, dass verschiedene Perspektiven zusammen kommen (Business, Design, Development, QA). Feinheiten und technische Details können so geklärt werden.
Sowohl beim Kickoff als auch beim Handover möchte man verschiedene Perspektiven zusammen bringen. Es gilt der Grundsatz “Three Amigos” (Business, Design, Development, QA) sollten hierbei zusammen kommen. Der Product-Owner kann, muss aber nicht zwingend eine Rolle übernehmen.
Im Handover wird geschaut, ob alle Themen dann wirklich erfüllt wurden. Wurden alle ACRs (Akzeptanzkriterien) umgesetzt? Wie steht es um die DoDs (Definition of Done) & DoRs (Definition of Ready)?
Pro-Tipp: Verwendet eine Checkliste in der Ticketbeschreibung als Vorlage.
Wer nicht mit der Zeit geht, geht mit der Zeit
Um agile Arbeitsweisen zu etablieren, ist das persönliche Mindset eines jeden essential. Es ist eine Grundvoraussetzung für jedes Mitglied im Team. Die folgenden Punkte sind dabei besonders zu beachten:
Feedback-Loops; aktive Teilnahme; Proaktivität; kein Multitasking; Anpassungsfähigkeit; Moderation rotiert durch das Team; Kamera einschalten; Continuous improvement; Kundenorientierung;
Haben einzelne Teamplayer kein agiles Mindset kann es ein hohes Projektrisiko bergen.
Achtet besonders auf Mitarbeiter die, die nachfolgenden Aussagen tätigen:
Never change a running system
oder
Das haben wir schon immer so gemacht
Diese können gefährlich werden und zeugen nicht von hoher Innovativität.
Eher man sich versieht, wird das Produkt durch innovativere Lösungen eingeholt und schlussendlich abgesetzt. Ein anderes, noch schlimmeres Szenario wäre, dass der Kollegenzusammenhalt darunter leidet und Mitarbeiter das Projekt verlassen oder gar kündigen.
Wir rebasen unsere Änderungen vorzugsweise anstelle von Merge. Damit bleibt die GIT-Historie aufgeräumt und die Stände lassen sich einfacher reverten.
Alle Änderungen sollten in einzelnen Commits gruppiert werden, damit diese vor allem nachvollziehbar sind. Mittels Squashing können Commits dann sinnvoll zusammengefasst werden.
Manchmal möchte man einen bestehenden,
lokalen Commit um Anpassungen erweitern, ohne das neuere Commits davon berührt werden.
Hierfür können Fixup Commits (git commit --fixup <COMMIT HASH>) verwenden werden.
Das Verständnis über die Vision und das gemeinsame Ziel sind ausschlaggebend für ein effektives Team und den Erfolg des Projektes. In jeder Iteration der Produktentwicklung sollte ein messbares Ziel (in Scrum auch Sprint-Ziel) definiert werden.
Pro-Tipp: Dieses Ziel sollte täglich im Rahmen eines Sprint-Goal-Checks überprüft werden. Der Check hilft ein gemeinsames Verständnis über die Erreichbarkeit des Ziels zu erlangen. Beispielsweise könnte man Fist to Five voten und bei größeren Differenzen oder bei Bedarf anschließend diskutieren.
Das Team sollte Zugang zu den KPIs haben, um mögliche Annahmen zu bestätigen und um die Software selbst noch besser optimieren zu können. Fehlverhalten wie Downtimes können so selbst ermittelt und behoben werden, noch bevor der Kunde es merkt. ONE GOAL bedeutet auch aus Sicht des Kunden zu denken. Empathie ist der Schlüssel zu einer gesunden und nachhaltigen Software.
New Relic eignet sich hervorragend, um beispielsweise Performance-KPIs damit darstellen. Mit Matomo als Alternative zu Google Analytics können darüber hinaus noch datenschutzfreundliche Analysen durchgeführt werden. Matomo bietet zudem die Möglichkeit A/B-Tests in seiner Anwendung einzubauen.
Pro-Tipp: Einmal wöchentlich gemeinsam auf die KPIs schauen und im Team besprechen.
Der Alert Babo ist eine Person, die sich die Alerts im Alert-Channel, Prisma, New-Relic Dashboard, Splunk, CloudWatch, … täglich anschaut und Entscheidungen darüber trifft, ob weitere Schritte diesbezüglich unternommen werden müssen.
Besonders wichtig ist es hierbei, dass High-Prio-Bugs oder auch Critical Issues ermittelt und aufgenommen werden. Vermeintliche wiederkehrende Fehler oder auch Warnings könnten nach Absprache im Team beispielsweise gewhitelistet werden.
Pro-Tipp: Dem Alert-Babo den Rücken frei halten damit er sich um die Alerts kümmern kann. Ebenfalls einmal wöchentlich die Rolle im Team wechseln.