In der letzten Folge haben wir Shift Left erklärt. Wir haben erklärt, was Shift Left genau ist und was für Prinzipien dafür nötig sind, wie man das Ziel von Shift Left erreicht und was die Vorteile davon sind.
Schau also unbedingt hier vorbei, falls darüber noch mehr wissen willst 😉
Softwareentwicklung ist nahezu immer ein komplexes Problem, das wir spezifisch in unserem Kontext lösen müssen, mit den Menschen in unserem Unternehmen und ihren individuellen Kenntnissen. Dazu kommt, dass Softwareentwicklung auch eine kreative Aufgabe ist, da der Kontext immer anders ist. Und für komplexe, kreative Aufgaben ist eine umfangreiche und effektive Kommunikation und Zusammenarbeit im Team, aber genauso auch zwischen Teams absolute Voraussetzung.
Für effektive Teams, also Teams, die regelmäßig ihre Arbeit integrieren und releasen, benötigen Transparenz, woran andere Teammitglieder arbeiten (z.B. Daily Scrum) und klar priorisierte Aufgaben (z.B. Product Backlog) mit einem klaren Verständnis warum diese Aufgaben so wichtig sind.
Zusätzlich erlaubt ein guter Informationsfluss eine einfachere Integration der Arbeit und damit auch die Fähigkeit regelmäßiger und nachhaltig Mehrwert an die Kunden zu liefern. Außerdem ermöglicht dieser offne Informationsfluss, dass die Teams bessere Lösungen auswählen, aus all den Alternativen, die ebenfalls möglich wären.
„Need to Protect“-Prinzip über „Need to Know“-Prinzip
Für uns sind ein enger und guter Austausch untereinander, also Kommunikation, und die offene Zusammenarbeit daher zwei der wichtigsten Bestandteile von gutem Teamwork. Und was gutes Teamwork noch ausmacht erklären wir jetzt.
Nun möchten wir darauf eingehen, wie gutes Teamwork denn nun wirklich aussieht.
Unserer Meinung nach gibt es verschiedene Faktoren, die gutes Teamwork ermöglichen und fördern.
Die Basis jedes guten Teams ist eindeutig ein gemeinsames Ziel, das dafür sorgt, dass alle Teammitglieder in die gleiche Richtung ziehen und das motiviert, aber auch einen Sinn für die Arbeit gibt (Purpose).
Kein Teammitglied wird inspiriert von der Aufgabe sein: „Bau eine Datenbank“. Wenn wir dem Team aber sagen können: „Wir wollen es ermöglichen, dass unsere Nutzer jetzt in Echtzeit auf unsere Daten zugreifen können und wir benötigen dafür eine Datenbank“, dann sieht das schon ganz anders aus.
Wichtig bei solchen Zielen ist natürlich immer, dass sie herausfordernd sind, aber nicht überfordernd sind, denn sowohl eine Über- als auch Unterforderung sind demotivierend.
Ein weiterer Faktor der sehr motivierend ist für Teams ist, dass das Team End-to-End verantwortlich ist für eine Aufgabe oder am besten für ein (Teil-)Produkt. Dafür ist die nötige Autonomie, also wie gearbeitet wird, extrem wichtig.
Zu gutem Teamwork gehört auch ein Team, das die richtige Größe und Fähigkeiten im Team hat, um die Aufgaben zu erledigen.
High-performing Teams haben die richtige Balance aus Fähigkeiten. In Agile wird das als cross-functional beschrieben und in DevOps wird dies als „Comb-Shaped“ (kammförmig) bezeichnet. Was das bedeutet ist, dass jedes Teammitglied ein breites Wissen mitbringen sollte, sodass die Aufgaben für das Team – im Idealfall – von allen bearbeitet werden können. Das heißt nicht, dass man sich nicht in einem oder mehreren Themen spezialisieren soll. Ganz im Gegenteil. Aber wichtig ist, dass dieses Wissen möglichst geteilt werden soll mit dem ganzen Team. Im englischen wird das sehr schön beschrieben als:
Diversity in knowledge, views and perspectives!
Die optimale Teamgröße ist laut mehreren Studien 5. In Scrum wird die optimale Teamgröße mit 6 +/- 3 angegeben. Wichtig ist hier zu verstehen, was bei den Extrema passiert. Für sehr große Teams ist zu beachten, dass diese Teams dazu neigen schlechter zu kommunizieren, Sub-Teams zu bilden (hängt sehr stark von der Anzahl der Aufgaben ab und dem Fokus, der durch das Product- bzw. Sprint-Goal geschaffen wird) und dass Verantwortlichkeiten verschwimmen bzw. sogar verschwinden (Sätze auf die man hier achten sollte sind z.B.: „Ja da sollte man/wir was machen.“). Aber auch für das andere Extrem gibt es Probleme. So kann ein zu kleines Team eventuell nicht alle Fähigkeiten haben, die benötigt werden, um die Aufgabe(n) zu bearbeiten.
Wichtig ist auch, dass mögliche Anreize so ausgelegt sind, dass sie positive Teamdynamiken im Team fördern. Also Einzelleistungen zu belohnen ist destruktiv. Man sollte daher versuchen Teamerfolg zu belohnen, was wiederum positive ist für die Performance des Teams. Das sollte aber nicht über den Erfolg der anderen Teams gestellt werden, da sich sonst ein „wir“ gegen „die“ Problem einstellen kann. Eine Möglichkeit dies zu verhindern ist, indem man allen Teams die am gleichenThema arbeiten eine End-to-End Verantwortung für das Gesamtprodukt gibt und ein gemeinsames Product Goal immer wieder schärft.
Eine weitere Methode, um destruktives Verhalten im Team zu verringern sind sogenannte Team-Canvas. Hierin werden die gemeinsamen Werte und Ziele des Teams festgelegt und auch wie die Zusammenarbeit und die einzelnen Events ablaufen.
Der Team Canvas ist ein Tool, das wir sehr gerne und erfolgreich mit unseren Teams einsetzen. Wichtig ist hier zu beachten, dass dieser regelmäßig nachgeschärft wird, vor allem wenn die Teams sich verändern. Quasi mal wieder Inspect & Adapt 😀 .
Dazu gehören mehrere Aspekte. Zum einen gehört dazu, dass ein „Informationssystem“ etabliert wurde, das alle Informationen schnell und einfach zur Verfügung stellt. Ein Wiki (z.B. in Confluence) ist hier sehr hilfreich, da es durchsucht werden kann. Allerdings haben wir auch schon erlebt, dass die Wikis so schlecht gepflegt werden, dass die wichtigsten Informationen fehlen bzw. die Suche hunderte Treffer ergab und nicht durch z.B. Labels eingeschränkt werden kann, da einfach niemand diese benutzt. Dann geht leider der Mehrwert einer Wiki verloren. Und ja das kostet natürlich Zeit, aber wenn man es gewohnt ist, dass man die Wiki immer direkt aktualisiert, wenn sich Links oder Teamzusammensetzung geändert haben, ist der Aufwand sehr gering. Hier sollte übrigens wieder das „Need to Protect“-Prinzip gelten 😉 , denn eins sollten wir nie vergessen:
Informationen, die nicht mit dem Team(s) geteilt werden, sind wertlos.
Denn dieses geteilte Wissen ist die Basis für effektive Zusammenarbeit und erlaubt es den Teams Situationen richtig zu interpretieren und bessere Entscheidungen zu treffen und trägt natürlich dazu bei, dass man sich gegenseitig besser versteht. Sätze, auf die man hier aufpassen sollte sind: „Das ist doch klar“ oder „Das ist doch ganz einfach“. Weil es nämlich in den meisten Fällen nicht klar ist, außer für den Experten.
Wichtig ist auch, dass ein Weiterbildungssystem etabliert ist, in dem die nötigen Trainings für Agile, DevOps oder Lean angeboten werden und von den Mitarbeitern genutzt werden können, um die Fähigkeiten im Team und damit den Outcome stetig zu verbessern.
Ein weiterer Faktor ist natürlich, dass die nötigen Ressourcen, sprich Budget, für das Team zur Verfügung stehen. Das ist nochmal ein wichtiger Punkt, den wir hier betonen möchten. Wir sollten nämlich nicht Budgets für Projekte vergeben sondern für Teams, die Produkte entwickeln. Aber darauf werden wir in einem späteren Artikel nochmal genau eingehen, wie Agile Funding funktioniert und welchen Mehrwert das bringt. Also unbedingt den Newsletter abonnieren 😉 .
Eine ganz entscheidende Rolle in dieser Umgebung ist das Management. Warum?
Eine der größten Studien zum Thema Scrum Team Effektivität (und das kann sicher auch auf DevOps Teams, bzw. alle Teams, die in einem komplexen oder kreativen oder wissenschaftlichen Umfeld arbeiten, angewendet werden), die Ergebnisse von 1200 Teams ausgewertet hat kommt zu dem Ergebnis, dass:
„A practical implication of these findings is that organizations that seek to improve the effectiveness of Scrum teams do well to invest in their autonomy.„ – A Theory of Scrum Team Effectiveness Paper
Und es gibt aus unserer Erfahrung kaum einen Faktor, der die Autonomie der Teams so sehr beeinflusst, wie die Unterstützung des Managements. Hierbei geht es um zwei entscheidende Komponenten. Zum einen die Unterstützung autonom arbeiten zu können und damit auch diesen Grundsatz zu respektieren und die Teams nicht zu beeinflussen. Andererseits gehört dazu auch die Unterstützung der Teams (und auch Scrum Master 😉 ) bei der Beseitigung von Impediments oder anderen Einschränkungen, speziell im Bezug auf Autonomie. Autonomie gilt hier sowohl für die Entwicklerteams als auch die Product Owner.
Genau diese Team Effektivität ist einer der Schwerpunkte unseres Agile Leadership Trainings . Wenn du also verstehen willst, wie du deine Teams am besten unterstützt und damit bessere Ergebnisse erzielst, ist dieses Training genau richtig für dich 😉 .
Hier ist ganz wichtig zu sehen, dass dieser Artikel sich um die Effektivität der Teams dreht. Also die Fähigkeit das Richtige zu machen. Und nicht um Effizienz (also etwas richtig/schneller zu machen).
Das ist deshalb so wichtig, da Effektivität die Basis von Effizienz ist.
Effectiveness trumps Efficiency every time.
Was wollen wir damit sagen? Naja, es hilft uns nunmal nicht schneller Produkte zu entwicklen und an die Kunden auszuliefern, wenn diese keinen Mehrwert für den Kunden haben. Daher sollte der erste Gedanke und Optimierungsschritt sein, dass wir verstehen was der Kunde wirklich will und dies zu priorisieren und erst wenn wir sehr sicher sagen können, dass wir wissen was das wichtigste für den Kunden ist und das regelmäßig bewiesen haben, dann können wir uns darum kümmern, wie man das effizienter macht.
Wenn man das oben genannte berücksichtigt, werden es die Teams schaffen das Richtige zu liefern und damit genau den Bedarf der Nutzer/Stakeholder zu treffen.
Auch werden die Entwicklungskosten für die Produkte geringer sein, da man weniger Nacharbeiten und Doppelarbeit machen muss, da wir mehr darauf konzentriert sind das Richtige für den Kunden zu bauen, anstatt einfach nur Dinge schneller zu bauen.
Durch einen besseren Informationsfluss und mehr Autonomie der Teams können diese bessere Entscheidungen über das Produkt treffen, was sich auch in der Qualität des Produkts widerspiegelt.
All das führt zu einem riesigen Vorteil für das Unternehmen, nämlich einem klaren Wettbewerbsvorteil gegenüber der Konkurrenz, da die Kunden zufriedener mit dem Produkten sind und einem Unternehmen kann nichts besseres passieren als zufriedene Kunden, die anderen potentiellen Kunden begeistert von dem Produkt erzählen 😉 .
Einfach auf das Bild klicken und direkt bestellen. Alle Bücher werden kostenlos versandt innerhalb Deutschlands (ohne Mindestbestellwert) 😉 .
Um gut in einem agilen oder DevOps Framework arbeiten zu können, ist ein Verständnis darüber was ein Scrum Team oder DevOps Team effektiv macht essenziell. Dazu gehört auch, dass der Fokus eben zunächst auf genau diese Effektivität gerichtet wird und erst dann auf die Effizienz der Teams.
Wenn wir das aber schaffen, sind die Vorteile für das Unternehmen riesig, da wir damit Kunden schaffen, die von unseren Produkten erzählen und damit weitere Kunden für das Unternehmen schaffen. Kostenlos.
Du brauchst Unterstützung von erfahrenen Coaches bei der Umsetzung bzw. Einführung dieser Konzepte?
Dann melde dich einfach direkt bei uns: Coaching/Training buchen!
Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!
Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.
Und auch der ist komplett kostenlos. Du findest den Glossar hier:
In der nächsten Folge erklären wir dir, was ein gutes Team ausmacht. Egal ob es in einem Unternehmen ist, dass DevOps, Agile oder Lean verwendet.
Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:
Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich in der nächsten Folge.
Deine Agile Coach Academy Gründer Ben und Alex
Mit * markierte Links sind Affiliate-Links mit denen du uns unterstützt dir weiterhin so guten Content zu liefern.
Vielen Dank für deinen Support 🙂
Note: Wir gehen keine Affiliates mit Amazon ein (auch wenn es hier mehr Möglichkeiten gäbe für uns), da die Mitarbeiter hier nicht fair behandelt werden und wir das nicht unterstützen!