Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin 28

Die agile Szene trifft sich in verschiedenen Stammtischen und Meetups. Hier ist ein Bericht vom Lean Coffee Frankfurt/Karlsruhe bzw. Karlsruhe Frankfurt. Unsere Gastgeberin Doris Weißgerber hat die Session zusammengefasst. Es ist gut, wenn sich die agiles Szene untereinander vernetzt und sich gegenseitig hilft. Dazu dient dieses Lean Coffee, deren Mitglieder sich Dienstagsmorgens von 8-9 Uhr trifft. Wer dazu kommen möchte, darf sich gern in einer der entsprechenden Xing-Gruppe anmelden:

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

Beliebte Posts aus diesem Blog

Wie starte ich ganz konkret mit einem neuen Scrum Team?

Ich habe den Eindruck, dass manche Agilisten damit überfordert sind, schnell ein Scrum-Team aufzusetzen. Sie haben ein Seminar nach dem anderen besucht und kennen so viele Techniken und Methoden, dass sie am Ende gar nichts davon anwenden. Das war nicht der Sinn des Scrum Guides. Hier ist mein Vorschlag für einen Teamstart.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.