Transition Archive - Agile Growth®

16. März 20218. März 2022

Agilität einführen – Die Kunst der Agilen Transition in der Praxis

Wir konnten mal wieder die Klappe nicht halten 🙊, was die Einführung agiler Methoden betrifft. Vom Einzelteam zur größeren Landschaft teilen wir Erfahrungen, Muster und Bitte-Nicht‘s!

Zur Nachlese

Das agile Manifest – https://agilemanifesto.org

Enterprise Transition Community (Etc) Verständlich Erklärt – https://www.ksimons.de/2015/02/enterprise-transition-community-etc-verstaendlich-erklaert/

Open Space Agility https://openspaceagility.com/

Kotter – Resistance To Change https://www.youtube.com/watch?v=Wdroj6F3VlQ

Fearless Change: Patterns for Introducing New Ideas (English Edition) https://amzn.to/3bLcwQ3

Der systemische Blickwinkel auf Agilität – Susanne Mühlbauer im Interview https://agilegrowth.de/der-systemische-blickwinkel-auf-agilitaet-susanne-muehlbauer-im-agilegrowthcast/

🔥 Schreib uns an unseren Twitter-Kanal: https://twitter.com/AgileGrowthLive

14. Juli 202030. April 2021

Der Bull$h1t vom Agilen Mindset

Das Ziel einer agilen Transition ist nie Agilität an sich – sie ist nur ein Mittel zum Zweck. Doch muss ich dabei „ein agiles Mindset“ haben oder es gar entwickeln? Brauche ich Taschentücher, wenn ich keins bekommen habe? Und wohinter verstecken sich die meisten Agile Coaches? Wir philosophieren in den Allgäuer Bergen über Sinn und Unsinn dieses mentalen Konzepts – und stellen ein pragmatischeres Werkzeug vor, dass wir gerne nutzen.

Zur Nachlese

„Culture follows structure“ – Craig Larman – LeSS (Large Scale Scrum)https://less.works/less/structure/index

Das 8-stufige Veränderungsmodell von Kotterhttps://de.wikipedia.org/wiki/Veränderungsmanagement#Phasen_des_Veränderungsprozesses_nach_John_P._Kotter

Leadership Lessons from a Dancing Guy https://www.youtube.com/watch?v=3EKAxQbYA9U

Scrum Guide (fälschlich im Podcast „Scrum Reader“ genannt) https://www.scrumguides.org

5. Februar 2015

Enterprise Transition Community (ETC) verständlich erklärt

Der Weg hin zu einer agilen Organisation ist mit vielen Hürden und Problemen gespickt. Anforderungen, Ziele und Rahmenbedingungen ändern sich innerhalb von wenigen Tagen und Wochen.

Um so mehr Teams mit agilen Vorgehensweisen arbeiten, umso mehr Hindernisse auf Organisationsebene werden deutlich. Themen, die die Teams davon abhalten, effizient Software zu entwickeln und voranzukommen. Ungelöste Zuständigkeiten, unklare Rollenbilder und Karrierepfade, zu lange dauernde Entscheidungsprozesse, inkonsequentes oder nicht vorhandenes Portfolio- oder Programmmanagement.

Doch wie begegnet man dieser Komplexität, den Risiken und der Vielfalt der Stakeholder einer Agilen Transition?

Auch Software-Entwicklungsteams sind ständig mit veränderlichen Anforderungen und technisch sowie fachlicher Komplexität konfrontiert. Was für diese Teams funktioniert, ist auch bei einer Unternehmenstransition das Mittel der Wahl: Scrum. Durch seine mehrfachen eingebauten Feedback-Schleifen versteht es das Scrum-Rahmenwerk, die Komplexität zu adressieren. Eine Enterprise Transition Community kann so auf die häufig erst bei der Umsetzung auftretenden Hindernisse und Ideen eingehen und in kurzen Zyklen lernen, was funktioniert und was nicht.

Eine Gemeinschaft als Taktgeber für die Veränderung

