Bei unserem Meetup \u201eWie kann ich mein Team agilisieren?\u201c am 12.03.2021 gab es aus dem Publikum viele interessante Fragen, die wir euch hier nochmal ausf\u00fchrlich beantworten m\u00f6chten.<\/p>\n
Q1: Welche Rahmenbedingungen m\u00fcssen eurer Meinung nach stimmen, damit man \u00fcberhaupt mit der \u201eAgilisierung\u201c starten kann?<\/p>\n
A1: Das Team, welches agile Methoden einf\u00fchren m\u00f6chte, sollte das wollen und auch (gute) Gr\u00fcnde daf\u00fcr angeben k\u00f6nnen, warum sie das wollen. Wir haben schlechte Erfahrungen mit \u201evon oben verordneter\u201c Agilisierung von Teams gemacht.\u00a0Wille und Anlass sind dann aber auch schon genug. Alles Weitere ergibt sich dann auf dem Weg in die Agilit\u00e4t.<\/span><\/p>\n Q2: Was waren die gr\u00f6\u00dften Herausforderungen bei der Einf\u00fchrung der agilen Arbeitsweise?<\/p>\n A2: Die Herausforderungen sind immer sehr unterschiedlich. Zwei Beispiele:<\/span><\/p>\n Q3: Warum habt ihr die Teams \u201eagilisiert\u201c? Also wo gab es Schmerzen?<\/span><\/p>\n A3: Mit Bezug auf beide Beispiele aus Frage 2: Bei dem Softwareentwicklungsteam war es zum einen die Gr\u00f6\u00dfe (s. o.)und zum anderen auch das Gef\u00fchl, dass bestimmt noch einiges besser\/effektiver laufen k\u00f6nnte als der Scrum-Ansatz, den sie bisher f\u00fcr sich (\u201cautodidaktisch\u201c nach eigener Aussage des Teams) festgelegt hatten. Das durchgef\u00fchrte initiale Training war hier sehr hilfreich, da dort nicht nur ein einheitliches Verst\u00e4ndnis der Kernkonzepte und -begriffe hergestellt wurde, sondern gleich schon etliche Ideen zur Verbesserung des aktuellen Vorgehens entstanden (\u201eAch so ist das eigentlich gedacht?! Das sollten wir auch mal bei uns probieren\u201c).<\/span><\/p>\n Bei dem Explorationsteam war der Antrieb tats\u00e4chlich Neugier. Es war ein komplett neues Team f\u00fcr ein neues Projekt und da in dem Unternehmen andere Teams und Projekte schon positive Erfahrungen mit Scrum gemacht hatten, wollte es dieses Team auch mal ausprobieren.<\/span><\/p>\n Q4: Welche Rolle spielt Freiwilligkeit? Pr\u00fcft ihr vorher, ob das Team zu agilem Arbeiten bereit ist, um zu verhindern, dass ein System einfach \u201e\u00fcbergest\u00fclpt\u201c wird?<\/span><\/p>\n A4: Im Prinzip schon. Unser Auftraggeber ist in der Regel nicht das Team selbst, sondern ein:e Teamleiter:in oder jemand anders mit \u201eBudgetverantwortung\u201c im Unternehmen. Wenn wir dann bei der Arbeit mit dem Team feststellen, dass es gar nicht agil arbeiten will, thematisieren wir das auf jeden Fall (im Team und mit dem Auftraggeber). Ich kann mich tats\u00e4chlich aber nur an einen Fall erinnern, bei dem so etwas passiert ist und wir die Beratung dann auch abgebrochen haben. Es ist also \u2013 zumindest in unserem Umfeld \u2013 ziemlich selten.<\/span><\/p>\n Q5: Habt Ihr Tipps f\u00fcrs Agilisieren von Teams, die nicht an einem Projekt\u00a0<\/span>arbeiten, sondern auch unterschiedliche Linient\u00e4tigkeiten haben?<\/span><\/p>\n A5: Da das ziemlich h\u00e4ufig vorkommt, gibt es tats\u00e4chlich einen Tipp, der sich schon bei vielen Teams\/Unternehmen bew\u00e4hrt hat:<\/span><\/p>\n Nehmen wir an, ein Teammitglied hat zu 30 % noch andere Aufgaben (Linienaufgaben oder ein zweites Projekt). Das Team sollte diese:n Kolleg:in dann behandeln wie jemanden, der eine Teilzeitstelle mit 70 % hat. Wie bei normalen Teilzeitstellen sollte sich der\/die Kolleg:in gemeinsam mit dem Team \u00fcberlegen, wie man die Arbeitszeit am besten gestalten kann (jeden Tag um 15:00 Uhr \u201eFeierabend\u201c, einen Tag in der Woche \u201efrei\u201c etc.). In den meisten F\u00e4llen findet sich so eine L\u00f6sung, die allen passt.<\/span><\/p>\n Q6: Ohne kompletten detaillierten Projektplan bekomme ich von der\u00a0<\/span>\u00fcbergeordneten Organisation gar nicht erst das Budget. Was nun?<\/span><\/p>\n A6: In so einem Fall wei\u00df die \u00fcbergeordnete Organisation entweder nicht, was agiles Arbeiten bedeutet oder sie lehnt es ab. In beiden F\u00e4llen ist der erste Schritt \u201eAufkl\u00e4rung\u201c \u2013 z.\u00a0B. ein Training oder ein Workshop mit dem Projekt Management Office, F\u00fchrungskr\u00e4ften oder der Gesch\u00e4ftsleitung als Einleitung in agiles Arbeiten. Wird das Thema weiterhin skeptisch gesehen, kann man versuchen, eine Ausnahmeregelung zu finden und es als \u201ePilotprojekt\u201c laufen zu lassen. So wird das wahrgenommene Risiko gedeckelt und man kann nach dem erfolgten Pilotprojekt auf Basis der gemachten Erfahrungen gemeinsam entscheiden, ob bzw. wie man mit der Agilisierung weitermachen m\u00f6chte.<\/span><\/p>\n Q7: Wie geht ihr mit Menschen um, denen die Transparenz unangenehm ist oder die die Vorgehensweise blockieren?<\/span><\/p>\n A7: Wenn jemandem Transparenz (z. B. gegen\u00fcber den Teamkolleg:innen) unangenehm ist, ist das oft ein Anzeichen f\u00fcr mangelndes Vertrauen. Man hat dann Angst, dass die Kolleg:innen mit der Transparenz nicht verantwortungsvoll umgehen. Mangelndes Vertrauen im Team ist etwas, das man aktiv adressieren sollte, um effektiver zu arbeiten \u2013 unabh\u00e4ngig davon, ob man agil arbeitet oder nicht. An dieser Stelle k\u00f6nnte man als erstes ansetzen, wenn Bedenken in Bezug auf die Transparenz aufkommen.<\/span><\/p>\n Q8: Wie stark arbeiten die Teams (intern) zusammen? Sind StandUps noch notwendig? Hat sich durch die Pandemie etwas daran ge\u00e4ndert?<\/span><\/p>\n A8: Unserer Erfahrung im letzten Jahr war, dass gerade das Daily StandUp im Lockdown noch wichtiger geworden ist. Neben der (bei Scrum) typischen Fragestellung \u201eGlauben wir noch an unseren Plan f\u00fcr den aktuellen Sprint\u201c kam in den vergangenen Monaten bei vielen Teams noch das Thema \u201eSocializing\u201c auf die Agenda, was ja durch die weggefallenen Kaffeek\u00fcchen-Begegnungen oder gemeinsamen Grillabende deutlich zu kurz kommt. Das hat sich je nach Team unterschiedlich ausgepr\u00e4gt: manche Teams haben einen expliziten \u201eSmalltalk\u201c-Block in ihrem Daily etabliert. Andere haben sich einfach etwas mehr Zeit genommen und \u2013 bewusst ineffizient \u2013 ausf\u00fchrlicher erz\u00e4hlt, an was sie am Vortag gearbeitet haben.<\/span><\/p>\n Q9: Was passiert mit den Projektmanager:innen, die es vorher gab? Was passiert\u00a0<\/span>generell mit den Rollen, die es jetzt \u201enicht mehr braucht\u201c?<\/span><\/p>\n A9: Nehmen wir als konkretes Beispiel den Wechsel eines Teams von PMI Projektmanagement zu Scrum. In Scrum gibt es die Rolle des Projektmanagers nicht. Die Aufgaben, die ein:e Projektmanager:in innehat, fallen dadurch jedoch nicht weg. Sie werden stattdessen auf die Scrum-Rollen verteilt (Stakeholder Management: Product Owner, Work Breakdown: Entwickler:in, Hindernisse beseitigen: Scrum Master etc.).\u00a0<\/span><\/p>\n F\u00fcr jemanden, der in der Vergangenheit die Rolle der Projektmanager:in eingenommen hat, stellt sich jetzt die Frage, welche der drei Rollen am besten passt. Das muss individuell entschieden werden, da es viel vom vorhandenen Wissen und den vorhanden F\u00e4higkeiten der Person anh\u00e4ngt.\u00a0<\/span><\/p>\n In der Praxis habe ich erlebt, dass alle drei M\u00f6glichkeiten funktionieren k\u00f6nnen: Ein Projektmanager der in die Rolle des Product Owners gewechselt ist, da er gen\u00fcgend Dom\u00e4nenwissen \u00fcber das zu entwickelnde Produkt hatte; ein Projektmanager, dem immer schon der Coaching-Aspekt seiner Rolle lag und der deshalb \u00fcber die Zeit in die Scrum Master Rolle hineingewachsen ist und ein Projektmanager, der sich auf seinen Informatikhintergrund besann und (sehr gerne) wieder die Entwicklerrolle einnahm.<\/span><\/p>\n Q10: Was sind eure Empfehlungen, gerade bei kleinen Teams mit weniger als 4 Entwickler:innen? Welche Artefakte sind hier sinnvoll und welche sind overhead?<\/span><\/p>\n A10: Kurze Antwort: Herausfinden! Auch bei kleinen Teams kann man mit einem \u201evollst\u00e4ndigen\u201c Scrum beginnen (vorausgesetzt Scrum ist die richtige Methode f\u00fcr die Dom\u00e4ne). Wenn das Team dann zwei bis drei Sprints damit gearbeitet und Erfahrungen gesammelt hat, bekommt man sehr leicht mit, welche Aspekte bei der kleinen Teamgr\u00f6\u00dfe \u201eoverhead\u201c sind und kann diese dann durch leichtgewichtigere Alternativen ersetzen.<\/span><\/p>\n Mit diesem Vorgehen stellt man sicher, dass man nicht Dinge \u00fcber Bord wirft, die vielleicht erstmal zu schwergewichtig klingen, sich in der Praxis dann aber doch als ganz n\u00fctzlich herausstellen.<\/span><\/p>\n Q11: Wie geht ihr mit \u2013 nach Scrum \u2013 zu gro\u00dfen Teams um, ohne gleich die\u00a0<\/span>Nexuskeule zu schwingen?<\/span><\/p>\n A11: Bevor wir einem Kunden raten, eines der Scrum-Skalierungsframeworks einzuf\u00fchren (LeSS, Nexus, SAFe), versuchen wir immer erst zu kl\u00e4ren, ob es nicht auch ganz ohne Skalierungsframework funktioniert. Denn egal welches Framework man verwendet: die Skalierung ist nie linear. Der Output von f\u00fcnf Teams, die gemeinsam arbeiten, wird geringer sein als der Output von f\u00fcnf Teams, die unabh\u00e4ngig voneinander arbeiten k\u00f6nnen, \u2013 einfach auf Grund des Kommunikations-Overheads. Es sollte also zuerst versucht werden, das zu entwickelnde Produkt so zu schneiden, dass daraus mehrere Produkte werden, die unabh\u00e4ngig voneinander entwickelt werden k\u00f6nnen. Erst wenn das nicht m\u00f6glich ist (und man es auch tats\u00e4chlich ernsthaft versucht hat), sollte man zu einem der Skalierungsframeworks greifen.<\/span><\/p>\n Q12: Ist aus eurer Sicht der Scrum Master eine Person oder eher eine Aufgabe,\u00a0<\/span>die jeder im Team \u00fcbernehmen kann?<\/span><\/p>\n A12: Der Scrum Master ist schon eine feste Rolle im Scrum Team. Bei kleineren Teams kann es sein, dass man als Scrum Master auch noch Zeit hat, parallel die Rolle eine:r Entwickler:in einzunehmen. Dann sollte man aber auch explizit zwei parallele Rollen haben und damit entsprechend umgehen (siehe auch Frage 5). Typischerweise sind die Skills, die man ben\u00f6tigt, um guter Scrum Master zu sein, auch andere als die, um ein:e gute:r Entwickler:in zu sein. D.\u00a0h. erst wenn jede:r im Entwicklungsteam diese Skills hat, kann auch jede:r diese Rolle \u00fcbernehmen. Das ist aber ziemlich selten der Fall.<\/span><\/p>\n Q13: Sollte ein Scrum Master das Ziel verfolgen, irgendwann das Team verlassen zu k\u00f6nnen?<\/span><\/p>\n A13: Das kommt ein bisschen darauf an, wie man genau die Rolle des Scrum Master f\u00fcr das Team (oder das Unternehmen) definiert. Wenn man die Hauptaufgabe darin sieht, das Team bei der Selbstorganisation zu unterst\u00fctzen, kann es ein hehres Ziel sein, sich selbst irgendwann \u00fcberfl\u00fcssig zu machen. Wobei selbst hier die Frage ist, ob die Perspektive von au\u00dfen, die ein Scrum Master dem Team liefern kann, \u00fcberhaupt durch eine reine Innenperspektive zu ersetzen ist.<\/span><\/p>\n In den meisten F\u00e4llen kommen f\u00fcr den Scrum Master aber ja neben der F\u00f6rderung der Selbstorganisation noch weitere Aufgaben hinzu: Beseitigung von Hindernissen, Ausbildung\/Training von Personen au\u00dferhalb des Scrum Teams, Werbung f\u00fcr die agile Arbeitsweise im Unternehmen etc. Das sind typischerweise Dinge, die das Entwicklungsteam gar nicht \u00fcbernehmen m\u00f6chte. \ud83d\ude09<\/span><\/p>\n Q14: Nutzt ihr f\u00fcr Inspect & Adapt ein festes Format, z. B. ein Assessment mit festen Metriken?<\/span><\/p>\n A14: F\u00fcr das allt\u00e4gliche Inspect & Adapt in den Retrospektiven (und den anderen Scrum Meetings) nicht. Das muss immer auf das jeweilige Team, die Dom\u00e4ne und die Situation (z. B. den aktuellen Produktlebenszyklus) angepasst sein.<\/span><\/p>\n Wir haben mal einen sogenannten \u201eAgile Audit\u201c entwickelt, der den Grad der Agilit\u00e4t eines Teams oder Bereichs anhand von Kennzahlen misst und dann entsprechende Verbesserungspotentiale aufzeigt. Welche Kennzahlen das sind und wie diese gemessen werden, ist hier dann standardisiert.<\/span><\/p>\n \u201eQ\u201c15: Naja eigentlich kommen die agilen Methoden nicht aus der Software-Entwicklung \u2026<\/span><\/p>\n A15: Ohne gleich einen Historiker-Streit vom Zaun brechen zu wollen: Das erste Scrum Paper wurde 1995 auf der \u201eObject-Oriented Programming, Systems, Languages, and Applications\u201c Konferenz (OOPSLA) vorgestellt und beschreibt Scrum als neue Methode zur Systementwicklung. Das \u201eagile Manifest\u201c, welches den Begriff \u201cAgile\u201c f\u00fcr diese Art des Arbeitens 2001 eingef\u00fchrt hat, tr\u00e4gt den Titel \u201eManifesto for Agile<\/span> Software Development<\/b>\u201c. \ud83d\ude42<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Bei unserem Meetup \u201eWie kann ich mein Team agilisieren?\u201c am 12.03.2021 gab es aus dem Publikum viele interessante Fragen, die wir euch hier nochmal ausf\u00fchrlich beantworten m\u00f6chten.<\/p>\n","protected":false},"author":147,"featured_media":21135,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[],"service":[424],"level":[],"coauthors":[{"id":147,"display_name":"inovex","user_nicename":"inovex"}],"class_list":["post-27818","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","service-agile"],"acf":[],"yoast_head":"\n\n