Die folgende Auflistung abgeleiteter Praktiken für agile Teams beinhaltet alle referenzierten Praktiken aus den vorgehend in der Blog-Serie beschriebenen zwölf agilen Prinzipien hinter dem agilen Manifest.

Aktive Einbindung der echten Anwender – Niemand kann so gut über die Qualität und die umgesetzten Anforderungen befinden wie die echten Anwender des Produktes. Durch die regelmäßige Einbindung dieser Anwender in alle Aspekte der Produktentwicklung erhält das Team sehr wertvolles und direkt verwertbares Feedback, so dass sowohl die nächsten Anforderungen, als auch das eigene Vorgehensmodell auf den größtmöglichen Nutzen hin verbessert werden können.

Akzeptanz-Tests – noch nicht vorhanden

Code Retreat / Coding Dojo – In der täglichen Arbeit nimmt sich ein Entwickler selten Zeit, sich mit seinem Handwerk auseinander zu setzen, sich neue Techniken anzueignen oder zu prüfen, welche anderen Perspektiven und Entwicklungsmöglichkeiten es bezüglich seiner Arbeit gibt. Formate wie Code Retreats und Coding Dojos geben den Entwicklern den expliziten Freiraum, sich abseits der echten Produktentwicklung mit anderen Entwicklungsmethoden auseinander zu setzen, neue Perspektiven einzunehmen und sich neue Techniken anzueignen.

Daily Stand-up (Daily Scrum) – Ein Team muss sich täglich koordinieren, um schnell die notwendigen Entscheidungen über das weitere Vorgehen zur Erreichung seiner Ziele treffen zu können. Diese kurze Besprechung dient nicht zum Statusbericht, sondern ausschließlich zur Koordination des Teams.

Definition of Done – noch nicht vorhanden

Dienende Führung (Servant Leadership) – Das Model der dienenden Führungskraft stellt die klassische Führungshierarchie auf den Kopf. Nicht die Mitarbeiter sind dafür da, der Führungskraft zu dienen, sondern genau anders herum: die wichtigen Personen sind die Mitarbeiter und die Führungskraft hat alles in ihrer Macht stehende zu tun, um ihre Mitarbeiter bestmöglich zu unterstützen.

Einfaches Design – Das Software-Design, mit dem die Entwicklungsteams arbeiten, muss so einfach wie möglich gehalten werden, damit es verständlich bleibt und die Wahrscheinlichkeit für langfristige Wartbarkeit und Erweiterbarkeit maximiert wird. Bei neuer Entwicklung muss von Anfang an auf einfaches Design Wert gelegt werden, bei der Weiterentwicklung alter Systeme besteht die Notwendig, das bestehende Design nach und nach zu vereinfachen.

Ganzes Team – Ein Team muss zusammenwachsen und Vertrauen aufbauen können, um zu einem guten, schlagkräftigen Team zu werden. Dies benötigt nicht nur Zeit, sondern auch Stabilität. Im Team müssen deshalb alle notwendigen Fähigkeiten und Rollen langfristig besetzt sein.

Informationsreicher Arbeitsplatz – Alle wichtigen Ergebnisse, laufenden Arbeiten, Prozessschritte, Anforderungen, Verabredungen und mehr befinden sich idealerweise direkt einsehbar im Team-Raum. Das Ziel ist dabei, bei der Suche nach relevanten Informationen keine Zeit zu verlieren und alles im direkten Zugriff zu haben.

Inkrementelles Deployment – Um frühes Feedback zu ermöglichen, muss das Produkt immer wieder zum Anwender gebracht werden können. Durch die Anwendung von inkrementellem Deployment wird das Produkt auf entsprechenden Systemen verfügbar gemacht.

Kleine Releases – Durch das Aufbrechen von großen Release-Paketen in kleine Releasezyklen beschleunigt sich das Feedback, das von Anwendern geliefert wird.

Kollektivbesitz – Ein effektives Team besteht nicht mehr aus Einzelexperten, denen jeweils ein bestimmter Teilbereich des Systems “gehört”, sondern gibt sich Arbeitsvereinbarungen, damit jedes Teammitglied in jedem Teilbereich des Systems arbeiten und Veränderungen vornehmen “darf”.

Leidenschaftliche Arbeit – Menschen werden dadurch motiviert, dass sie Aufgaben finden, die ihrer technischen und/oder fachlichen Leidenschaften sehr nahe kommen. Im Gegensatz dazu werden Menschen sehr leicht demotiviert, wenn sie Aufgaben erledigen sollen, die weder ihrer Leidenschaft entsprechen, noch irgend einen daraus ableitbaren Sinn ergeben. Für die Personalpolitik in einem Unternehmen bedeutet dies, dass nicht nur die technisch brillantesten Köpfe angeheuert werden  müssen, sondern in erster Linie auch diejenigen Mitarbeiter, die eine sehr große Begeisterung für das Produkt oder die Dienstleistung mitbringen.

