Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pecha-Kucha: Scrum in Cool

241 views

Published on

Pecha Kucha-Vortrag auf der OOP-Konferenz am 24.01.2019.
Im Upload finden sich auch die Sprecher-Notizen, in der Hoffnung, dass es dadurch verständlich wird.

Published in: Software
  • Be the first to comment

Pecha-Kucha: Scrum in Cool

  1. 1. Langweiliges vs. cooles Scrum Stefan Roock stefan.roock@it-agile.de @StefanRoock Früher war es cool, mit Scrum zu arbeiten. Heute fühlt es sich häufig langweilig und Energie-arm an. Ich habe mich gefragt, wie es dazu kommen konnte und möchte euch mitnehmen auf eine Zeitreise, um dieses Phänomen zu ergründen.
  2. 2. Das geilste Team der Welt Es begab sich Ende der 1990er Jahre, dass die ersten Entwicklungsteams in Deutschland mit Scrum und eXtreme Programming arbeiteten. Fragte man zu jener Zeit die Teammitglieder nach ihrer Arbeit, sagten sie meist, sie hätten den geilsten Job der Welt. Fragte man die Kunden der Teams, so sagten sie, sie hätten das geilste Team der Welt.
  3. 3. Immerhin istes nicht mehrso schlimmwie früher. Seitdem sind 20 Jahre vergangen und haben ihre Spuren hinterlassen. Die Antwort auf die Frage nach dem Effekt agiler Entwicklung fällt in den meisten Unternehmen heute deutlich bescheidener aus. „Immerhin ist es nicht mehr so schlimm wie früher“ ist die häufigste Einschätzung. Dazu kommt häufig eine gewisse Resignation: „In der Realität geht es halt nicht anders.“
  4. 4. Back to the roots Wenn ich sowas höre, steigt mein Puls jedesmal ins Unermessliche. Wie kann man glauben, dass dieser fade Aufguss der ursprünglichen agilen Ideen das Bestmögliche sein soll. Wir können soviel mehr erreichen. Wir müssen nur aufhören, die ganzen Einschränkungen, die wir uns selbst auferlegt haben, als unveränderliche Naturgesetze anzusehen. Wir müssen uns und anderen wieder mehr zutrauen.
  5. 5. Ziel: der agile Kernzyklus Echte agile Teams begeistern ihre Endkunden. Dazu stehen sie im direkten Kontakt mit den Endkunden. Sie setzen nicht einfach deren Anforderungen um, sondern verstehen die Probleme ihrer Endkunden und gestalten dazu passende Lösungen, die sie direkt an die Endkunden ausliefern. Ich nenne das den agilen Kernzyklus.
  6. 6. Scrum als Hilfsmittel Scrum kann dabei helfen, den agilen Kernzyklus umzusetzen. Dort, wo sich Begeisterung nicht einstellen will, hat die Scrum-Mechanik häufig die Idee des agilen Kernzyklusses in den Hintergrund gedrängt. Da fordern Scrum Master von ihren Teams ein rituelles mit Blut unterschriebenes Commitment auf den Sprint, ohne gemeinsam darüber zu reflektieren, ob dadurch die Endkundenbegeisterung steigt.
  7. 7. Dieser methodische Dogmatismus zeugt davon, dass die disruptiven Ideen von Agilität und auch von Scrum nicht verstanden wurden. Man versucht, die ungezügelte Energie, die Agilität freisetzt, zu kontrollieren, zu zähmen. Anscheinend gibt es sogar Unternehmen, die sich explizit darauf spezialisiert haben, wie diese Xing-Anfrage an einen Kollegen zeigt.
  8. 8. Das erinnert mich dann doch alles sehr an die SODVo, die Selbstorganisationsdurchführungsverordnung, die am 1. April 2014 veröffentlicht wurde. Sie ersetzte mit sofortiger Wirkung die ungezähmte Auslegung von Agilität durch klare Regeln und schuf die Grundlage für Accounability.
  9. 9. *aus einer CSPO-Schulung In einem fernen Land erwacht aus einem Koma, unter einer Meta-Planwand ein umzertifizierter Product Owner. Sowas sollte in diesem Land auf jeden Fall verhindert werden und so schufen die Unternehmen klare Stellenbeschreibungen für Scrum Master und Product Owner. Denn ohne sowas läge schnell das ganze Land in Scherben.
  10. 10. Mitarbeiter Vorstand Abgrenzung So werden die Zuständigkeiten von Product Owner, Scrum Master und Entwicklungsteam mit viel Mühe und großer Genauigkeit festgelegt. Sonst macht nachher noch jeder, was er will. Natürlich hat der Vorstand auf seiner Toilette bessere Handtücher als der gemeine Untertan. Eine klare Abgrenzung ist von allergrößter Wichtigkeit, damit auch ja nichts die geregelten Bahnen verlässt.
  11. 11. Stories A-K Stories L-Z Epics A-K Epics L-Z ReleaseTrains A-F So wird genau geregelt, dass der Product Owner für das Schreiben der User Stories zuständig ist. Mit viel Akribie erstellt er die User Stories und achtet peinlich genau auf die Einhaltung des Satzschemas, der optimalen Formulierung der Akzeptanzkriterien und der Definition of Ready.
  12. 12. Die klaren Regelungen führen selten zu begeisterten Kunden. Es entstehen mitunter sehr seltsame Produkte, wie diese neuartigen Urinale, die sich immer häufiger auf Herren-Toiletten finden. Ich kann übrigens nur dringend von der Benutzung abraten. Das gibt eine Riesen-Sauerei.
  13. 13. Wir müssen uns von dem Glaubenssatz verabschieden, dass das Entwicklungsteam nur aus Kommunikationsbehinderten besteht, die man auf keinen Fall mit Endkunden sprechen lassen kann. Es ist keineswegs die Aufgabe von Product Owner und Scrum Master das Entwicklungsteam von der bösen Außenwelt abzuschotten und die Teammitglieder zu bemuttern.
  14. 14. Spezifikation Kontext Details, Fakten Bemutternde Product Owner erstellen Spezifikationen für das Entwicklungsteam. Spezifikationen sollen vollständig, widerspruchsfrei und korrekt sein. Sie sollen das zu entwickelnde Produkt möglichst genau beschreiben. Folgerichtig fokussieren Spezifikationen auf Details und Fakten.
  15. 15. Spezifikation User Story Kontext, Emotionen Details, Fakten User Stories hingegen sind Geschichten, die erzählt werden und diese Geschichten sollten im Dialog zwischen Kunden und dem Team entstehen. Auf diese Weise werden sehr viel mehr Informationen transportiert als es mit Spezifikationen möglich ist. Der Product Owner spielt dann nicht mehr stille Post zwischen Kunden und Team, sondern konzentriert sich auf seine Kernaufgabe: er optimiert den Produktnutzen durch Priorisierung der Produkteigenschaften.
  16. 16. das Team musiziert konzipiert So entsteht der Freiraum, den das Team braucht, um kreative Lösungen für die Probleme der Endkunden zu erschaffen. Ein agiles Team ist kein Orchester, das einer festgelegten Choreographie folgt. Ein agiles Team gleicht vielmehr einer improvisierenden Jazz-Band.
  17. 17. ein Produkt, ein Product Owner Wenn also die Teams die User Stories im Dialog mit den Kunden erschaffen und der Product Owner sich auf die Priorisierung konzentriert, vereinfacht sich skalierte Entwicklung mit mehreren Teams. Dann kann ein Product Owner das ganze Produkt verantworten und als Product Owner für mehrere Teams fungieren. Nicht ohne Grund heißt die Rolle Product Owner und nicht Team Owner.
  18. 18. Lasst uns also die Fenster unserer eigenen Denkbeschränkungen putzen - nur so aus Neugier, was wir dann sehen. Wenn wir neugierig bleiben, werden wir Probleme nicht mehr als Bedrohungen wahrnehmen, sondern als Lehrer. Und mit diesem Lehrmeister können wir herausfinden, wie wir Agilität in unserem Kontext zu voller Entfaltung bringen können.
  19. 19. "Wir müssen das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse VonGretWidmann(†1931),Gemeinfrei, https://commons.wikimedia.org/w/index.php?curid=208230 Hermann Hesse schrieb einst, wir müssten das Unmögliche versuchen, um das Mögliche zu erreichen. Teams, die direkt Probleme ihrer Endkunden lösen und so die Endkunden begeistern, mögen unmöglich erscheinen. Und trotzdem müssen wir es probieren. Ton Steine Scherben sangen: „Wir haben nichts zu verlieren, außer unserer Angst.“
  20. 20. Wo it-agile anpackt, wächst eine Organisation, die nachweislich Endkunden und Mitarbeiter begeistert. it-agile

×