Die Veränderung hin zu Agilem Vorgehen benötigt Menschen aus den unterschiedlichsten Bereichen eines Unternehmens.

Eine Enterprise Transition Community (kurz: ETC) ist ein Scrum-Team, dass die Transition hin zu agilem Vorgehen in einem Unternehmen durchführt.

Dieses Team arbeitet nach Scrum, produziert aber keine Software. Es liefert Organisationsveränderung in kleinen Schritten je Sprint. Es wurde von einem der beiden Begründer von Scrum, Ken Schwaber, im Jahr 2007 bekannt gemacht (siehe The Enterprise and Scrum) und seitdem in verschiedenen Variationen neu veröffentlicht und in etlichen Unternehmen praktisch eingesetzt (siehe z.B. BMC, EWE oder Amazon).

In dem hier dargestellten Prozess kommen auch die bekannten Artefakte und Rollen von Scrum zum Einsatz:

Product Owner – der Fokusgeber

Der Product Owner einer ETC trägt die Verantwortung dafür, dass das Team fokussiert an den Veränderungen mit dem höchsten Wert für das Unternehmen arbeitet. Er verwendet dazu ein Transition Backlog, welches die zu lösenden Organisationsthemen beinhaltet. In regelmäßigen Backlog Refinements werden die teils großen Organisationsveränderungsthemen (Epics) in Sprint-gerechte User Stories zerlegt.

Teammitglieder – Umsetzer und Gestalter

Die Teammitglieder sind Personen des Unternehmens, die ein Interesse an der Veränderung hin zu Agilität haben und sich einbringen möchten mit ihrer Zeit. Die Teammitglieder haben die Umsetzungsverantwortungen der organisatorischen Veränderungen. Sie sollten aus den Bereichen stammen, die maßgeblich von den Veränderungen betroffen sind und diese auch maßgeblich beeinflussen können. Am besten sie gehen die Themen selbst in der Umsetzung an. Falls es aber notwendig sein sollte, sollten sie dazu die Arbeit maximal eine Ebene delegieren, behalten aber die Verantwortung

ScrumMaster – Servant Leader und Facilitator

Der ScrumMaster einer ETC moderiert die Besprechungen, sorgt für das Prozessverständnis von Scrum und arbeitet an Lösungen von Hindernissen, die die ETC davon abhalten, hochproduktiv zu sein. Manchmal unterstützt er in Agilität unerfahrenere Teammitglieder bei der Vertiefung des Verständnisses und der Findung „agiler Lösungen“ für Organisationsthemen. Er dient dem Team und führt Kraft Anerkennung.

Die Organisation teilhaben lassen

Die Stakeholder einer Enterprise Transition Community sind oft breit gestreut im Unternehmen. Jeder betroffene Mitarbeiter und jede betroffene Führungskraft hat ein Interesse an den Ergebnissen dieses Teams. Nach einer anfänglichen Findungsphase der ETC sind sie gerne gesehene Feedbackgeber für „ETC Entwicklungsteam“ und ETC Product Owner im Review-Meeting.

Wer mehr zu dem Thema lesen möchte, empfehle ich die Szenen einer Scrum Transition (englisch), welche auch meine Abbildung inspiriert haben.

1. Oktober 2014

Ich bin jetzt Certified Scrum Coach.

Ich fühle mich geehrt. Seit letzter Woche bin ich einer von derzeit sieben Certified Scrum Coaches in Deutschland. Ich trete damit in eine weltweite Gemeinschaft von Menschen ein, welcher zum Beispiel auch Lyssa Adkins und Bob Hartmann angehören. Doch der Weg dorthin hat mich eigentlich schon die letzten sieben Jahre beschäftigt – wenn auch nicht bewußt. Warum bin ich ihn gegangen?

Mein Anliegen ist und war es, unsere Arbeitswelt gemeinsam zu verbessern.

