- Lean Coffee Frankfurt: https://www.xing.com/communities/groups/lean-coffee-frankfurt-am-main-8879-1139176/about
- Lean Coffee Karlsruhe: https://www.xing.com/communities/groups/lean-coffee-karlsruhe-8879-1139173/events/upcoming
Der Lean Coffee wurde, unserem „Wechselmodell entsprechend“, wieder von Karlsruhe ausgerichtet. Roberto Blanco war Gast („ein bisschen Spaß muss sein“), aber auch eine „echte“ neue Teilnehmerin durften wir begrüßen.
Übrigens gibt es das Lean Coffee als als Sonderausgabe auf dem Online-Teil des Scrum Days im September.
Hier kommen die Themen, die sich sogar an die aktuellen meteorologischen Geschehnisse in Deutschland und Österreich anpassen.
Agile Ansätze bei aktuellen Naturkatastrophen
Als erstes „Auftragsklärung“: Es ist gemeint, welche Ansätze zum Tragen kommen sollten/könnten, wenn die Katastrophe eingetreten ist, nicht, über welche Ansätze man versuchen könnte, sie schon im Vorfeld zu verhindern. (Dieser Zug scheint ohnehin seit vielen Jahren abgefahren [die Red.]) Ein Teilnehmer berichtete, dass bei Rettungskräften agile Elemente wie z. B. Dailies zur schnellen und effektiven Abstimmung untereinander bereits Standard seien: Jede/r kennt dabei die eigenen Handgriffe, den er/sie im Ernstfall ausführen muss. |
| Foto von Jeremy Yap auf Unsplash |
Der Themengeber ergänzte, dass Rettungspläne häufig bereits existieren, „sie sind fertig und werden zuerst aus der Schublade gezogen“, über die Details wird dann ad hoc vor Ort entschieden. Die ersten Schritte, so die Vermutung aus der Runde, sind wahrscheinlich relativ klassisch: Szenarien werden gedanklich durchgespielt, das benötigte Material (z. B. bei einem Reaktorunfall Tabletten für die Bevölkerung) muss bereits verfügbar sein, für etwa eine Evakuierung notwendige Utensilien müssen bereitstehen, entsprechende Maßnahmen müssen sofort eingeleitet werden können.
Die Schwierigkeit bei Naturkatastrophen, so ergänzte jemand, bestehe darin, dass der Mensch nicht daran glaube, dass es tatsächlich gerade ihm passiere. Die Teilnehmerin berichtete von einer Betroffenen, die einer Überschwemmung u.a. vor ihrem Haus zusah, aber nicht auf die Idee kam, Dinge aus dem Keller in den 1. Stock zu räumen. Ein Teilnehmer kommentierte frech: „Sind ja auch immer die anderen Teenager, die beim ersten Sex schwanger werden…“ (Ja, auch solche Kommentare landen in den Nachschauten! 😉)
Es wurde festgestellt, dass in einer Notfallsituation eine höhere Teamautonomie benötigt werde, beispielsweise beim THW oder bei der Feuerwehr. Von den Rettungskräften, die immer wieder üben, damit sie wissen, was sie machen müssen, leitete jemand über: „Apropos Üben… ein Schweizer muss in die Grundausbildung beim Militär.“ Er werde dort immer wieder geschult. Schlusskommentar: „Du bist irgendwann steinalt und wirst jedes Jahr ausgebildet…“
Ein Gast berichtete, er sei in seinem Berufsleben einmal Mitglied in einem Special Assistance Team gewesen, welches Fluggäste nach Katastrophen begleitet habe. Nach einer Katastrophe mit Erdbebenbeteiligung in der Türkei in den 1990er Jahren beispielsweise hätte das Team die Kollegen in Istanbul abgelöst und deren komplette Arbeit dort übernommen. Es gebe auch eine ganz klare Kommandokette, so der Teilnehmer, Vorstandsvorsitzende z. B. dürften vor Presse nichts sagen und würden abgeschirmt, damit sie in emotionalen Momenten nicht ungünstige Äußerungen tätigten. Diese Aufgabe ist nach Meinung des Gastes in höchstem Maße agil, denn man arbeite mit den Menschen vor Ort, wisse aber überhaupt nicht, was in ihnen vorgeht und was ggf. als nächstes passiere. Alternativ konnte sich der Teilnehmer aber auch eine nüchterne Planung immer wiederkehrender und planbarer Aufgaben über Kanban vorstellen.
Das immer mal wiederkehrende Thema der Budgetierung…
„Brauche ich 100.000 € oder 1 Mio.?“ Wenn jemand eine agile Initiative aufsetzt, setzt er keine klassische Initiative auf. Agilität bedeutet, mit Unsicherheiten leben müssen. (Ein Teilnehmer ergänzte dazu, dass auch in klassischen Projekten die Planungen sehr oft ziemlich anders aussähen als später die Realität). Als ein mögliches Heilmittel wurden agile Verträge empfohlen (eines der vergangenen Spezialthemen in unserem Lean Coffee!), in stramm korsetthaften Initiativen lässt sich ggf., wenn man aus dem Ruder läuft, über Abschichtung der Produkteigenschaften (MVP) etwas erreichen. Ein Teilnehmer gab zu bedenken, dass es bei Projekten oder Programmen natürlich ein Ziel gebe und damit teilweise 80% dessen, was umgesetzt werden soll, bereits im Vorfeld festgelegt seien. Dennoch der Kommentar aus der Runde dazu: „Eine Schätzung ist eine Schätzung.“
Plötzlich stand die Frage eines Teilnehmers im Raum: „Hat jemand Star Trek Discovery gesehen?“ Kurze Pause, in der einige in sich gingen, um zu überlegen, begleitet von ersten positiven Rückmeldungen. „Da gibt’s eine Figur, die fährt immer Ganglien aus, wenn sie Gefahr spürt - das wär‘ jetzt bei mir so… was ist denn das für eine unternehmerische Herangehensweise?“ (Amüsement in der Runde) Wenn eine Planung machbar sei, sollte man auch planen, dies sei auch nicht zwingenderweise unagil, lautete eine andere Ergänzung.
Außerdem erging folgender pragmatischer Vorschlag, der wohl bei erfolgstechnisch grundsätzlich unkalkulierbaren Start-ups angewendet wird: Investoren geben im ersten Schritt vielleicht 10.000€. Es gibt einen Pitch. Wenn das Start-up dabei gut abschneidet, erhält es weitere 100.000 €. Auf diese Weise hangeln sich auch die Investoren vor, anstatt gleich Millionen in eine Idee zu pumpen, die sich am Ende als vielleicht gar nicht tragfähig erweist. Über das beschriebene Vorgehen - mit der Unsicherheit im Nacken, dass man nicht weiß, ob die Idee bis zum Ende durchhält - wird immer wieder entschieden, ob in die jeweils nächste Entwicklungsphase investiert wird. Die ersten Sprints dienen hier dazu, das Konzept festzulegen. Ab etwa der Mitte des Projektes steht ein klare(re)s Bild zu Design und Anforderungen zur Verfügung, welches als Basis für eine genauere Planung genutzt werden kann (laut dem Teilnehmer wird dies als „Denken in real options“ bezeichnet).
Ein Teilnehmer konstatierte trocken, dass es in seinen Projekten es gar nicht die Option gegeben habe, das ganze sein zu lassen. Gründe hierfür waren beispielsweise auslaufende Lizenzen, die nicht verlängert werden sollten, und damit verbunden teilweise ein Wechsel auf eine völlig andere, noch unbekannte Technologie, verbunden mit einem Riesenaufwand (…der dunkel an SAFe-Initiativen erinnert… [<- wieder die Red.]) Die sehr treffende Rückantwort des Denkers in real options lautete, das sei unprofessionell, dahinter stehe das Versagen der Governance. Der Zug sei aufgegleist worden, und danach bedeute Risikomanagement, dass man bereit sei, alle Risiken zu akzeptieren. Eine Alternative hierzu könnte die Erstellung eines Piloten sein.
Wiederum Rückantwort des Kommentar-Einwerfers: „ Du kannst gar keinen Prototyp bauen - du hast einen Schuss, ansonsten läuft alles zeitlich total aus dem Ruder…“
Eine bessere Herangehensweise (die sich komischerweise flächendeckend, so scheint es, noch nicht herumgesprochen hat) sieht folgendermaßen aus: Wenn etwas zu Beginn nicht geplant werden kann , muss der Unternehmer am Anfang festlegen, welche Summe ihm der Versuch wert ist, und weiterarbeiten (lassen), wenn der erste Schuss funktioniert. Um Erfahrungswerte mit neuen Technologien zu erhalten, so die Info des Gastes, sollten mindestens fünf verschiedene Stichproben gesammelt werden. Es gehe um eine „bewusste Entscheidung am Ende des Geldes“ (klingt das nicht schön?).
Um unbekannte Kosten besser abschätzen zu können, lohnt es sich auch, sogenannte Parametrisierungsmodelle (wie COCOMO) zu nutzen. Darin werden Koeffizienten festgelegt, die es erlauben, die voraussichtlichen Kosten in anderen Dimensionen hochzurechnen. Beispiel: Ein User/Modul kostet uns x €. Wieviel kosten uns 5000 User/30 Module?
Scrum-Team-Mitglied ohne Aufgaben
In dieser Geschichte geht es um ein Teammitglied, das momentan keine Aufgaben hat und daher herumsitzt und Däumchen dreht. Dieser Zustand soll natürlich abgestellt werden. Durch Nachfragen finden wir heraus, dass es sich um keine/n Entwickler/in handelt, sondern um eine Person, die testen soll (und hierin wohl auch gut ist). Das Mitglied erfüllt derzeit Administrationsaufgaben, erst langsam kommen ein paar geeignetere Aufgaben dazu.
Es handelt sich um eine Interne, die von Anfang an dabei ist. Das beschriebene Setting befremdet bereits beim Zuhören, die Auflösung kommt jetzt: Der Kunde wollte es so, dass die Person Mitglied im Scrum-Team ist. Kommentar eines Gastes: „Die sogenannten „Eh da-Kosten“ (Lachen in der Runde. Ein Silberrücken kontert beinahe fassungslos, er habe es noch nie erlebt in seinen 500 Projekten, dass jemand nichts zu tu hatte, ein anderer erfahrener Teilnehmer konstatiert Führungsversagen: „Warum kommen die ins Team?“ Die Verantwortung für den Fortgang der Geschichte liegt in diesem Fall beim Team selbst: Hilft Job Rotation („Welche Jobs müssen wir gut beherrschen, damit wir nicht in Stress kommen?“), das Team muss sich fragen, was das Beste ist, das es tun kann, um einen guten Job zu machen? (Nutzung bestimmter Tools, Pair Programming, kontinuierliche Verbesserung,…)
Der Themengeber betont, dass die Person auch gut sei. Trockener Kommentar eines anderen Teilnehmers, der im folgenden Satz seinen eigenen Namen einsetzt: „Ach - der X ist eigentlich ganz nett, aber der stoffwechselt eigentlich in diesem Projekt nur so vor sich hin…“ (kichert, gefolgt von Erheiterung unter den Gästen).
Von dritter Seite wird die Schwierigkeit betont, dass man sich – über all der Job Rotation und der Suche nach sinnvollen Aufgaben - ggf. nicht mehr auf den Sprint und dessen Ziel fokussiert, sondern dass immer mehr Personen an etwas anderem arbeiten. Man sollte sich wenigstens auf Aufgaben konzentrieren, die später noch anstehen.
Was zeichnet einen guten Scrum Master aus?
Interessanterweise herrschte nach Eröffnung dieses Themas erst mal Stille. Der Themengeber amüsiert: „Ist ‘ne langweilige Frage, hm? Seh‘ ich an Euren Gesichtern!“ (lacht, andere stimmen ein)
Der erste Teilnehmer zitiert Aufgaben wie „Selbstorganisation ins Team bringen, …“, woraufhin eine Teilnehmerin bemerkt, dass die Aufgaben ja klar seien, nicht unbedingt aber der Weg, wie man dort hinkommt. Als eigene Lösung wird angedacht: viele Fragen stellen, alles hinterfragen, sich nicht alles servieren lassen. Eine weitere Ansicht lautet, „auch im Konzernumfeld den Weg finden, wie er im Scrum Guide zusammengefasst ist“ (wenn der Schreiberling dieses Artikels da an sein eigenes Betätigungsfeld denkt: Das kann eine wahre Mammutaufgabe sein…)
Danach kommt ein ebenso überraschender wie zutreffender Beitrag: „Ein guter Scrum Master glaubt an das Team.“ Es ginge darum, das Team zu befähigen. „Wenn ich an das Team glaube, glaubt auch das Team irgendwann an sich selbst. Für mich ist das das wichtigste.“
Weitere Beiträge, die Gäste waren in Schwung gekommen: „Spaß daran haben, mit Menschen zu arbeiten, und dieses auch zeigen; viel das Verhalten im Team beobachten, auf einzelne Personen eingehen, sie ernst nehmen, die Fähigkeit haben zu begeistern; verbunden bleiben mit dem Team; Disziplin wahren, wenn man über mehrere Sprints hinweg zusammenarbeitet, nicht alles abflachen lassen, sondern am Ball bleiben.“
Nach dieser Zusammenfassung nach dem Ende des Artikels auch noch die Übersicht über alle Themen, die uns mitgebracht wurden. Wir danken wieder allen Gästen, die natürlich alle zum Gelingen der Veranstaltung beigetragen haben, und für die gute Laune, auf die sich das Organisationsteam jeden einzelnen Dienstag schon im Voraus freu.
Kommentare
Kommentar veröffentlichen