Definition:
Das TEAM ist als Rolle im agilen Umfeld definiert. Diese Rolle ist eine Zusammenstellung aus mehreren Menschen, die gemeinschaftlich mit unterschiedlichem Know-How ein Entwicklungsziel erreichen möchten. Über den Zusammenhalt mit der Rolle definieren sich die einzelnen Mitglieder, wie Sie zusammen am geeignetsten arbeiten, miteinander funktionieren und Erfolge feiern möchten.
Ein kleines HOW TO - Umgang und (Selbst-) Organisation:
Allgemeines zur Teamunterstützung:
Über klar definierte Kommunikationswege und Regelmeetings wissen die Teammitglieder, wer zu welchem Thema nach außen der Ansprechpartner ist.
Über das Zugeständnis zu mehr Selbstinitiative und Eigenverantwortung erleben die Mitarbeiter (Teammitglieder) eine andere Stellung in der Entwicklung. Über das KANBAN-Board und den vereinbarten WIP-Limits erhält das Team zudem einen besseren "Hebel", die geplanten Aufgaben zu verwalten (anzunehmen, ggf. zurücklegen). Der Dialog und das gemeinsame Interesse an der Entwicklung eines Produkts zwischen Team und Product Owner sind das „ABC“ im Planungsprozess.
Ganz nach dem Leitsatz, „Weg von -> Hin zu“ möchte dieses Dokument aufzeigen, wie stark sich die einzelnen Teammitglieder in die Entwicklung einbringen können und wie sich das Team im Gesamten in das Unternehmen einbringt.
„Weg von“ dem „dummen Ticket-Fließbandentwickler“ ohne Entscheidungskompetenz „hin zu“ einem wichtigen Entwicklungsorgan mit Planungsfreiheit und Freigeist. Kommunikation auf Augenhöhe steht im agilen Umfeld im Vordergrund. Nimm ruhig diese Rolle und die Verantwortung an, selbstständig zu arbeiten. Folgende, einfache und kurze Hilfestellungen werden Dir zeigen, wie das funktioniert!
Team internes:
Nimm dir folgende Hinweise zu Herzen. Es hilft dir zu reflektieren, was du vielleicht bisher, von all diesen Anmerkungen anwenden kannst, oder vielleicht unbewusst oder verdeckt Anwendung findet. Wichtig ist es, selbständig herauszufinden, ob diese Hilfestellungen für Dich und das Team geeignet sind. Erdenke dir konkrete Fälle und Ergebnisse bei denen folgende Techniken angewendet werden und funktionieren können. Überlege dir, was speziell Du dabei lernen und gleichzeitig anderen helfen kannst.
- Wünsche frei äußern!
- Vorschläge zur Verbesserung sammeln und beispielsweise in der Retrospektive einbringen!
- Vorlagen erstellen!! Ziel ist es wiederkehrende Stationen in den Iterationen performant abzudecken! Nehmt Euch als Team Zeit, um die eigenen internen Prozesse aufzudröseln. Vermeidet redundante Arbeit.
- "Quality Gates" und Checklisten -> Schafft Euch kleine Meilensteine in der Entwicklung, an denen Du selbst Euren eigen tollen Fortschritt erkennen kannst.
- Agile Methoden anwenden: Paar Programmierung, Collective Ownership, Refactoring, Reviews, etc.
- Transparenz -> Kommuniziert Blockaden oder Störungen rechtzeitig nach außen -> SCRUM-Master. Holt euch ggf. Hilfe bei der Auflösung sofern dies nicht im Team gelöst werden kann.
Bei allen Punkten kann auf die Hilfe des SCRUM-Masters zurückgegriffen werden. Er kann als Moderator für Meetings oder als Prozessbeauftragter und neutraler Ansprechpartner hinzugeholt werden.
Beobachte und lerne die eigenen unterschiedliche Rollendynamiken im Team. Kommuniziere die Stärken, die du bei deinen Teammitgliedern erkennst, frei nach außen. Finde Wege diese Stärken für alle anzuwenden. Hilf dabei, sich gegenseitig zu entwickeln.
- Freie Aufteilung der Aufgaben im Team -> jeder kann die Aufgaben aus dem Pool bearbeiten auf die er „Lust“ hat.
- Daily SCRUM -> Nutzt diese Plattform, um Euch zu helfen oder von anderen helfen zu lassen. Informiere Deine Teammitglieder über den aktuellen Fortschritt ("Ich habe ... erreicht!").
Kollaboration nach außen:
- Als Team habt Ihr eine unabhängige Beratungs- und Unterstützungsrolle (SCRUM- Master) als Ressource! Nutzt diese!
- Planbarer Rahmen -> Erstellt euch eine offene, verständliche und argumentationsbeständige Aufgabenplanung. Achtet auf eure Regelmeetings.
- Gemeinsame Produktentwicklung -> Nutzt das Grooming, um Euch über das Produkt zu Informieren und gebt dort ggf. Euer Wissen und eure Einschätzungen weiter!
- Arbeit auf Eigeninitiative und Versprechen -> Das Kommitment des Teams entscheidet über den Entwicklungsfortschritt!!
- Nutze die Sprint-Retroperspektive, um Veränderungen nach außen wirkungsvoll durchzusetzen
(Speziell für SCRUM)
- Ein Sprint definiert eine versprochene, abgeschlossene und geplante Entwicklungshandlung. Die Inhalte können nur vom Team verändert werden. Die passiert aber immer in Anlehnung auf ihr Kommitment und der DoD.
Planung und Schätzung:
(SCRUM: Das Team gibt genau an, was in einem Sprint bearbeitet werden kann und was nicht. Für diese Beurteilung wird jedes Backlog-Item im Detail für den Sprint geplant.)
(KANBAN: Die WIP-Limits helfen dem Team, die geplanten Aufgaben durch die Entwicklung zu führen. Eine exakte Aufplanung vor der Bearbeitung kann, muss aber nicht zwingend erfolgen.)
Wird eine genaue Planung angestrebt, gilt es folgendes zu beachten:
- Unterscheidung zwischen Anwesenheitszeit und effektiver „Entwicklungszeit“
Erfahrungsgemäß können Menschen nicht komplette 7-8 Stunden an Tag am Stück „produktiv“ arbeiten. Hinzukommen Ablenkungen durch Meetings oder durch allgemeine und wichtige Möglichkeiten zum Informationsaustausch z.B.: in der Kaffeeküche. Zudem können unerfahrene Mitarbeiter nicht mit der Taktung ggf. mit erfahrenen Mitarbeitern mithalten. Zusammen ergibt das eine geschätzte, individuelle, tägliche Entwicklungszeit. Genau diese Zeit gilt es in der Planung als wirkliche Referenzeit für die zur Verfügung stehende Arbeitszeit zu verwenden. Achtet darauf, dass ihr euch nicht zu sehr im Detail verliert. Jenachdem über welchen Zeitraum Ihr eine Planung erstellt, definiert euch eine minimal mögliche Zeiteinheit für eine Aufgabe. Beispielsweise 1 Stunde bei einem Planungsbereich von 3 Wochen. Es kann auch sinnvoll sein, eine maximale Zeiteinheit für eine Aufgabe festzulegen. An dieser könnt ihr erkennt, dass ihr diese Aufgabe aufteilen müsst um das Risiko zu minimieren.
Weitere Empfehlungen für eine tolle und einfache Zusammenarbeit:
Neben der DoD und den üblichen Regeln für Meetings gibt es noch einige nützliche Regeln, die für eine gute Zusammenarbeit unbedingt beachtet werden sollten.
Verteilung von Informationen im Team -> Sollte das Gefühl aufkommen eine Information weiterzugeben, fange an zu erzählen – Das TEAM hörz zu und gehört zusammen.
- Nimm dir Zeit für Diagramme, Skizzen, Workflows -> Bearbeitet diese gemeinsam
- Definiere Dir/Euch einen Bereich in Deinem/Eurem Team (Büro) an dem Informationen für alle Teammitglieder öffentlich geteilt werden können
- Erstellt euch viele Benutzer- / Arbeitsanleitungen, die alle Teammitglieder lesen und auch gemeinsam bearbeiten können. Dies hilft vor allem neuen Mitarbeitern sich zu Recht zu finden.
- Verwende kurze Arbeitstitel für Anleitungen (Hilfreich sind fragende Formulierungen): z.B.: „Wie baue ich einen neuen Softwarestand mit unserem Buildsystem.“
- Formuliere verständliche Kommentare zu Check-Ins
- Verlange vom Product Owner immer rechtzeitig vor den Meetings eine Liste der zu bearbeiteten Backlog-Items.
- Jeder darf etwas ausprobieren, tauscht, wenn der Wunsch besteht, die Rollen in der Entwicklung. Helft untereinander und gebt euch gegenseitig Einblicke. -> Hier hilft es Euch, dies bereits in der Planung zu berücksichtigen.