Konkret: Herzliche Menschlichkeit und gesunde Wirtschaftlichkeit in Einklang zu bringen. Erfolgreich zu sein durch Kulturen des Vertrauens, der Offenheit, des Respekts und des Fokus. Gemeinsam mit Kunden, Partnern, Führungskräften und Mitarbeitern Ziele zu erreichen ohne dabei auszubrennen. Sinnhafte Arbeit zu gestalten mit konkreten Ergebnissen und dabei Freude an guten Lösungen und Produkten zu haben.

Die letzten zwei Jahre habe ich daher mit vielen weiteren Menschen intensiv gearbeitet, um mich jetzt Certified Scrum Coach nennen zu dürfen. Neben einer umfangreichen Darlegung und Bewertung meiner Coaching- und Beratungspraxis erfordert dies nachgewiesene Erfahrung in verschiedenen agilen Projekten sowie positive Kundenreferenzen. Durch das Feedback konnte ich über meine Arbeit reflektieren und erkennen, wie ich mein Anliegen in Zukunft mit Ihnen noch klarer umsetzen kann.

Vielen Dank für Ihre und Eure Unterstützung!

Großer Dank gebührt meinen Kunden, für das in mich gesetzte Vertrauen, dass ich mit ihren Problemen diskret, respektvoll und lösungsorientiert umgehen würde und ihre Bereitschaft, gemeinsam neue Wege zu gehen.

Ganz herzlich möchte ich mich an dieser Stelle auch bei meinen Kollegen Sabine Canditt, Peter Hundermark, Dr. Jürgen Hoffmann, Olaf Lewitz, Krishan Mathis, Sandra Reupke-Sieroux, Andreas Schliep, Mark Summers, Andrea Tomasini und der deutschen sowie internationalen Agile Community sowie der ScrumAlliance bedanken für Ideen, Erfahrungen, Mentoring und Feedback!

Sie fragen sich vielleicht, was ein Certified Scrum Coach eigentlich ist oder wie Sie selbst einer werden? Lesen Sie mehr dazu bei der ScrumAlliance.

22. Januar 2014

Neue Räume öffnen – Mit Open Space in agilen Transitionen

Wir sind häufig in Besprechungen. Oft mehrmals täglich. Unsere Kollegen laden uns ein, an wichtigen Themen zu arbeiten. Oder wir sie. Der Einladende entwirft eine Agenda, definiert ein Thema, stellt ein Problem zur Diskussion, möchte ein Ziel erreichen in einer vorgegebenen Zeit. Manchmal sind diese Besprechungen wirklich wichtig, oft nur teilweise informativ, manchmal versucht man aus Höflichkeit nicht zu laut zu gähnen oder gleich ganz zu entschlafen.

Das muss doch anders gehen. Wie wäre es, wenn wir das grundlegende Prinzip unserer Besprechungen umdrehen würden? Was passiert, wenn wir nur einen minimalen strukturellen Rahmen vorgeben und freiwillige Teilnehmer einladen, über ihre Lieblingsthemen zu reden? Wie wäre es, wenn man dabei nicht nur gehen könnte, wenn einen die Langeweile ergreift sondern sogar selbstverständlich geht, wenn man woanders mehr Beitragen kann? Und es sich dabei noch wie die längste Kaffeepause der Welt anfühlt?

Genau das ist ein so genannter Open Space:

Unter einem Open Space versteht man ein erprobtes Konferenzformat des selbstorganisierten Austausches, um in wichtigen Themen neue Ideen und Lösungen zu finden.

Seit 1985 gab es weltweit über 60.000 dieser Zusammenkünfte von manchmal nur 6 bis weit über 2.000 Personen. In allen möglichen Branchen wurden so neue Räume geöffnet für Lösungen und Innovationen.

In Deutschland trifft sich die agile Szene ebenfalls gerne auf diese Art und Weise. Denn es gibt viele Ähnlichkeiten zwischen agilem Arbeiten und einem Open Space:

Ein Facilitator erleichtert Selbstorganisation: Wie ein Agile Coach ist ein Open Space Facilitator jemand, der den Prozess sehr gut kennt und bei den Inhalten den Teilnehmern vertraut. Er unterstützt durch laterale Führung die Selbstorganisation aller, um gemeinsam bemerkenswerte Ergebnisse zu erreichen.

