Kalter Kaffee ist diese Nachschau, könnte man meinen. Manche Dinge brauchen eben etwas länger. Die Themen waren aber so interessant, dass sie, finden wir, mit der Nachwelt geteilt werden könnten. (Schnell noch bei Nacht und Nebel veröffentlicht, bevor schon der übernächste Lean Coffee stattfindet...)
Damit Ihr in Euren (künftigen) Lieblingsgruppen immer auf dem neuesten Stand seid, gerne hier anmelden (zumindest noch bis zum 31.12.2022, danach ziehen auch wir notgedrungen um):
https://www.xing.com/communities/groups/lean-coffee-frankfurt-am-main-99d1-1139176/about
https://www.xing.com/communities/groups/lean-coffee-karlsruhe-99d1-1139173/about
Sprint Goal - wie bestimme ich es, und wenn ja, wieviele?
Wirklich nur ein klitzekleines Sprintziel?
Wie kann man es schaffen, während der Einführung von neuen features nur ein einziges Sprintziel zu definieren? User Stories werden anhand des backlogs gewählt und können zu Prosa über das Sprintziel, unabhängig vom backlog, umformuliert werden. Manche Teams liefern im Grunde nur das "Standard-Commitment" ab, wird gefunden: Das Team sammelt Stories, die Sammlung der Stories entspricht dem Sprintziel.
Vision, Mission und Meilensteinplanung: Sind wir noch auf Kurs?
Die Vision, die Mission und die neudeutsche "Roadmap" müssten aber hervorgeholt werden, das Team muss eine Antwort darauf parat haben, wie das definierte Sprintziel jeweils darauf einzahlt. Maintenance z. b. wird in manchen Unternehmungen als Standardprozess gesehen, der ausgeführt wird, damit nach dem Sprint "alles läuft". Hierfür gebe es teils Abgesandte, die sich wie ein eigenes Team zusammensetzten und klärten, was getan werden müsse.
ReVIEW: Ein kritischer Blick auf das, was da ist
Der oder das Review als Termin, in dem man "zeigt, was man hat", wird zitiert. Software x existiert in Version y, und im Planning sollte überlegt werden, worin eine sinnvolle Erweiterung dessen bestehen könnte. Man nehme dazu von allem, was man kennt und weiß, das, was die Stakeholder sagen, das, was man außerhalb des Sprints nicht mitbekommen hat... Die Verbindung zu den Unternehmenszielen sollte immer wieder hergestellt werden. Es wird "überkreuz nachfragen" empfohlen: Entwickler:innen auf Business-Seite, das Business auf Entwicklungsseite nach sinnvollen Inhalten befragen, im Bereich der Maintenance auf Sicherheitslücken abklopfen, um nicht im Falle des Eintritts eines unerwünschten Ereignisses Feuerwehr sein zu müssen.
Scrum als Lern-Framework nutzen
Häufig sind Teams nicht glücklich mit ihren Sprintzielen, weil diese nicht mehr leiten und motivieren, sondern eine Zusammenfassung dessen sind, was man im Vorhinein aus dem Backlog gewählt hat. Auch das Ziel ist teilweise nicht ganz klar.
Auch hier zeigt sich wieder: Scrum ist kein Tool zur Abarbeitung, sondern ein Lern-Framework, man lernt immer dazu und erkennt, was für Probeme man als nächstes lösen muss. "Was müssen wir lernen, um einen Schritt nach vorne zu kommen?" Dies sei das Sprintziel - nicht alles wird allerdings dazu passen.
Der Leadership-Mythos...
"Es gibt zu wenig Unterstützung für Agilität in Unternehmen." - "Es wurde nie definiert, was 'agile leadership' ist, das ist für mich nur ein buzzword. Es kommt aus dem EBM-Guide, man muss es für sich und sein Unternehmen definieren und damit an die Führungsebene herantreten: Was bedeutet das in unserer Zahlenwelt? Auf den Menschen wird momentan nicht geachtet." - "Leadership ist leadership: Wer wo hin will mit anderen, muss es schaffen, dass die anderen ihm folgen."
Starke Beharrungskräfte auf Führungsebene
Nach Bob Emiliani, wird zitiert, habe es seit 200 Jahren in diesem Bereich keinen echten Fortschritt gegeben, die Beharrungskräfte auf Führungsebene seien so stark, dass man auf dieser Ebene nicht weiterkomme. Jemand anderes zitiert rühmliche Ausnahmen: "Die, die es geschafft haben, haben die Probleme der Mitarbeitenden ernst genommen, hatten eine klare Vision darüber, wo sie hinwollen.
Der einfache und der richtige Weg
Weitere Analyse aus der Runde: Es ist zu einfach, als klassische Führungskraft durch Entlassungen von Personen oder durch neue Produkte Geld zu verdienen, alles geschieht auf dem Rücken der Mitarbeitenden, "... machen die einfach!" Bei Großkonzernen wird beobachtet, dass die Steuerung, wer in der Hierarchie hochkommt, und wie, folgendermaßen aussieht: Auf D- oder C-Level braucht man ein Projekt, dessen Ergebnis am besten "brutal viel Kohle" als Einnahmen oder als Einsparungen bedeutet. Hochperformante Teams, Nachhaltigkeit, gut funktionierende Prozesse zahlen sich auf dieser Ebene aktuell nicht aus.
Leadership als Inspiration - Geschäft "nur" an zweiter Stelle
Ein anderer bestätigt: "Je mehr das Leadership/Management die Business- und Projektbrille trägt, desto schwerer ist dieser Personenkreis zu coachen. Was bedeutet leadership? Inspriration. Also sollte man eine inspirierende Persönlichkeit sein..."
Sobald ein Unternehmen das Business vollständig in den Fokus rückt ("wir möchten Geld machen!"), verliert es den Blick für seine Kernexistenz, warum es z. B. dieses Unternehmen ist. Es existieren Firmen, die das Geschäft an zweite Stelle rücken, sie interessieren sich für jede Handlung, die sie selbst ausführen, weil sie wissen, dass alles Einfluss auf das gesamte Unternehmen hat. (Leider rückte niemand eine Liste dieser Unternehmen heraus...)
Transparenz über den Fortschritt einer Scrum-Einführung
Über Prozesseffizienz und die Fragen "Was tun wir, und warum?"
Es geht darum, für den Scrum Master und sein Team sichtbar zu machen, wo man gemeinsam in der Scrum-Einführung steht. Scrum ist dabei kein Selbstzweck, sondern man will DAMIT (darüber) etwas erreichen; insofern ist es legitim, genauer darauf zu sehen, was man tut. 30% dessen, was ein Unternehmen tut, ist im Schnitt „dark work“, hat sich überlebt, wird nicht mehr benötigt. Nur 2/3 dessen, was erstellt wird, werden auch häufiger genutzt. Es wird vorgeschlagen, einmal nach dem Verhältnis von Bearbeitungszeit und gesamter Durchlaufzeit zu fragen. Prozesseffizienz bedeutet z. B., die Durchlaufzeiten halbieren zu können, ohne die Bearbeitungszeiten erhöhen zu müssen.
Teams als Spezialisierungsfalle
Teams seien oft eine Spezialisierungsfalle: Muss man nicht auf den einen Mitarbeiter warten, der als einziger bestimmte Dinge tun kann, die benötigt werden, gibt es mindestens einen Flaschenhals weniger. Über mehr multifunktional einsetzbare Personen erhält ein Team mehr Möglichkeiten, autonom zu handeln.
Es ist sinnvoll, wenn ein Team die Durchlaufzeit seiner Features kennt, und Messen der Prozesseffizienz hilft dabei, diese herauszufinden. Hierüber kann man erkennen, ob bzw. dass man Fortschritte macht.
Ist Scrum kompatibel mit CI/CD?
Continuous integration bedeutet, dass ein Team nach jeder Erzeugung eines neuen "Wertes" für den Kunden ein live-deployment durchführt, damit der Kunde direkt darauf zugreifen kann. In Scrum existiert nach dem Buche minimal ein Zwei-Wochen-Zyklus, innerhalb dessen entschieden wird, ob ein neuer "Value" das Problem des Kunden löst (und auf die Welt losgelassen werden sollte).
Review als Quality Gate: Deployment bei Bestehen
Jemand beschreibt den/das Review als quality gate: Eine neue Entwicklung löst ein Problem, und wenn die Akzeptanzkriterien erfüllt sind, geht man davon aus, dass man diese Entwicklung direkt deployen kann. Die Idee der Trennung von "deploy" und "release" wird aufgebracht: Eine Entwicklung ist bereits online, muss aber noch scharfgeschaltet werden, sodass sie sichtbar und nutzbar ist.
Werthypothesen und feature toggles
Es wird vorgeschlagen, mit Wert-Hypothesen (Hypothesen über den Wert einer Etwicklung für den Kunden) zu arbeiten. Auch für die Marktforschung sei dieses Element wichtig: Eine Gruppe bekommt schon das neue Feature zur Verfügung gestellt und testet, wie es sich auswirkt bzw. wie es arbeitet. Die Integration (das deployment) sollte mit Hypothesen verknüpft werden ("Was kann unsere neue Produktversion besser?"), dann könnten am Tag auch 20 bis 30 Integrationen durchgeführt werden. "Wenn man merkt, dass es Schrott war, kann man es auch wieder rausholen, man muss ausprobieren." Eine DevOps-Pipeline sei für solche Fälle optimal. Zum Thema mit der Neuentwicklung verknüpfbare Markttests erwähnt jeand "feature toggles": Es handelt sich um ausschaltbare Funktionalitäten, die zunächst nur bestimmte Personengruppen zu sehen bekommen. Auch Amazon arbeite auf diese Weise, um im Vorfeld herauszufinden, wo es "knallen" könnte. Die neuen Features werden für diese Personengruppen ausgerollt, und im Falle eines Störfalles wird der Prozess gestoppt.
Wissensmehrung als Sprintziel
Hier kommt wieder das Sprintziel in die Diskussion, das beantworten sollte: Was verstehe ich über den Kunden? (z. b. welche Produktseiten mag der Kunde, wie verkaufen wir also mehr? Lohnt es sich, weiterhin Geld für x auszugeben? Kann ich guten Gewissens am Thema y weiterarbeiten?) Auf die Frage, welche Kriterien die Definition eines Ziels beinhaltet, wird geantwortet: "Ich bin am Ende schlauer als vorher." Ein Beispiel: Ich möchte einen Marathon unter 4 Stunden laufen. Das Ziel ist dann "Marathon unter 4 Stunden". Nun gilt es, herausfinden, wie ich das schaffe. Wenn ich es versuche und nicht schaffe, woran liegt es dann? Sind es die Schuhe, die Mitläufer, das Wetter…?
User Story Mapping und Identifikation der inhaltlichen Klammer
Die Übung von Jeff Patton zum User Story Mapping kommt zur Sprache: zunächst werden alle Aktivitäten gesammelt, die dem Team einfallen zu "morgens fertig machen, um ins Büro zu gehen". Jetzt kommt die eingebaute Störung (der Wecker springt nicht an): Wenn man verschlafen hat, was macht man stattdessen? Was ist das Sprintziel? Was ist inhaltlich die Klammer? Warum würde man eher auf duschen verzichten, nicht aber auf Zähneputzen? -> Weil man in letzterem Fall Mundgeruch hätte. Warum sollte man sich überhaupt ankleiden? -> Man geht nicht nackt ins Büro. Das Sprintziel lautet also in etwa: "sozial verträglich aus dem Haus gehen und pünktlich im Büro sein".
An den Grenzen des Wissens experimentieren
Hier, so erfährt die Runde, trenne sich auch die Scrum-Master-Spreu vom -Weizen. Es geht darum, an den Grenzen des Wissens zu experimentieren ("Was hält uns davon ab, in der doppelten Geschwindigkeit zu arbeiten, ohne zu viel Kraft aufzuwenden? Was hält uns davon ab, weniger Fehler zu machen?") Ein Silberrücken berichtet uns, dass die Teams, die er erlebe, am Anfang immer nicht lieferfähig seien, sie erwarteten einen Zauberstab, kauften Externe ein. Das Ziel bestehe zunächst darin, die Lieferfähigkeit des Teams zu steigern, Software ohne Fehler auszuliefern, die der Kunde liebt. Er lasse Teams gleich in der ersten Woche etwas liefern (wobei diese ihm sinngemäß zunächst einen Vogel zeigten) und bestätigt, dass ihm tatsächlich alle etwas lieferten. Die Art der Fragen ändere sich: Anfangs sei alles unklar, der unnachgiebige Teilnehmer aber wolle von seinen Teams trotzdem etwas sehen. Idee dahinter: Das Team erkennt irgendwann den Punkt, an dem gute Vorbereitung nichts mehr nützt; dies ist der Moment, in dem das Team etwas MACHEN muss, um daraus wiederum etwas zu lernen. Ist die Anforderung unklar, muss man mit dem Kunden reden, damit sie klarer wird. Auf diese Weise baut sich ein Team sein eigenes spezifisches Wissen auf und lernt, wie es danach fragen muss, was der Kunde möchte. Als Beispiel wird der Aufbau von Produktseiten genannt, hier könne man viel lernen.
Auch im Review lauten die eigentlichen, die wichtigen Fragen: Was haben wir gelernt? Was müssen wir tun, um wieder einen Schritt nach vorne zu kommen? (Man vergleiche dies einmal gedanklich mit Reviews, in denen bestimmte Knöpfe im System nicht gedrückt werden dürfen, weil sonst das System in der Vorführung abstürzt [selbst bezeugt], oder sogenannte "Sprint-Demos", die den Termin "Review" vollständig verdrängt haben...[dito])
Infame Behauptung: Die Themen dieses Lean Coffees haben uns alle wieder einen Schritt nach vorne gebracht. :-)
Die Themen im Überblick
Übersichtliche Literaturhinweise
Leadership - als Video: https://www.youtube.com/watch?v=hO8MwBZl-Vc
https://bobemiliani.com/product/the-triumph-of-classical-management/; https://www.youtube.com/watch?v=5Ula8GliQek
https://www.amazon.de/Welcome-Problems-Find-Success-Creating/dp/1032065923/
Wir sagen allen Beitragenden verspätet schriftlich dankeschön für diesen tollen Dienstag!
Kommentare
Kommentar veröffentlichen