Pair Programming – Die beste und schnellste Art der inneren Qualitätssicherung kann erreicht werden, wenn während der Entwicklung zwei Teammitglieder gemeinsam versuchen, die richtige Lösung in der richtigen Art und Weise zu bauen. Technische Entscheidungen müssen in solchen Paar-Konstellationen gerechtfertigt  werden, konzeptionelle Fehler können bereits im Entstehungsprozess gefunden und vermieden werden.

Product Backlog – noch nicht vorhanden

Produkt Demonstration – Mit regelmäßigen Demonstrationen von Produktständen bereits während der Entwicklung kann sehr wertvolles Feedback von Product Ownern und Anwendern eingeholt werden. Diese Demonstrationen sind nicht nur auf Meetings wie das Sprint Review Meeting beschränkt, sondern sollen idealerweise täglich vom Team durchgeführt werden.

Refaktorisierung – Die kontinuierliche Verbesserung des Software-Designs in kleinen Teilen des Systems, aber auch in größerem Umfang, ist ein wichtiger Erfolgsfaktor, um zu einem langfristig wartbaren und erweiterbaren Produkt zu gelangen.

Regelmäßige Auslieferung – Durch die regelmäßige Auslieferung eines funktionierenden Produktes erhalten die Anwender schnellstmöglich neue Funktionalitäten, die ihre Wertschöpfung erhöhen und den Anwendernutzen optimieren.

Release Burndown – Durch das iterative Abtragen der bereits umgesetzten Features (Business Value) in Form eines graphischen Charts wird sehr leicht transparent gemacht, wie viel Wert schon erreicht ist und wie viel Wert noch erreicht werden kann.

Sprint – Ein Sprint in Scrum entspricht dem Konzept der iterativen Vorgehensweise und umfasst den gesamten Zyklus von Planning, tägliche Entwicklung, Review und Retrospektive.

Sprint Backlog – noch nicht vorhanden

Sprint Planung – noch nicht vorhanden

Sprint Retrospektive – noch nicht vorhanden

Sprint Review – noch nicht vorhanden

Team-Kontinuität – Ein Team entfaltet sein gesamtes Potential erst nach und nach, es entwickelt sich mit der Zeit in einem kontinuierlichen Prozess. Dies wird durch Team-Kontinuität unterstützt. Ein wesentlicher Erfolgsfaktor für Teams ist Vertrauen unter den Teammitglieder und der Aufbau von Vertrauen ist eine langfristige Investition. Veränderungen in der Teamstruktur führen dazu, dass sich die sozialen Aspekte im Team neu ordnen müssen und damit auch das Vertrauen zwischen bestehenden und neuen Teammitgliedern neu gewonnen werden muss.

Team-Raum – Ein Team und seine Kommunikation können sich erst richtig entfalten, wenn es einen eigenen Team-Raum gibt, in dem sich die Teammitglieder alle gleichzeitig gemeinsam aufhalten und arbeiten können.

(agiles) Testen – noch nicht vorhanden

Testen durch den Anwender – Die effektivste Möglichkeit, eine Einschätzung der entwickelten Funktionalitäten eines Produktes zu erhalten, ist die Einbindung der echten Anwender in dem Maße, dass diese Anwender das System funktional und explorativ testen. So werden sehr schnell Erkenntnisse gewonnen über Usability, fehlende bzw. überflüssige Funktionen, sowie die tatsächlichen Workflows der Anwender.

Testgetriebene Entwicklung – noch nicht vorhanden

Verschwendung erkennen – In einem transparenten Vorgehensmodell können überflüssige Arbeitsschritte leicht erkannt werden. In gutem Software-Design können überflüssige Schnittstellen und Teilsysteme ebenso leicht erkannt werden. Diese Erkenntnisse sollten unbedingt dazu genutzt werden, alle unnötigen Verschwendungen in Prozess und Produkt zu entfernen.

Zusammen sitzen – Die effizienteste und effektivste Kommunikation in einem Team geschieht durch die räumliche, physische Nähe der einzelnen Teammitglieder untereinander. In der idealen Konstellation sitzt das gesamte Team in einem großen Teamraum beieinander. Alles, was dieses enge Zusammensitzen beeinträchtigt, führt zu Reibungsverlusten in der Kommunikation. Bereits die Wand zwischen zwei benachbarten Teamräumen kann dazu führen, dass einzelne Teammitglieder nicht mehr gut miteinander kommunizieren. Der verlängerte Weg zum anderen Teammitglied stellt schon eine Hürde für die Kommunikation dar, die erst aktiv überwunden werden muss. Es ist nur menschlich, solche Hürden zu vermeiden. Zusammensitzen in einem Teamraum sorgt dafür, dass diese Hürden minimiert werden.