Und jeder gestaltet dieses Ergebnis mit. Denn ein Open Space lebt von dem, was die Teilnehmer mitbringen sowie eine Scrum Einführung von den Zielen und Wünschen der Teammitglieder und Organisation abhängt. Ohne Leidenschaft und Verantwortungsübernahme wird agiles Arbeiten schnell fade und langweilig, jede Besprechung zur Einschlafhilfe.

Informationen sichtbar machen, um zu entscheiden: In einem Open Space visualisieren wir die Themen des Tages an einem Anschlagbrett, ganz ähnlich wie ein Taskboard eines agilen Teams. So sieht jeder alle Informationen und kann die richtigen Entscheidungen treffen.

Wir dürfen Freiwilligkeit voraussetzen. Wer bei einem Open Space teilnimmt, ist nur da, weil er es möchte. Auch zu einer neuen Arbeitsweise wie Scrum kann man niemanden zwingen, das wäre ein Anti-Pattern.

Die Intelligenz der Gruppe nutzen: Wenn viele kluge Köpfe zusammenkommen, sind Lösungen komplexer Probleme leichter. Verschiedene Perspektiven der Intelligenz der Gruppe nutzt Scrum in seinen Besprechungen und Schätzverfahren. Im Open Space nutzen wir dieses Potential voll aus.

Fazit: Agile Transformationen und Open Spaces passen von ihrer Grundhaltung hervorrgangend zusammen, was auch die oben aufgezeigten Parallelen unterstreichen. Nutzen Sie die Kraft des Open Space in Ihrem Weg zum agilen Unternehmen.

Dan Mezick, der diese Idee beim Scrum Gathering Paris darstellte, zeugt auch von positiven Erfahrungen beim Einsatz von Open Space in agilen Transitionen und bemerkenswerten Ergebnissen.

Wann hatten Sie das letzte Mal ausgiebig Zeit, mit allen Ihren Kollegen zusammenzukommen, um intensiv die Themen zu besprechen, die Ihnen am Herzen liegen? Wenn das schon eine Weile her ist, dann probieren Sie doch einmal einen Open Space bei Ihnen aus! Und wenn Sie in einer agilen Transition sind, dann erst recht.

13. Dezember 2013

Scrum skalieren – Communities of Practice (CoP) verständlich erklärt

Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?

Softwareentwickler arbeiten nun in kleinen Teams von 5 – 9 Personen. ScrumMaster und Agile Coaches investieren viel Energie, diese Teams zu stärken und zu schützen. Im Laufe der Zeit entwickelt dabei jedes Team seinen eigene Definition davon, wie gute Softwareentwicklung aussieht und funktioniert.

Doch was ist mit Querschnittsthemen?

Wie koordiniert man gemeinsame Auslierferungen, an denen mehrere Teams arbeiten? Wie lernen wir teamübergreifend neue Softwareentwicklungspraktiken? Wie entwickeln wir Entwicklungsrichtlinien, die für alle Teams passen? Wo kommen Tester zusammen, um herauszufinden, was gute Qualität für sie bedeutet?

Wenn wir agil mit mehreren Teams arbeiten möchten, brauchen wir teamübergreifend einen Weg, solch einen Austausch zu gestalten. Eine Art von loser Interessensgemeinschaft aus Praktikern. Menschen, die freiwillig und aus Leidenschaft zusammenkommen – vielleicht wie wir Deutschen das so gerne in Vereinen tun (nur weniger bürokratisch)?

Vor über 20 Jahren beschäftigten sich die Sozialforscher Jean Lave und Étienne Wenger mit der Bedeutung von sozialen Konstrukten in Lernprozessen. Und sie formten den Begriff der „Communities of Practice“ – kurz: CoP.

Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.

Eine Teilnahme an solch einer Community ist immer freiwillig – und unabhängig vom bisherigen Wissensstand. Anfänger, Fortgeschrittene und Experten treffen sich regelmäßig, um gemeinsam zu lernen.

