Methoden

Team-Working-Agreements:
10 Tipps f√ľr einen optimalen Arbeitsfluss im Team, wie sie in der IT-Automobilbranche gelebt werden ūüöÄ

Artur Sopelnik ‚ÄĘ
#team-agreements#Teamvereinbarungen#Scrum#SAFe#Agile

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:

1) Stop Starting Start Finishing

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.

2) Vier-Augen-Prinzip

Jeder Change sollte von mindestens vier Augen gesehen werden.
Pair oder Code Review.

3) Fokus auf Value

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.

4) Zero Bug Policy

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.

5) Kick-off after Refinement

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.

6) Handover before done

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.

7) Agiles Mindset

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.

8) Rebase statt Merge

Wir rebasen unsere √Ąnderungen vorzugsweise anstelle von Merge. Damit bleibt die GIT-Historie aufger√§umt und die St√§nde lassen sich einfacher reverten.

9) Fixup & Squashing

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.

10) ONE GOAL

10.1) Sprint-Goal-Checks

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.

10.2) KPIs

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.

10.3) Alert Babo

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.