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

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.