Wie beginnt man nun so eine Community of Practice?

Das ist leicht! Derjenige, der für ein Thema eine große Leidenschaft besitzt, sucht nach Gleichgesinnten im Unternehmen. Man legt gemeinsam erste Ziele fest und lädt alle interessierten Kollegen zu einem großen Willkommens-Termin ein. Dort informiert man dann über das Vorhaben und bittet die Teilnehmer, um Feedback, ob sie in Zukunft auch mit an Bord sind. Ein erfahrener ScrumMaster als Experte für Teamprozesse kann von Anfang an schon als Facilitator den Weg der CoP begleiten.

Wie sähe Ihre Firma mit solchen Lerngemeinschaften aus? Was wäre dann anders? Wer würde zu welchen Themen wohl im Austausch sein? Wenn Sie Lust bekommen haben, selbst eine Community of Practice zu Gründen oder Kollegen dabei zu helfen, mit ihrer Initiative erfolgreich zu sein, empfehle ich Ihnen dieses Buch. Und danach viel Spaß bei der Umsetzung! Denn gemeinsames Lernen macht uns doch oft am meisten Spaß, oder?

5. November 2013

Darf’s ein bischen mehr sein – Ist der ScrumMaster eine Vollzeit- oder Teilzeit-Rolle?

Besonders kleinere Abteilungen und Unternehmen auf dem Weg zur Agilität stehen gerade zu Anfang häufig vor der Herausforderung, keine Vollzeitstelle für die Rolle des ScrumMasters im Unternehmen zu haben. Eine Vollzeitstelle für einen ScrumMaster? Muss das wirklich sein? Kann das nicht auch ein Entwickler nebenbei machen? Oder wenigstens ein ScrumMaster für zwei Teams gleichzeitig?

Bei dieser Entscheidung sollte man betrachten, wie sich diese auswirkt. Die Konsequenzen, die sich oft hinter ihr verbergen, zeige ich hier auf.

Zwischen den Stühlen

Der Teilzeit-ScrumMaster hat in der Regel nur einen Teil seiner Arbeitszeit zur Verfügung, um die ScrumMaster-Rolle zu leben. Daraus resultierend ist die besondere Herausforderung, dass er einen ständigen Konflikt ausbalancieren muss: Welcher Rolle gibt er wann den Vorrang?

Ist er zeitgleich Entwickler im Team, kann er dann guten Gewissens sein Team an der Tastatur „hängen lassen“, wenn es eigentlich in puncto Teamentwicklung an der Zeit wäre, mal wieder einen aufwändigeren Workshop zu gestalten? Schafft er den Perspektivenwechsel, Teil des Entwicklungsteams und doch in einer vom Team absichtlich getrennten Rolle zu sein? Hält er durch, wenn ein Hindernis schwer zu lösen ist oder flüchtet er an die Tastatur, um das Erfolgserlebnis des Tages zu sichern? Nimmt er sich die Zeit, proaktiv sein Team zu fördern und zu fordern?

In der Praxis beobachte ich, dass Teilzeit – ScrumMaster Schwierigkeiten haben, einen Teil des Potentials der Rolle umzusetzen: Während Sie im Team einen sehr guten Job machen, fällt der Teil der Organisationsentwicklung in der Regel weg. Auch technisches Coaching (Refactoring, Unit Testing, TDD, …) wird üblicherweise nicht stattfinden, denn Prozess- und Technologiecoaching füllt schnell eine Vollzeitstelle aus.

Wie ist es nun, bei zwei Teams gleichzeitig? Der Balanceakt bleibt, nur verschiebt er sich auf die Frage, welches Team gerade wichtiger ist. Auch hier verzichtet das Unternehmen meistens auf die Dienstleistungen, die der Vollzeit-ScrumMaster der Organisation bietet.

Veränderung im Team und darüber hinaus

Für den Vollzeit-ScrumMaster gilt: Er kann seine gesamte Arbeitszeit einsetzen, um sein Team optimal im Verlauf der Produktentwicklung zu begleiten. Es ist genügend Zeit vorhanden um proaktiv und reaktiv zu handeln. Mit der steigenden Erfahrung des Teams verschiebt sich sein Tätigkeitsfeld mehr und mehr weg von der Arbeit am Team hin zur Organisationsentwicklung und Schaffung neuer Rahmenbedingungen: Er hilft bei der Gründung von Communities of Practice. Er unterstützt die Verkürzung von Release – Zyklen. Er gestaltet neue Karrierepfade mit. Er hilft anderen Gruppen im Unternehmen, die richtigen Kommunikationswege zu Scrum und Kanban – Teams zu finden. Auch andere Abteilungen interessieren sich häufig nach einiger Zeit für die „bunten Klebezettelchen“. Eine Einladung zum Dialog, die der Vollzeit-ScrumMaster einfacher aufgreifen kann und so Agilität weiter in das Unternehmen trägt.

Die Grafik zeigt nochmals die Kernaktivitäten, die Teilzeit- und Vollzeit-ScrumMaster in der Regel leisten.

Abhängig von dem Ziel Ihrer Scrum-Einführung können Sie nun entscheiden, welche Variante Sie wählen möchten. Wenn Ihnen das volle Potential agiler Methoden oder Ihr Projekt-/Produkterfolg sehr wichtig sind, empfehle ich Ihnen, diese neue Rolle als Vollzeitstelle zu schaffen.

Wenn Sie die Teilzeit-Option wählen, seien Sie sich der möglichen Konsequenzen bewußt – und es gilt sicherlich auch: besser ein erfahrener Teilzeit-ScrumMaster, der seinen Job ernst nimmt und beherrscht, als gar kein ScrumMaster.

8. Oktober 2013

Scrum Gathering Paris 2013 – Agiler Szenetreff am Eiffelturm

Wenn 400 Menschen aus 38 Ländern zusammenkommen, um ihre Leidenschaft für eine Arbeitsphilosophie zu teilen, dann muss es gut werden. Zwei Tage voller Workshops und Vorträge vergingen wie im Flug, die Abende in Paris profitierten vom Flair der Metropole.

Mein persönliches Highlight der Konferenz waren die Keynotes: Henrik Kniberg, der über Agilität im Großen bei Spotify berichtete. Eine Firma, die es durch ein geschicktes Skalierungsmodell geschafft hat, agil zu bleiben trotz massiven Wachstums. Keine leichte Aufgabe.

Dan Mezick folgte, der über seine inspirierenden Ansätze der Kulturveränderungen in verschiedenen Unternehmen berichtete. Sein Modell von agilen Transitionen präsentierte er unter der Kernfrage:

Wie schaffen wir es, dass Agilität langfristig bleibt?

An den Themen des Gatherings merkt man: Viele Firmen haben mittlerweile Erfahrung mit Scrum gesammelt – manche Firmen führen sogar Scrum zum zweiten Mal ein, weil sie die Agilität auf Ihrem Weg dann doch verloren oder die Einführung nur halbherzig begonnen haben. Die Fragestellung, wie Agilität dauerhaft in Firmen existieren kann, beschäftigt Firmen wie Community also intensiv.

Wichtige Eckpfeiler dafür sind das klare und dauerhafte Erleben der Vorteile agilen Arbeitens – auch auf der Ebene des mittleren und oberen Managements – und die kontinuierliche Verbesserung auf allen Ebenen des Unternehmens an die sich stetig verändernden Rahmenbedinungen.

Das Ziel der größten agilen Allianz bleibt spannend: Die Arbeitswelt zu transformieren (analog zum englischen Slogan: „Transforming the world of work.“).

Gut 90% der Mitarbeiter bei Spotify sind mit ihrem Arbeitsplatz sehr zufrieden. Welche deutsche Firma kann das von sich sagen?

Es gibt viel zu tun. Mit Agilität haben wir einen lohnenswerten Weg. Lasst uns gemeinsam das Morgen gestalten, in dem wir Arbeiten wollen.