CAS Agile Organisation

making your organisation agile

Perpetuum Mobile – LCM

Posted by Henry Dontschew on 14.12.2019

Die Zeit ist um und schon schreibe ich den letzten Blog-Beitrag für das CAS ‘Agile Organisationen’.
Diesmal steht das Lean Change Management im Fokus meiner Betrachtung. Doch bevor es losgeht möchte ich an dieser Stelle innehalten und einen kurzen Rückblick auf das Erlebt, Erfahrene und Erlernte machen.

Review:
In den vergangenen Wochen und Monaten drehte sich alles um das Thema Agilität und ich bin in die verschiedensten Facetten der agilen Welt eingetaucht. Einiges war mir bereits bekannt und vertraut. Andere Aspekte hatte ich schon mal gehört und wieder vergessen. Doch ein grosser Teil des im CAS vermittelten Inhalts und Eindrücke war auch für mich, der seit über 10 Jahren in agilen Teams lebt und arbeitet, völliges Neuland. An meiner Grundeinstellung zum Thema Agilität hat sich auch heute nichts verändert und ich glaube immer noch fest daran, dass eine agile Denkweise und agile Methoden künftig unseren Arbeitsleben prägen und weiterentwickeln werden. Doch die Reise zum ‘agilen Nordstern’ wird beschwerlich und übersät mit Stolpersteinen sein. Irgendwann jedoch haben auch die letzten verstanden das Hierarchien, Command & Control, reine Zielvorgaben, jährliche Mitarbeitergespräche und vieles mehr uns in der VUCA-Welt nicht weiterbringen.

Vielen Dank an alle Dozenten und Kommilitonen für diese lehrreiche Zeit, den Erfahrungsaustausch und die super Zusammenarbeit. Ich vermiss euch jetzt schon 😉

Lean Change Management:
Ein wichtiger Aspekt bei allen Agilitätsbestrebungen ist das Feedback. Denn ohne dieses sind wir “blind” in den Was und Wie wir etwas tun. Damit ist es auch nicht verwunderlich, dass wir Feedback-Loops überall in der agilen Zusammenarbeit wiederfinden. Sei es auf der persönlichen Ebene, der Team-Ebene oder innerhalb der gesamten Organisation. Menschen brauchen Feedback, um die unsichtbaren Flecken ihrer Wahrnehmung zu erkennen, zu lernen und um sich zu verbessern.

Der seit über 100 Jahren das Arbeitsleben beherrschende Taylorismus hat uns gelehrt, unsere Abläufe vorhersehbar zu machen, sie vorab detailliert zu planen, zu dokumentieren, umzusetzen und im besten Fall sogar abschliessend zu prüfen. Dieser Ablauf klingt einleuchtend und begegnet mir fast täglich in meiner Arbeit. Erst vor kurzen haben wir intern den Mini-Change “Kaffeemaschine zügeln” genau so geplant. Der Auslöser für dieses Vorhaben war eine Beschwerde unserer HR-Abteilung, welche in unmittelbarer Nähe zur Kaffeemaschine platziert war und sich durch die Geräusche des Mahlwerks und den an Kaffeemaschinen üblichen Mitarbeitergesprächen in ihrer Konzentration gestört gefühlt hat.
Das Leitungsteam hat sich daraufhin in mehreren Meetings zu diesem Problem Gedanken gemacht und beschlossen die Kaffeemaschine an einem anderen Ort im Gebäude zu zügeln und dieses Vorhaben akribisch geplant.

  • #1 – Eruieren möglicher Standorte (Anschlussmöglichkeiten, Erreichbarkeit, usw.)
  • #2 – Zeit- und Ressourcenplanung (Wann, Wer, Information an MA)
  • #3 – Abschätzen der möglichen Mitarbeiterreaktionen und Vorbereitung einer Argumentationskette, die das Vorhaben plausibel rechtfertigt und positiv “verkauft”
  • #4 – Planung des Abschluss-Meetings (Zusammenfassung der Mitarbeiterreaktionen und Validieren der Ergebnis)

Trotz dieser Spitzenleistung an Vorbereitung 😉 kam natürlich alles anders als erwartet. Schon nach der ersten Ankündigung, dass die Kaffeemaschine in ein anderes Stockwerk des Gebäudes verschoben wird, kam die ersten Reaktionen von Mitarbeiter. So meldete sich jemand und fragte, ob die Regelung : “Keine offenen Getränke im Treppenhaus” aufgehoben wird. Der Nächste hielt es für völlig unverhältnismässig und beschwerte sich über den Zeitverlust. Das Leitungsteam hielt natürlich an der Planung fest und die Kaffeemaschine wurde pünktlich durch den Abwart verschoben. Die weitere Story würde den Rahmen dieses Beitrags sprengen. Deswegen kürze ich an dieser Stelle etwas ab. Das Endergebnis des “kleinen” Veränderungsvorhabens war, dass neue Anschlüsse für die Kaffeemaschine durch den Elektriker verlegt werden mussten, der Schreiner entsprechende Möbel mit Entsorgungsmöglichkeiten anfertigen musste, Mitarbeiter ihren täglichen Kaffee in Thermoskannen mit an den Arbeitsplatz nehmen und sich daraus täglich lange Schlangen an der Kaffeemaschine bilden und auch Wochen später noch völliges Unverständnis darüber besteht was dieser Schritt an Mehrwert gebracht hat. Nur das HR, bestehend aus drei Personen, ist rundum zufrieden und holt den eigenen Kaffee aus der Kaffeemaschine, welche für Kundenbesuche auf dem Stockwerk verblieben ist.
Kurzum:

  • Die Vorab-Planung zum Was, Wie und Wie schnell wurde weder im Change Prozess geprüft noch angepasst.
  • Die Betroffenen wurden nicht mit einbezogen, fühlen sich übergangen und sind verärgert
  • Alle vorab erwarteten positiven Effekte blieben aus
  • Das Vorhaben wurde viel teurer als geplant

An diesem kleinen Beispiel wird deutlich warum klassisches Change Management so oft scheitert und eine Erfolgsrate von lediglich ca. 30%, wie verschiedene Studien zeigen, aufweist.

Organisationen und deren Bewohner sind komplexe adaptive Systeme, welche nicht vorhersehbar sind. Veränderungen können folglich nur mit Vermutungen und Annahmen darüber was passieren wird geplant werden. Genau hier setzt Lean Change Management an, indem es das Lean Startup-Prinzip auf Veränderungsmanagement überträgt.

Lean Startup:
Statt umfangreich mit theoretischen Wissen und Annahmen zu planen, setzt Lean Startup auf schnelle Iterationen. Ausgehend von Hypothesen soll gehandelt und aus dem Ergebnis gelernt werden, um das Erlernte in den nächsten Handlungsschritt einfliessen zu lassen.

(Start) Tue etwas. Schaue, was passiert. Ziehe Rückschlüsse daraus. Goto (Start)

Diese Idee des Lean Startups griff 2012 Jeff Anderson auf und übertrug es auf das klassische Change Management. Jason Little entwickelte den Ansatz von Anderson weiter und schuf einen eigenen offeneren Approach. Heute existieren verschiedene Ausprägungen des Lean-Change Management Ansatzes. (Quelle: Torsten Scheller auf agil-werden.de)

Wie auch beim Lean Startup finden beim Lean Change keine langwierigen Vorab-Planungen statt. Um zu starten bedarf es lediglich spezifisches internes Wissen aller am Veränderungsprozess Beteiligter in Form von Einsichten (Insights). Anhand dieser Einsichten können verschiedene Handlungsoptionen generiert und eine konkrete Veränderungsmassnahme selektiert werden. Die Umsetzung dieser Massnahme erfolgt experimentell und generiert neues Wissen, anhand dessen neue Einsichten entstehen, die ursprüngliche Option angepasst oder das Experiment beendet werden kann. Somit entsteht ein kontinuierlicher Kreislauf der Optimierung und Veränderung.

Auch wenn sich der Lean Change Cycle sehr strukturiert und linear präsentiert ist der Ablauf in der Praxis keineswegs so linear. Vielmehr kann das Vorgehen als “Dance with the System” betrachtet werden. Wie beim “echten” Tanzen auch, hängt der nächste Schritt von der Reaktion des Tanzpartners ab. Stolpert dieser, fange ich ihn auf. Dreht er sich in die falsche Richtung reagiere ich und korrigiere dies oder passe mich situativ der Bewegung an. Genau dies passiert im Lean Change Kreislauf. Die Reaktion des Systems in den einzelnen Schritten führt zu situativen Handlungen und einem neuen Vorgehen.

Anwendung in der Praxis:
Nachdem der ersten Halbtag im Lean Change Modul mit Pit absolviert war habe ich beschlossen das Erlernte in der Praxis anzuwenden.
Mein Teams bemängelte in verschiedenen Retrospektiven immer wieder, dass unsere Arbeitsweise nicht zielorientiert und fokussiert genug ist. Angespornt durch das CAS-Modul habe ich mein Team spontan zu einem gemeinsamen “Bier-Trinken” eingeladen und die Frage gestellt: Was müssen wir tun damit wir fokussierte werden und unser Sprintziel konsequent erreichen können?
Es entstand eine angeregte gemeinsame Diskussion, die uns zu verschiedenen Einsichten führte:

  • Unser Sprintbacklog ist zu diffus
  • Wir lassen uns von anderen betrieblichen Nebentätigkeiten zu sehr ablenken
  • Scrum ist die falsche Methode für uns
  • Wir sitzen zu verteilt (Grossraumbüro)

Mit diesen Insights haben wir an den darauffolgenden Tagen verschiedene Handlungsoptionen erarbeitet und gemeinsam bewertet, welche dieser Optionen wir als erstes umsetzen wollen und folgendes Experiment definiert:

Treiber:
Uns fehlt die Fokussierung um das Sprint-Ziel konsequent zu erreichen.

Hypothese:
Wenn wir unsere betrieblichen Aufgaben von unseren Projektaufgaben trennen und neben den Sprintbacklog ein Kanban-Board führen, sparen wir Zeit und können fokussierter und zielorientierte an der Erreichung des Sprintziels arbeiten.

Messen:
In jedem Daily Scrum beurteilt jeder die Wahrscheinlichkeit, dass wir das Sprintziel erreichen. (Diagnostik)
Über 3 Sprints hinweg messen wir, die Anzahl der offenen betriebliche Tickets im System und vergleichen dies mit den Vormonaten. (Metrik)

Ich bin gespannt wie dieses Experiment verläuft und welche neuen Erkenntnisse wir als Team für uns daraus ziehen können.

Quellen:
https://www.ionos.de/startupguide/gruendung/lean-startup/
https://www.lean-change.de/prinzip/
https://mindandmethods.com/lean-change-management/

Thx2Pit: it was amazing and exciting time

Posted in Agile Transformation, Knowhow-Transfer | Tagged: , , | No Comments »

Organizational Agility

Posted by Gils Glauser on 05.12.2019

Agility: The Circle of Organizational Life?

Ich schreibe diesen Blog im Advent 2019. Advent ist lateinisch und bedeutet Ankommen. Wir sind nun im Modul Organizational Agility angekommen.
Thomas Haas betonte in einem seiner Module, dass er bewusst schwarz-weiss malt. Möglichst keine Grautöne. Jeder muss selber die Grautöne für sein Umfeld bestimmen, denn Grautöne sind die Realität. Um zu erkennen weshalb man in diesem bestimmten Grau unterwegs ist, muss man zuerst wissen und erkennen mit wie viel Schwarz und von wie viel Weiss man gemischt ist. Wenn man nicht die klare Botschaft resp die Regel kennt, kann man sich nie verbessern und sich in ein neues zuversichtlicheres Grau bewegen (Shu-Ha-Ri: Kenne die Regel, bevor du sie brichst und eine neue, bessere für dich bestimmst).
Gespräche und Beobachtungen in meinem Umfeld zeigen mir, dass nicht jeder Mitarbeiter Agilität will, resp noch nicht reif dazu ist. Haltung entsteht aus einem persönlichen Reifungsprozess und kann nicht mit ein paar Trainingsmassnahmen eingeimpft werden. Wir landen also wieder bei der persönlichen Haltung der Mitarbeiter.
Ich hatte oft beim Zuhören das Gefühl, dass sich immer wieder der Kreis schliesst. Alles beginnt bei mir selber, bei meinem Mindeset, bei der persönlichen Agilität. 

Scale Agile: Dank agiler Organisationsformen zum wirtschaftlichen «Grossherzogtum»?

Wir wurden als Klasse durch eine faszinierende Simulation geführt. Sie soll den Nutzen von agilem Vorgehen in einer Organisation mit verschiedenen Teams mit je einem Product Owner erleben lassen. Nach dem Verteilen der Rollen und nach Erhalten der Aufgaben wurde eine erste Iteration des «Grossherzogtums»-Prototypen durchgeführt. Erkenntnis war, dass die Dimensionen der einzelnen Produktteile wie Häuser, der Kathedrale, dem Marktplatz, den Menschen u.s.w. keine Einheit zeigten. Zudem fehlten wesentliche Teile, oder wurden falsch umgesetzt.  
Vor der zweiten Iteration wurde mit einem gemeinsamen Austausch aller Beteiligten die Vision geschärft. Die Product Owner tauschten sich für die Details untereinander aus. Unklarheiten wurden angesprochen und geklärt. So floss das Wissen für die Realisierung der Produktteile durch alle Teams.
Das Geheimnis, dass beim zweiten Realisierungsschritt ein Passendes Ganzes entstand, lag in der gemeinsamen iterativen Herangehensweise und dass sich durch den Austausch über Teamgrenzen hinaus eine Produktvorstellung entwickelte. 
Yuval Noah Harrari,  ein israelischer Historiker, beschreibt in einem seiner Bücher die kognitive Revolution. Diese basiere auf Lernfähigkeit und kommunikativen Kompetenzen, welche dem Homo Sapiens das Erschaffen von effektiven Organisationsformen ermöglichten. Dank diesen dominieren wir nun das Ökosystem.
Könnte es sein, dass in Zukunft agile Organisationsformen das globale Wirtschaftssystem dominieren? Oder tun sie es schon? 

(Bild aus den Kursunterlagen)

Führung in agilen Organisationen: Übt jeder Führung aus?

Johann Weichbrodt hat zu Beginn seines Moduls die Behauptung geäussert, dass jeder in einer Organisation Führung ausübt.
Diese Woche habe ich es selber in meinem Umfeld erlebt. Die Situation war banal aber doch für mich beispielhaft.
Ich habe eine Liste mit Kostenstellennummern erhalten, welche nach einem bestimmten Schlüssel zugewiesen wurden.  Ich hätte meine Nummern einfach entgegennehmen können und die Sache wäre für mich erledigt gewesen. Sozusagen von oben verordnet. Im Wissen was der negative Impact nächstes Jahr sein kann, wenn diese Nummern nicht richtig zugewiesen sind, fragte ich nach, wie der Schlüssel zu verstehen sei. Noch während dem Erklären hat die Kollegin bemerkt, dass es auch ihr nicht ganz klar war. Via Finanz- und Entwicklungschef konnte sie die nötigen klärenden Massnahmen einleiten.
Der Entscheid lag bei mir. Ich hatte mich entschieden zu Fragen um Klarheit zu bekommen. Dies hatte Handlungen zur Folge (Betroffene einbeziehen und klären) was Konsequenzen mit sich brachte (neuer Schlüssel definieren, neue Listen erstellen und Betroffene entsprechend informieren).
In dem Sinn bin ich einverstanden, Führung ist verteilt (Gemäss Ed Schein distributed) und somit übt jeder Führung aus.  

(Slide aus den Kursunterlagen)

Pathologische Unternehmenskulturen: Krankheitsbild meiner Organisation?

Im Rahmen einer Gruppenarbeit mit Peter Marines galt es, die eigene Organisation einer «ärztlichen» Diagnose zu unterziehen.
Meine Organisation einzustufen war nicht einfach. Dramatisch, paranoid, schizophren, zwanghaft oder depressiv (gemäss Dr. Michael C. Funke)? Sicher, von allem ein bisschen! Ich habe mich wegen erkennbarem Führungsvakuum und hohem Spielraum in der Mitte für schizophren entschieden. Ich frage mich was eigentlich gesunde Führung bedeutet und welche «Tabletten» eingenommen werden müssen, wenn Führung fehlt.
In den Worten von Thomas Haas ist Führung immer dazu da Entscheide zu fällen. Entscheide haben Handeln zur Folge. Handeln führt zu Konsequenzen. Dies würde für mein Umfeld bedeuten, dass durch das Fehlen von Entscheidungen Handlungsunfähigkeit resultiert. Wie komme ich nun zu den nötigen Entscheidungen? Mein Teil dabei ist, die Informationsquellen bewusst zu suchen. Informationen wären wohl also die heilenden Tabletten. Mit Informationen kann man Argumentieren und eine Richtung aufzeigen um für meine Aufgabenbereiche Bewegung zu erlangen. Eine Konsequenz-Analyse kann dabei zu mutigen Schritten helfen.     Wenn ich es genauer überlege, ob schizophren oder ob anders dysfunktional ist nicht wirklich relevant. Die Übung hat mir aufgezeigt, dass ich kein Opfer einer “krankhaften” Organisation bin, sondern es an mir liegt mögliche heilende Wege zu finden, denn es gibt sie.

Posted in Organisation Agility | No Comments »

Agile Organisation – Beyond Portfolio

Posted by Marc Keiser on 05.12.2019

Damit das Folgende im richtigen Kontext gelesen werden kann, muss ich zuerst etwas ausholen. Ich arbeite in einer Wertschöpungskette mit rund 150 beteiligten Mitarbeiten und das Ganze nennt sich Projektgeschäft. Unsere Kunden unterliegen Gesetzen und Vorgaben, die sie erfüllen müssen (Man beachte den Imperativ!) und wir unterstützen die dahinterliegenden Prozesse mit IT Systemen. Die Planung zur Erstellung dieser digitalen Unterstützung bilden unsere Kunden in sogenannten Projektvorhaben ab. Diese werden in einem zentralen Portfolio geführt. Wer es noch nicht erahnt hat, dem sei hier bestätigt, dass die Kunden von denen ich spreche beim Bund eingebettet sind, namentlich im EJPD. Wie alle Departemente folgt auch das EJPD einer strikten Jahresbudgetierung. Ein Jahr ist in der IT bekanntlich der gefühlte Übergang der Kreide- in die Bronzezeit und weiter, hat sich mit abnehmender Halbwertszeit von Technologiewechseln gezeigt, dass sich die guten Absichten der Jahresplanungen im Dezember bereits im ersten Quartal nicht gerade als obsolet, aber mindestens gefühlt anders zeigt. Die Spannung zwischen den Extremen “Tradition, Kontrolle und Planung” auf der einen Seite und “Modern, Selbstorganisation und Experimentell” auf der anderen Seite, lässt sich sinnbildlich mit der Landung von Elon Musks Raumfahrtskapsel auf der Rütlischwurwiese vergleichen und ist wohl nirgends so frapant wie in der Bundesverwaltung.

Der geneigte Leser stellt sich vielleicht mitunter die berechtigte Frage, warum das überhaupt (m)ein Problem ist, daher versuche ich es wie folgt auf den Punkt zu bringen: Der Ansatz Unvorhergesehens zu meistern, wird in der Bundesverwaltung durch Bildung von Reserve angegangen. Damit soll die benötigte Leistung amTag x (wobei x ein unbekannter Tag im Jahr ist) , so sichergestellt werden, dass für das ganze Jahr Ressourcen eingeplant werden. Gute Idee eigentlich, den x ist ja irgendwo im Jahr enthalten. Aber gut gemeint ist noch nicht wirklich gut, oder? (Twinky). Der Effekt dieses Lösungansatzes liegt auf der Hand: Sehr teuer – das Warten auf Arbeit ist nicht gerade ein Kostenreduktionsverkaufsschlager – und ja, es weiss immer noch niemand, wann dieser Zeitpunkt x denn nun konkret im Jahr ist…

Transfer

Es gilt also zu erkennen, wann welche Ressourcen tatsächlich benötigt werden und wo aufgrund von Unsicherheit Reserve eingeplant wurde.

Damit ist für mich die Handlungsachse klar. Weder Sinn, noch die Rechtmässigkeit noch der Zweck verlangt ein Umdenken, sondern ausschliesslich der Beitrag [Quelle Unterlagen Haas]. Wir müssen Strukturen schaffen, welche der Inneffizienz der Reservenbildung entegegenwirkt.

Meiner Meinung nach, wirken folgende Aspekte in irgend einer Form auf das Wirkungssystem ein

  • Transparenz
  • Parallelität
  • Ressourcierungsprozesse
  • Disziplin
  • Vertrauen

Noch vor zwei Jahren konnten wir uns es leisten, Projekte völlig autonom zueinander zu betrachten und die Reservebildung aufgrund von Unsicherheiten waren deutlich kleiner. Natürlich hatten die dahinterliegenden IT-Systemen gewisse technische Zusammenhänge (Schnittstellen), aber Projektabwicklungstechnisch waren diese weitgehend losgelöst voneinander und damit auch besser entlang der Zeitachse planbar. Unser aktueller Portfolioressourcierungsprozess kann vereinfacht wie folgt dargestellt werden.

  • Vorhaben werden als Grössenordnung eingeschätzt -> Je höher die Unsicherheit, desto höher die eingeplante Reserven
  • Projektvorhaben werden gestartet, dann wenn erste Aktivitäten erkennbar sind (Unabhängig von Grösse (5 Personentage bis 2000 Personentage pro Jahr und Reife)
  • Projekt wird geplant -> Wasserfall und sehr Skill orientiert. Businessanalyst Jan – Feb, Entwickler Mrz-Aug, Integrator Sep, usw.)
  • Projekt wird ressourciert -> Sehr Skill fokussiert: Businessanalyst Jan-Feb 2h pro Woche, 3 Entwickler Mrz – Apr 40%, ..
  • Projekt wird umgesetzt -> Änderungen im Plan ziehen Replannings nach sich. Reserve wird ausgesessen oder zugunsten interessanter Features eingesetzt. Replannings betrifft zunehmend alle Projekte, mit denselben Ressorucen
  • Projekt wird abgeschlossen -> Zunehmendes Risiko, dass Replannings zu Verzug und höhere Kosten führen

Eine Chance könnte es also sein, den Portfolioprozess anzupassen.

Rahmenbedingungen / Voraussetzungen des Modells

Stehende Teams mit durchmischten Skills (z.B 7 Personen, 1 Methodiker (Scrummaster), 1 Fachowner (ProductOwner), 2 Experten mit Schwerpunkt Businessanalysten/Testing, 3 Fachspezialisten Entwicklung, 1-2 Fachspezialisten mit Sonderskill je nach Phase und/oder Typ von Projekt (z.B Architektur, Qualitätssicherung, Intergrator, usw.)

Stehende Teams können in einem höheren Kontext noch einmal gebündelt werden (Tribesansatz). Diese Bündelung haben wir bereits dieses Jahr eingeführt, bei uns heisst das Gefäss “Städte”. Bis anhin waren die Städte allerdings in erster Linie für das Reporting und die Diskussion um Ressourcen wichtig. Der Aspekt des Teilportfolios steht also noch aus.

Ich könnte mir als Big Picture dazu Folgendes vorstellen:

Vereinfacht gesehen, gibt es pro Ebene ein Kanban, mit Open, In Progress und Done/Cancel

Pro Ebene sollte es klare Strukturen, Regeln, Prinzipien geben welche die Übergänge regelt. In meinem Modell “zieht” (pull) jetzt jeweils die untere Ebene entlang der freigegeben und priorisierten Portfolioitems die Arbeiten und plant die Detailsschritte Ebenengerecht ein

Dazu würden die Beteiligten in einem Dialog mit Wissensträgern der benachbarten Ebenen treten und die Frage beantworten: “Was ist eine sinnvolle Reihenfolge zur Abarbeitung des Backlogs mit Blick auf’s Ganze?”. Die geplanten Detailschritte müssen Ebenengerecht sein und bilden die Basis zur Priorisierung der unteren Ebene.

Nach einem definierten Takt wird das Ergebnis konsolidiert und dient als Replanningsgrundlage der oberen Ebene. Dies ist der Magic Trick! . Die Reserve sollte damit in den Portoflios “stehenbleiben”, “parkiert” werden.

Ein möglicher Zeitplan/Takt pro Ebene könnte auf die Jahresplanung der Bundesverwaltung ausgerichtet sein. Die Teams haben zwei Wochen Intervalle und die Städte haben Monatsintervalle, was dem Controlling der Bundesverwaltung entspricht. Synchronistation auf Stufe der Ämter als Auftraggeberschaft wären quartalsweise im Sinne eines “Big Room Plannings” 4 Mal jährlich.


Posted in Organisation Agility | No Comments »

Mehr “Darf”, weniger “Muss”.

Posted by Michael Bolliger on 04.12.2019

Transformationsstrategie CAS, 29.11. 

Ein Transfer auf der Schnittstelle zwischen den Modulen «Organizational Agility» und «Agile Transformation». Im Zentrum stehen die Überlegungen zum Change von «Pflicht» zu «Verantwortung» und Methoden aus «Lean Change Management». 

Strategie-Ziel  

  • Die Mitarbeitenden sind aktiv in den Zielsetzungsprozess der Abteilung einbezogen und übernehmen ihren aktiven Teil zur Verantwortung der Zielerreichung. Die Pflicht (Muss) ein Ziel zu erfüllen, wird zur Verantwortung (Darf). 

Mehrwert:   

  • Mindset-Change.   
  • Kompetenz-Effektivität.   
  • Aktives Verantwortungsverständnis  
  • Zeitgemässes Partizipationsverständnis.   
  • Eigen-Motivation.   
  • Vertrauensbildend  

WOZU (was will ich bewirken):  

Mit dem Prinzip aktive Verantwortung richten die Beteiligten ihr eigenes Handeln selbstmotiviert an den Zielen der Organisation aus.  Sie sind in der Lage, die Verantwortung für ihren Beitrag zur Zielerreichung ihres Teams zu übernehmen und tun das auch. Die Gesamtredaktion kann von Kompetenz der Mitarbeitenden stärker profitieren. 

WARUM – Vier Gründe:  

Insights: Sparmassnahmen in der Abteilung (AL) führten seit 2018 dazu, dass die Abteilungsleitung über deutlich weniger Ressourcen verfügt als noch vor zwei Jahren (1,6 FTE statt 2,4). Der aktuelle Strategieprozess des Unternehmens verlangt zudem, dass die Mitglieder der AL aus Bern regelmässig am Hauptsitz in Zürich an Sitzungen, Workshops etc. teilnehmen. Deshalb hat sich die Präsenz der AL-Mitglieder im Alltag in Bern deutlich verringert. Am meisten sichtbar ist das in der publizistischen Führung, konkret der Feedback-Arbeit. Das früher tägliche Feedback der Chefredaktion auf die Sendungen ist auf ein bis zwei Termine pro Woche reduziert worden, die restlichen Termine wurde nicht ersetzt. Das wird von vielen MA als Gleichgültigkeit gegenüber ihrer Arbeit und als Abbau der Qualitätssicherung gewertet. Diese Wahrnehmung wirkt für viele demotivierend. 

Need: Wir brauchen ein Modell, das die hierarchieorientierte Kultur – ein Feedback ist nur „richtig“, wenns vom Chef direkt kommt – überführt in eine Praxis, die den Mitarbeitenden Feedback-Verantwortung und -Kompetenz überträgt und die Akzeptanz dieser Kompetenzübertragung unter den Mitarbeitenden fördert.  

Insights Die Entwicklung digitaler Formate verlangt neue Kompetenzen, die im Kader der Abteilung (Abteilungsleitung und Redaktionsleitungen) kaum vorhanden sind. Jüngere, digitale ausgebildete Mitarbeitenden besitzen diese Fähigkeit häufig. Damit wird die traditionelle Idee, dass „der Chef“ alles besser können müsse, obsolet.  

Need: Wir brauchen auch aus Gründen der Kompetenz- und Qualitätssicherung in neuen Bereichen ein Modell, das jüngeren MA mehr Fachführungskompetenz und Gestaltungsspieltraum gibt.  

Insights: Es gibt in der Abteilung ein über viele Jahre entwickeltes Autonomie-Verständnis der einzelnen Teams. Das ist teilweise begründet in unterschiedlichen Aufgaben und publizistischen Konzepten, andererseits in unterschiedlichen Organisationsformen. Die negative Begleiterscheinung dieser Autonomie zeigt sich im fokussierten Blick ausschliesslich auf das eigene Team und Produkt. Ein Verständnis für vernetzte Denkweisen, gegenseitiges Verständis und koordinierte Planung, beispielsweise bei Gross-Projekten einer Redaktion, fehlt fast vollständig. Das ist weder oekonomisch noch publizistisch sinnvoll und verwehrt allen Mitarbeitenden den Blick auf das gemeinsame Ganze.  

Need: Wir brauchen ein Modell, das allen Tesams gegenseitig den Stand der Projekte und Planung zeigt und damit auch das vernetzte Bewusstsein im Haus fördert. 

Insights: Der Wunsch nach Mitsprache- und Mitgestaltungsmöglichkeiten bei den Mitarbeitenden ist in den letzten Jahren spürbar lauter geworden. Das Unternehmen ist einem tiefgreifenden Wandel unterworfen. Durch den Eindruck an der Basis, die Unternehmensführung (damit sind auch die Kader in unserer Abteilung in Bern gemeint) plane den Wandel im Alleingang, abgekoppelt von der Basis, hat sich ein Klima des Misstrauens und der Demotivation gebildet. Gleichzeitig entwickeln sich Machtkämpfe in alle Richtungen (zwischen den Teams und zwischen der Basis und der Führung) um Ressourcen, Deutungshoheit in Qualitätsfragen etc.   

Need: Wir brauchen ein Modell, das den Mitarbeitenden an den richtigen Stellen Kompetenzen und Gestaltungsmöglichkeiten überträgt, ohne damit die Unternehmensziele in Frage zu stellen, respektive die Erreichung zu gefährden. 

Beitrag des Change:  

Durch die Entwicklung vernetzter Planung und aktiver Verantwortung können gewisse Abläufe effektiver gestaltet, die Motivation der Mitarbeitenden und damit auch die Qualität gesteigert werden.  

Option: 

Die Mitarbeitenden übernehmen die Autonomie, ihre Ziele (tbd), Massnahmen und Messgrössen selber zu formulieren und erklären sich damit auch für die Erreichuing selbsverstantwortlich. 

Experiment: 

Wir beginnen mit einem ersten Schritt und führen im Jahresziel-Prozess die WOOP-Methode ein. (Die Teilnahme der Teams ist freiwillig, die Teamleitung entscheidet in Absprache mit dem Team über die Teilnahme im Test. Ein Team, das nicht in den Test einsteigen will, bleibt beim bisherigen Muster, die Abteilungsleitung gibt ihnen die Ziele konkret vor. ) 

  • WISH Wohin willst du?  
  • OUTCOME Was ist das Ergebnis/die Wirkung der Veränderung?  
  • OBSTACLES Was sind die Hinternisse (und wer kann ev. helfen sie zu überwinden)?  
  • PLAN Mit welchen Massnahmen und Terminen erreichst du das Ziel?   

Der Rahmen ist gegeben, durch die Gesamtstrategie und die Jahresziele, die Abteilung von der Unternehmensführung erhält. Die Abteilungsleitung und die Test-Redaktion beschreiben mit der WOOP-Methode je zwei Ziele mit der sie ihren Beitrag zum Erreichen des Jahresziels leisten werden. Die einzelnen Mitarbeitenden halten mit der gleichen Methode ihren individuellen Beitrag zuhanden der Teamleitung fest.  

Messgrössen /Beobachtbares Verhalten  

1) In einem gemeinsamen Meeting präsentieren die Teams inkl. Abteilungsleitung ihre Beschlüsse und ihre Schritte dazu den anderen. Spielregel: Die jeweilige Zielsetzung ist erreich- und messbar und mit Massnahmen versehen, sie betrifft den Kompetenzbereich des jeweiligen Teams und zeigt einen konkreten Beitrag zum Gesamtziel.  

1a) Die Abteilungsleitung kann, wenn das Gesamtbild vorliegt, allfällige Defizite feststellen und ggf. zusätzliche Massnahmen einfordern.  

2) Die Schritte zum Ziel sind terminiert, zum Beispiel auf Schritte pro Quartal. Zu vereinbarten Daten treffen sich AL- und Team-Delegationen und beschreiben den aktuellen Entwicklungsstand, respektive Massnahmen um Defizit zum Plan aufzuholen.   

3) Innerhalb der Teams gilt der gleiche Ablauf.  

Zusatz: 

Die Abteilungsleitung kann auch entscheiden, dass der Prozess anders eingeteilt und beispielsweise statt mit Jahres-, mit Quartalszielen gearbeitet wird. 

 Allfällige Ausbildungs- oder Entwicklungsmassnahmen werden vom Management (Stab und Controlling) innerhalb der Budget-Kompetenzen beschrieben und terminiert.  

Vorteil der Methode:  

  • Die Ziele werden – aufgrund der Selbsteinschätzung der MA und Teams – realistisch/erreichbar.  
  • Die Ziele sind – dank der Kompetenzen der MA – stärker die neuen Anforderungen ausgerichtet. 
  • Die Idee der Transparenz impliziert auch gegenseitige Rechenschaft  
  • Die MA bringen sich in die Lage, Verantwortung für ihre Zielerreichung zu übernehmen.  
  • Das Vorgehen ist transparent, was das gegenseitige Verständnis und Vertrauen steigert.  
  • Gegenseitige Unterstützung, aktiv oder passiv ist gegeben und damit Partizipation realisiert.  
  • Die Methode ist einfach und sogar mobil anwendbar (WOOP-App) 
  • Sie ist unabhängig von der Grösse der Organisation und beliebig auf weitere Bereiche des Gesamtunternehmens skalierbar.  

Meine Revolution (Faust): Aus einer tw. noch recht traditionellen Organisationsstruktur (4-5 Hirarchiestufen zwischen Spitze und Basis) mit teilweise tribalen Unterelementen (kleinen Fürstentümern) bildet sich eine integrale-evolutionäre Organisationskultur.   

Mein Strukturbruch: Die Führung gibt ihren hierarchisch geprägten Anspruch auf dauernde Kontrolle auf. Die MA verpflichten sich, statt passiv aktiv zu werden und die Verantwortung für ihr Tun selber zu übernehmen.   

Meine Idee auf der Bewusstseinsebene: “Ich bin Teil des Ziels”  

Meine Vision: Selbstverantwortung löst Kontrolle ab.  

Zweck:   

  • Die gesetzten Ziele sind erreicht  
  • Die publizistischen Leitlinien (Qualitäts-Benchmark) werden nicht gebrochen, sondern im Einzelfall diskutiert (auf Zuruf mit der publ. Leitung)  
  • Absenz der Abteilungsleitung ist nicht mehr Begründung für Konflikte, sondern wird als Teil der Zielerreichung akzeptiert.  

Wie stärke ich Kostbarkeiten  Wir haben zwei wichtige Ressourcen im Haus:

  • Identifikation mit dem Sinn der Organisation (Service Publique)  
  • Inhaltliche Kompetenz  

Diese beiden Superkredits werden durch das Vorgehen nicht tangiert, respektiert langfristig gestärkt durch die Motivation der Beteiligten.  

Posted in Knowhow-Transfer | No Comments »

Transformation der Transformation Willen?!?

Posted by Stefan Winistörfer on 01.12.2019

Zeit – sehr viel Zeit ist notwendig

Zeit – sehr viel Zeit ist notwendig, um eine Vision zu entwickeln oder besser eine Vision zu vermitteln. Soll doch eine Vision von vielen Menschen verstanden werden. Denn nur mit einem gemeinsamen Verständnis kann erreicht werden, dass sich eine Organisation (oder ein Team) in die Richtung der Vision bewegt.

Auch für die Umsetzung einer Vision wird viel Zeit benötigt. Leider wird der Faktor Zeit bei einer Transformation oft unterschätzt. Diesem Umstand sollte sich das Management einer Unternehmung und mit ihm die ganze Führung bewusst sein. In meinem aktuellen Umfeld stelle ich an mir selbst fest, wie viel Zeit (und Aufwand) notwendig ist, um die Betroffenen zu Beteiligten zu machen und ihnen zu erklären, wohin die Reise gehen soll. Wie in meinem Blog-Eintrag zum Thema Organisational Agility schon geschrieben, soll und muss es immer auch um die Menschen in der Organisation gehen. Wie sich dieser Zeitbedarf mit den restlichen Aufgaben in meiner aktuellen Funktion deckt, muss ich in verschiedenen Gesprächen mit meinen Vorgesetzten klären.

Gemeinsames Verständnis mit Canvas

Die Methode der Canvases war mir nicht ganz neu. Jedoch habe ich sie in der Vergangenheit etwas aus den Augen verloren und nicht wirklich angewendet. Dank dem Input im aktuellen Modul Agile Transformation ist mir wieder bewusst geworden, wie hilfreich ein Canvas sein kann, um ein gemeinsames Verständnis zu erreichen. Als Projektleiter mit langjähriger Erfahrung habe ich immer wieder feststellen müssen, dass es zu Beginn eines Projekts äusserst schwierig ist, ein gemeinsames Verständnis für das zu erreichende Ziel (oder den Nutzen) zu entwicklen. Ein Canvas hätte mir vermutlich schon oft gute Dienste geleistet.

Ich werde in unserer Firma den Chef Projektmanagement kontaktieren und ihm vorschlagen, dass wir eine kleine Schulung zum Thema Projekt-Canvases aufbauen. Ich bin gespannt auf die Feedbacks der Projektleitenden.

Priorisierung – die grosse Herausforderung

Im zweiten Halbtag des Moduls Agile Transformation hat uns Pit eine mögliche Variante zur Priorisierung vorstellt. Diese Variante hat mich sofort begeistert und hat mich dazu bewogen, dies als Hilfsmittel mit in meine Unternehmung einzubringen, um den Product Ownern eine Hilfestellung bei ihrer Arbeit zu geben.

Adaptierte Einteilung zur Priorisierung (Quelle: CAS Agile, FHNW, 11/2019, Notizen Stefan)

In Abwandlung der vorgestellten Variante von Pit könnte ich mir vorstellen, dass es helfen kann, den Nutzen für die Menge der Bedarfsprojekte als eine Betrachtungsachse aufzuführen.

Die persönlichen Bedürfnisse des Einzelnen

Der Flyer-Ausschnitt des SCARF Modell von Andreas Diehl (www.digitaleneuordung.de) zeigt mit verschiedenen Handlungsvorschlägen schön, welche Möglichkeiten sich bieten, die Grundbedürfnisse der Menschen abzudecken bzw. die einzelnen Dimensionen zu unterstützen.

SCARF Modell mit Handlungsvorschlägen (Quelle: https://digitaleneuordnung.de/blog/scarf-modell/)

Das Grundprinzip von Belohnung oder Bedrohung ist tief im Unterbewusstsein eines jeden Menschen verankert. Wenn es mir als Vorgesetzter oder Verantwortlicher gelingt, in meinem Umfeld die “Belohnungsbereiche” zu unterstützen, so kann es gut sein, dass die angestrebte Veränderung auf weniger Widerstand trifft. Es ist jedoch wichtig, die Menschen als Individuen zu betrachten und entsprechend individuell zu “behandeln”. Das ist ja auch das Interessante im Umgang mit Menschen.

Wichtig ist, sich selbst immer wieder zu reflektieren. Auch bei mir selbst stelle ich immer wieder fest, dass sich meine Bedürfnisse je nach Situation oder auch aktueller Befindlichkeit (= Tagesform) ziemlich unterschiedlich sein kann. Vergleiche dazu mein SCARF Modell vom 07.12.2019:

Meine Bedürfnisse nach dem SCARF Modell (Quelle: CAS Agile, FHNW, 12/2019, Notizen Stefan)

Viel Energie notwendig

Nicht nur viel Zeit sondern auch viel Energie ist für eine erfolgreiche Transformation notwendig. Klar, Zeit und Energie stehen durchaus in einer gewissen Abhängigkeit.

Aber auch beim Investieren von Energie gilt es, zu priorisieren. Will und soll man in die Immovables Energie investieren? Und wie viel soll man investieren?

Movers, Movables, Immovables / Figure 1 (Quelle: http://www.helpingyouengineeryourfuture.com/change.htm)

Movers, Movables, Immovables / Figure 2 (Quelle: http://www.helpingyouengineeryourfuture.com/change.htm)

Wie in der obigen Abbildungen gemäss der Einteilung von Stuart Walesh dargestellt (vgl. http://www.helpingyouengineeryourfuture.com/change.htm), so teile ich die Meinung nicht unendlich viel Energie in die Gruppe der Immovables zu investieren. Viel mehr soll in die Movers investiert werden. Diese können dann die Movables mehr und mehr mitziehen und werden dann hoffentlich zu Movers.

Finale

Das war es nun also fast mit dem CAS Agile Organisation. Bald schon geht ein intensives Kapitel in meinem Lebenslauf zu Ende. Viele bekannte Themen konnte ich mit mir geläufigen Sichtweisen betrachten. Aber oft sind neue oder unbewusste Sichtweisen aufgetreten. Diese Sichtweisen haben mich persönlich und auch beruflich bereichert.

In viele Sichtweisen und Themenbereich muss und will ich jedoch noch mehr Zeit und Energie investieren, damit ich die aktuellen beruflichen und dadurch auch persönlichen Herausforderungen meistern kann. Das tönt jetzt nach ziemlichem Druck. Ich freue mich jedoch, die verschiedenen Themen noch mehr zu vertiefen und mich damit auseinanderzusetzen. Denn es macht mir viel Spass, Menschen und Organisation zu bewegen.

Ein letzter Transfer zum erfolgreichen Abschluss, die Projektarbeit, ist noch zu leisten. Dann ist das CAS Agile Organisation auch schon wieder vorbei.

Es war eine intensive Zeit. Das Investment hat sich aber für mich persönlich gelohnt. Ich freue mich auf weitere Changes und Transformationen 🙂

Posted in Agile Transformation, Knowhow-Transfer | Tagged: , , | No Comments »

Organisation der Agilität

Posted by Moritz Schwegler on 30.11.2019

Im letzten Blog habe ich euch die Welt der persönlichen Agilität näher gebracht. Ihr wisst jetzt also, den Blogs chronologisch folgend, was agile bedeutet, wie wir eine kleine Gruppe Menschen agilisieren können und wie wir uns selbst agil analysieren und weiterentwickeln können. Das alles führt zu der Frage: Wie kann man die Agilität im grossen Stil anwenden, zum Beispiel in einer Organisation?

I am agile, you will be agile so now we are agile.

Die älteste Form einer Organisation findet sich im Aufkommen der ersten Armeen, mit dem Ziel das Volk zu schützen, das Heimatland zu beschützen und im “Notfall” auch zu erweitern. Diese Organisationsform ist bis heute vorhanden, hat sich aber in weitere Bereiche der Gesellschaft weiterentwickelt und der Begriff “Organisation” wird im allgemeinen Volksmund mit Unternehmen in Verbindung gebracht. Unternehmen gibt es genügend, was aber definiert ein agiles Unternehmen? Diese Frage soll beantwortet werden aber zuerst ein wenig (trockene) Theorie, was es denn überhaupt für Organisationsformen gibt. Dazu erinnere ich euch an die Memes au der persönlichen Agilität, denn diese machen nicht bei euch halt sondern dringen auch in den Bereich der Organisationen ein. Die Farben und ihre Charakterzüge lassen sich somit auch auf Unternehmen übertragen. Nehmen wir beispielsweise die älteste Organisationsform: die Armee. Diese bildet nämlich direkt eine Ausnahme zu den PersönlichkeitsMemes denn hier spricht man anstatt blau (persönlich) von bernsteinfarben (Organisation). Die Eigenschaften sind weitestgehend gleich mit der Definition von formalen Rollen und Prozessen. Ich habe bereits Unternehmen erlebt, die durch den Wandel der Zeit und durch die Managementstufen einen wahren Regenbogen aufspannen könnten. Entstanden als ein Familienunternehmen wurde eine starke werteorientierte Kultur mit starkem Empowerment gelebt. Es entstand eine Art Kult um den Inhaber, die Mitarbeiter waren bereit alles zu geben für den Erfolg des Unternehmens. Während dieser Phase wurde eine Kulturoffensive gestartet um diesen “Kult” durch Empowerment der Mitarbeiter zu ersetzen. Noch während dem Wandel der Kultur wurde durch den Rückzug aus dem aktiven Geschäft und dem Wechsel in den Aufsichtsrat, das familiengetriebene, grüne ersetzt durch das orangene Meme der Innovation und Leistungsprinzip und zuvor bereits im mittleren Management entstandene bernsteinfarbene Suborganisationen haben an Macht gewonnen.

We are pioneers

Basierend auf dem grünen Meme entstand eine Pionierkultur, der Inhaber steht als Pionier im Mittelpunkt, der Kunde ist Priorität Nummer 1 und um seine Wünsche zu erfüllen, wurden in kürzester Zeit neue Strukturen aus dem Boden gestampft. In dieser Kultur entsteht gerne eine Führungskrise, hervorgerufen durch die Frage wer für was zuständig sei. Mit einem Pionier an der Spitze lässt sich das sehr gut mit Hilfe des “Personenkultes” bewältigen. Mit dem teilweisen Verlust des Pioniers und der unvollständig durchgeführten Kulturoffensive potenzierte sich die lauernde Führungskrise und es wurde als Bewältigungsmechanismus, fast panikartig, auf eine Differenzierungs-Kultur umgeschwenkt. Regeln sollten das Vakuum beherrschbar machen, der Kunde wurde zurückgestuft und wurde zu einem störenden Element in einem Unternehmen das zusätzlich zur Führungskrise nun auch in eine Kontrollkrise gerutscht ist.
Weitere Entwicklungskulturen die zu nennen wären, sind die Integrationskultur die hohen Wert auf das selbstständige Arbeiten mit Selbstkontrolle legt und die Netzwerkkultur bei der sich eine Organisation in Abhängigkeit von anderen Organisationen versetzt bei der jeder den gleichen Nutzen hat.

If you’re happy and you know it clap your hands

Weitere Metrik für eine Organisationskultur ist die Untersuchung nach pathologischen Merkmalen (nach Dr. Michael C. Funke). Ich bitte an dieser Stelle bei Interesse die verschiedenen Pathologien selbst nachzuschlagen da ich gerne weiter das Unternehmen mit euch analysieren möchte. Viele Pathologien sind dabei schon bereits durch die vorhandene Kultur definiert und treten zu einer hohen Wahrscheinlichkeit auf. So ist es im bereits erwähnten Unternehmen dazu gekommen, dass es in eine shizoide Kultur gefallen ist. Das Führungsvakuum erlaubt es nicht eine angemessene Betrachtung von vergangenem durchzuführen geschweige denn eine wirklich motivierte Zukunftsplanung bereitzustellen. Zu nahezu gleichen Teilen weist das Unternehmen auch eine zwanghafte Kultur auf, da versucht wird mit massiven Vorgaben zurück auf “null” zu kommen. Gleichzeitig zeichnet sich auch, vor Allem in der Belegschaft, depressive Organisation aus, da auf dieser Ebene der einzelne Mitarbeiter die fehlende/übermässige Kontrolle und die fehlende Führung durch altbekanntes zu kompensieren.

Get into the Agile now!

Was sind jetzt die Merkmale einer agilen Organisation fragst du dich? Nun das ist ein Thema für ein anderen Tag… Nein, Spass beiseite, zurück zur Ursprungsfrage. Interessanterweise vereinigt, vorausgesetzt du fragst mich, eine agile Organisation Komponenten aller vier vorgestellten Entwicklungskulturen. Sie nimmt sich aus der Pionier-Kultur das Konzept des Kundens royaler Abstammung (der Kunde ist König), stellt diesen in den Mittelpunkt. Dabei werden legere Regeln aufgestellt um die sich alles dreht (e.g. Verhaltenskodex) die aus der Differenzierungs-Kultur stammen. Auch die Integrations-Kultur wird beerbt mit dem wohl wichtigsten Punkt der Selbstführung bei gleichzeitiger Pflege der Teamarbeit. Zu guter Letzt geht eine agile Organisation ein Verhältnis mit weiteren Organisationen ein mit absoluter Gleichberechtigung (oder Augenhöhe genannt)

Yes, Yes, let agile consume you

Danke dass ihr heute wieder eingeschalten… vorbeigeschaut habt. Heute habe ich euch einen Frühstart in die Organisationskulturen gegeben und hoffentlich stellt ihr euch die Frage: “Ja, schön und gut. Ich weiss jetzt was bei mir so los ist aber wie bekomm ich die Organisation agil?”. Wenn eure Frage so oder so ähnlich ist, dann habe ich eine gute Nachricht: Schaut am 20.12. wieder vorbei, wenn es um die agile Transformation gehen wird.

Posted in Knowhow-Transfer | Tagged: | No Comments »

Muss es denn immer agil sein?

Posted by Cindy Wittmer on 30.11.2019

In dem Modul Organizational Agility gab es einen Punkt, der mich zum Nachdenken gebracht hat. Bisher war bei mir (und wahrscheinlich auch bei vielen Menschen in meiner Unternehmung) die Meinung präsent, dass agiles Projektmanagement immer passend ist. Erst in diesem Modul ist mir klar geworden, dass andere Projektmethoden durchaus Daseinsberechtigung haben und nicht ausgemerzt werden müssen. Um diesen Gedanken noch ein bisschen mehr Reifen zu lassen, überlege ich mir in diesem Blogg, welche Projekte mit welchen Methoden durchgeführt werden sollen. Als Grundlage verwende ich diese Grafik aus dem Unterricht.

Neue Märkte

Die Bank in der ich arbeite, ist bekannt dafür, dass sie immer wieder versucht neue Märkte zu erschliessen. So ist sie auf fast allen Kontinenten vertreten und hat für verschiedene Kulturen massgeschneiderte Produkte. In China waren sie die ersten mit einer Bankenlizenz. Auch heute gehört es immer noch zur Strategie neue Märkte zu erschliessen. Dazu werden neue Hubs errichtet oder kleinere Banken aufgekauft. Ein spannender Prozess, der erstmals sicher an dem „klassischen“ Projektmanagement vorbei geht. Da dieser Prozess immer wieder von neuem startet, wäre eine Methode wie bspw. Lean Innovation sicher sinnvoll, um die Verschwendung minimal zu halten und möglichst schnell am Markt zu sein. Ob meine Bank solche Methoden anwendet erzieht sich meiner Kenntnis.

Zweckmässigere Lösung

Aktuell ist Digitalisierung hoch im Kurs und auch in der Strategie festgehalten. Dem Kunden sollen neue Wege zur Kommunikation mit dem Kunden zur Verfügung gestellt werden. Ob per Chat oder Videotelefon oder durch die Nutzung speziell zugeschnittener Tools, alle Kanäle sollen für Kunden auf der ganzen Welt geöffnet werden – und das natürlich immer mit den Sicherheitsbestimmungen der Bank und des Gesetzgebers. Zur Erweiterung des Produkteangebots werden Tools entwickelt, mit dem in 5 Minuten strukturierte Produkt kreiert werden können. Solche Projekte können von der Agilität profitieren. Durch die schnellen Zyklen und das schnelle Feedback kann die Bank auf neue Trends reagieren. Schnelle erste nutzbare Lieferungen können testweise bei Kunden ausprobiert werden und das wertvolle Feedback des Kundenberaters sowie des Kunden kann eingearbeitet werden. Einige dieser Projekte werden tatsächlich agil umgesetzt. Hier scheint die Bank das Potential erkannt zu haben. Aber der Durchbruch wurde noch nicht geschafft.

Zweckmässigere Lösungen

Ich denke, viele regulatorische Projekte gehen in diese Kategorie. Mit der Umsetzung von regulatorischen Anforderungen verdient die Bank kein Geld, aber sie kann hohe Bussen vermeiden. Deshalb ist es wichtig, dass die Anforderungen korrekt umgesetzt werden, aber ein frühes Feedback ist nicht notwendig. Warum braucht’s trotzdem eine agile Komponente? Weil Gesetze meistens erst kurz vor dem Einführungstermin definitiv sind und laufend den Änderungen angepasst werden. Mein jetziges Projekt hat bspw. Einführungstermin 1.2.2020 und wir entwickeln im Moment nur auf Annahmen, weil sich die Bankiervereinigung nicht mit dem Regulator einigen kann. Deshalb mussten wir mit dem Provider eine Vorgehensweise finden, mit dieser Situation umzugehen. Wir haben nun die Möglichkeit, wenn nötig bis im Januar noch Anpassungen vorzunehmen. Ohne agile Strukturen (nicht unbedingt Methode) können solche Situationen nicht bewältigt werden.

Tauglichere Lösungen

Neben den oben erwähnten regulatorischen Projekten gibt es auch oft fixe Vorgaben wie bspw. die Besteuerung von Produkten. Das Land XY gibt vor, dass jede Transaktion mit 2% besteuert werden muss. Solche Vorgaben sind meistens fix und ändern nicht mehr. In solchen Fällen reicht das Wasserfallmodell aus. Legal/Compliance gibt vor, was besteuert werden soll und in den Systemen wird umgesetzt. Meistens sind die Umsetzungen zwar dennoch sehr komplex, da Daten aus den verschiedensten Systemen zusammengefasst werden müssen. Deshalb ist es gut, doch eine agile Komponente zu haben, damit man auf unerwartete Situationen wie bspw. eine vergessene Systemkomponente schnell reagieren kann.

Regelkonforme Lösung

Die Abgrenzung zwischen tauglichen und regelkonformen Lösungen finde ich schwierig. Es sind wohl Projekte gemeint, bei denen die Umsetzung nachvollziehbar nach bestimmten Anforderungen umgesetzt werden muss. Die daraus folgenden Prozesse sind meistens einfach und können automatisiert getestet werden. Die Einführung einer neuen Verarbeitungsmöglichkeit für Zahlungsaufträge würde ich in diese Kategorie fallen lassen. Der Prozess ist einfach und überblickbar, aber er muss alle möglichen Varianten abdecken. Diese sind aber im Vornherein bekannt. Bei uns werden solche Projekte immer nach dem Wasserfallprinzip umgesetzt. Das scheint auch sinnvoll zu sein.

Schnelle Umsetzung

Die schnellen Umsetzung sind die kleinen Änderungen an den Systemen und relativ häufig. Oft wird nicht mal ein Projekt lanciert. Der Businessvertreter erklärt was er möchte und der verantwortliche Entwickler setzt es um. Hier würde man mit einer grossen Projektorganisation wohl mit Kanonen auf Spatzen schiessen.

Fazit: Meine Bank grenzt die Methoden also tatsächlich ab. In der zweiten Kategorie wäre wohl am Meisten „Room for improvement“. Leider ist im Moment das Management noch nicht bereit für „agil“ (Aussage eines Managers). Als Projektmitarbeiterin ist dieser innere Kampf stark spürbar. Agile Projekte werden meistens völlig losgelöst von der Organisationsstruktur aufgestellt, damit sie eine Chance haben und von den internen Machtkämpfen verschont bleiben. Dieser Umgang ist im Moment zweckmässig, mich würde es aber freuen, wenn agile Projekte wie selbstverständlich in der Unternehmung eingebettet werden könnten.

Posted in Organisation Agility | No Comments »

Selbsterkenntnis auf dem Weg in die Agilität

Posted by Henry Dontschew on 04.11.2019

Die Zeit vergeht wie im Flug und wieder ist ein CAS-Modul abgeschlossen. Diesmal muss ich feststellen, dass mich das Thema “Personal Agility” auf sehr unterschiedliche Weise gefordert und zum Teil überfordert hat.

Summary:

“Ein Mensch muss wissen, was er will, und wissen, was er kann:

Erst so wird er Charakter zeigen und erst dann kann er etwas Rechtes vollbringen”

Die Welt als Wille und Vorstellung, Arthur Schopenhauer, 1977, S. 251

Soziale Kompetenzen haben in der Agilitätsbestrebung eine neue Tragweite erreicht und die bis dato gefragten ‘hard skills’ längstens überflügelt. Wer die Agilität meistern und als Gewinner vom Platz gehen will, muss eine reife Persönlichkeit entwickeln.
Selbsterkenntnis ist dabei der erste Schritt auf dem beschwerlichem Weg zu einer gefestigten inneren Stabilität. 

Persönliche Reife ist der Weg zur Agilität

In der agilen Welt ist die reife Individualität eine Lebensnotwendigkeit

https://www.wiwo.de/erfolg/beruf/new-work-in-der-agilen-welt-ist-die-reife-individualitaet-eine-lebensnotwendigkeit/24380670-2.html

Diese oder ähnliche Aussagen lassen sich zur Genüge in der Fachliteratur zum Thema Agilität und auf diversen Blogs wiederfinden.
Grund genug, sich mit dem Thema intensiver zu beschäftigen und die eigene Reife im Zusammenhang mit der Agilität zu hinterfragen.

Agilität als Bewältigungsstrategie unserer heutigen VUCA-Welt verlangt uns einiges ab. Kundenorientierung, schnelle Entscheidungen, enge Zusammen-arbeit, Anpassungsfähigkeit, Veränderungsbereitschaft und permanente Optimierung stehen hoch im Kurs.
Der tägliche Leistungsdruck ist allgegenwärtig zu beobachten und mich überkommt nicht selten das Gefühl der Überforderung.

An manchen Tagen weiss ich kaum wo mir der Kopf steht.
Es geht von einem Meeting ins nächste, Entscheidungen müssen getroffen, Probleme gelöst und Kunden befriedigt werden. Kleinigkeiten, wie eine banale Frage eines Mitarbeiter können dann das Fass schnell zum Überlaufen bringen und eine Kurzschlussreaktion bei mir auslösen.
Die eigenen Wünsche und Bedürfnisse bleiben dabei oft auf der Strecke und nicht selten gehe ich mit einem tiefen Gefühl der Unzufriedenheit und Ärger über mich selbst frustriert nach Hause.

Doch was tun?

Eine Antwort liefert Dr. Thomas Würzburger:

Wer … agil und leistungsstark werden will, braucht ein STABILES ICH, das ihn mit den dafür notwendigen Kompetenzen ausstattet und ihm gleichzeitig innere Stabilität verleiht.

Thomas Würzburger, Die Agilitätsfalle, 2019, S. 70

Aha, ein “stabiles Ich” muss also her.
Aber was ist das genau, dieses stabile Ich?

Als Voraussetzung zum “stabilen Ich” nennt Würzburger folgende Selbstkompetenzen:

  • Intrinsische Motivation
  • Selbsterkenntnis
  • Selbstkontrolle

und fasst diese im Würzburger Kompetenzmodell zusammen.

Quelle: https://thomaswuerzburger.com/blog/persoenlichkeitsentwicklung-die-alternative-zum-agilen-management-hype/

Goleman bezeichnet die oben genannten Kompetenzen als emotionale Intelligenz und stellt in Studien fest, dass diese Fähigkeiten doppelt so wichtig sind, wie jede andere Fähigkeit. (vgl. What Makes a Leader)
Selbstkompetenzen sind demnach der Schlüssel zum Tor der persönlichen Agilität.

Wie meine Offenbarung von oben zeigt, scheint bei vor allem in Sachen Selbstkontrolle Bedarf der Nachreife zu bestehen.

Selbsterkenntnis:
Eine Grundvoraussetzung für die persönliche Weiterentwicklung ist Selbst-erkenntnis. Denn ohne Wissen über seine eigenen Verhaltensweisen, seine Stärken und Schwächen, seiner Gefühle und Ziele ist eine Verbesserung seiner Selbst nicht möglich. Und auch das persönliche Glück ist eine Frage der Selbsterkenntnis.

Doch wer bin ich eigentlich und wie gut kenne ich mich?

Diese Frage klingt im ersten Moment trivial denn immerhin konnte mein 8-jähriger Sohn sie in 30 Sekunden spontan beantworten.

Doch ich selber scheitere kläglich auf der Suche nach einer Antwort.
Schenkt man dem renommierten Hirnforscher Gerhard Roth glauben, dann ist uns lediglich 0.1% dessen was unser Hirn gerade tut, bewusst. Der Rest passiert unbewusst, ist also eine Abfolge von erlernten Muster.
Daraus ziehe ich die Schlussfolgerung, dass der erste Schritt zur Beantwortung der Frage im Erkennen der eigenen Muster liegt.

Verhaltensmuster sind die Summe der unterschiedlichsten Einflussfaktoren und das Ergebnis unserer eigenen Geschichte und somit auch nicht durch unseren Willen beeinflussbar.

Um eigene Muster zu erkennen, eignet sich der im CAS präsentierte “Muster-Detektor”, den ich direkt in folgender Alltagssituation angewendet habe.

Alltagssituation:
Seit mehreren Sprint wird in meinem Team an der Umsetzung einer User-Story gearbeitet und auch nach Abschluss des letzten Sprints konnte diese nicht umgesetzt werden. Erneut stellt sich heraus, dass die angestrebte techn. Lösung zu komplex ist und immer weitere Tasks auftauchen, die erledigt werden müssen.

Nachdem ich anfänglich sehr zurückhaltend darauf reagiert und meinem Team “blindes” Vertrauen geschenkt habe, dass das zugesicherte Commitment diesmal erfüllt wird, beginnt es jetzt langsam in mir zu brodeln und die Unzufriedenheit übersteigt einen für mich erträglichen Pegel. Dennoch halte ich mich weiter zurück und wähle die Coping-Strategie “Ruhig Blut bewahren”.

Am liebsten würde ich jedoch mit den Worten “macht es nicht komplizierter als es ist” auf den Tisch schlagen und eine einfache Lösung zur Umsetzung diktieren. Immerhin haben wir uns die Kundenorientierung und die schnelle Lieferung von Ergebnissen als agiles Team auf die Fahne geschrieben. Stattdessen stehen wir seit Wochen ohne vorzeigbares Ergebnis dar.

Doch mein eigenes Harmoniebedürfnis hält mich letztendlich von einer solchen Tat ab. Zudem möchte ich keinen Konflikt mit einzelnen Teammitglieder riskieren und Gefahr laufen, dass die bisher positive Stimmung im Team kippt. Immerhin verbringe ich mehr Zeit mit diesem Team als mit meiner eigenen Familie.

Dies führt mich zu der Erkenntnis, dass ich auf Grund einer gewissen Konfliktscheue und dem Bedürfnis nach Harmonie meine Führungs-verantwortung in den Hintergrund stelle und damit u. U. Erfolge des Teams verhindere. Hinzu kommt ein gewisses Unvermögen die eigenen Gefühle mit dem Team zu teilen ohne dabei zu überreagieren und Vorwürfe zu kommunizieren.

In Einzelgesprächen mit anderen Mitgliedern meines Teams stellte sich jedoch heraus, dass auch sie ähnliche Ansichten wie ich vertraten, was mir eine gewisse Sicherheit verlieh und mich bestärkte das Thema in einer Retrospektive aufzugreifen und anzusprechen.
Schlussendlich ist die Scheu, etwas für mich belastendes anzusprechen, mit der Sicherheit nicht alleine dazustehen gewichen.

Durch die eigene Reflexion und im Dialog mit anderen können als problematisch erlebte Situationen oder Zustände analysiert und hinterfragt werden. Die gewonnen Erkenntnisse können anschliessend genutzt werden, um das eigene Verhalten in ähnlichen Situationen anzupassen und damit die eigene Selbstkontrolle zu verbessern.

Selbstverständlich ist das von mir beschriebene Verhaltensmuster nur eines von vielen. Einige dieser Muster sind mir durchaus bewusst und ich arbeite oder kämpfe vielmehr seit Jahren diese abzustellen.
Andere liegen im Verborgenen und sind damit blinde Flecken in der Selbsterkenntnis.

Auf dem Weg zur Selbsterkenntnis bzw. einem “stabilen Ich” liegen also noch einige Jahre harter Arbeit vor mir.
Trotz aller Bemühungen bleibt bei mir ein etwas bitterer Beigeschmack zurück.

Denn der Philosoph Richard David Precht und der Hirnforscher Gerhard Roth kommen zum Ergebnis, dass das menschliche Verhalten nur zu einem kleinen Teil (ca. 20%) tatsächlich bewusst änderbar ist.

“Die Ratio alleine bewegt überhaupt nichts”

Streitgespräch, Roth, Precht, https://magazin.spiegel.de/EpubDelivery/spiegel/pdf/65115053

Mit diesem Hintergrundwissen stellt sich mir die Frage:
Wie weit können oder wollen wir uns tatsächlich selbst optimieren auf dem Weg in die Agilität?


Posted in Personal Agility | Tagged: , , , , | No Comments »

4 Hauptwerte des agilen Manifestes

Posted by Cindy Wittmer on 25.10.2019

In meinem heutigen Blogg werde ich die 4 Hauptwerte des agilen Manifestes erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden. Leider ist der Prozess im Moment aber so aufgesetzt, dass der persönliche Austausch nicht vorgesehen ist. Als eigenständige Personen können wir uns aber selbstverständlich trotzdem dafür entscheiden – aber ob das jeder tut?

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich hab schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.   sdqformat

erörtern und auf mein heutiges Umfeld transformieren. Ob wir diesen Werten gerecht werden?

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In  einem Team geht es um Menschen und wie diese miteinander arbeiten. Alleine kreativ zu sein ist schwierig. In einem Team können verschiedenste Talente miteinander verbunden werden und wenn diese Fähigkeiten kombiniert werden, entsteht ein produktiver Organismus, der mehr ist als die Summe aller Fähigkeiten der Individuen. Ein positiver Team-Groove macht Spass, fördert die Kreativität und reduziert den negativen Stress.

Prozesse und Werkzeuge führen oft dazu, dass die persönliche Interaktion reduziert wird. Tasks und Issues werden direkt in einem Tool erfasst und automatisch an die verantwortliche Person gesandt. Hinter definierten Prozessen verstecken sich Mitarbeiter, um nicht über den Zaun schauen zu müssen. Sie sagen: „Der andere ist für den nächsten Prozessschritt zuständig. Das geht mich nichts mehr an.“ Die Zusammenarbeit bleibt dabei auf der Strecke. Deshalb sollen Methoden so gewählt werden, dass sie die Interaktion fördern und nicht unterbinden.

In unserem Team wird durch örtliche Nähe, aber auch durch eine sehr offene Kommunikationskultur der Kontakt gefördert. Obwohl wir offiziell nicht agil sind, werden Probleme angesprochen und zusammen gelöst. Die Tools und Prozesse, die wir verwenden, laden aber nicht unbedingt zur Zusammenarbeit ein. In einem festgelegten Prozess müssen Dokumente erstellt werden. Im Dokumenten-Review können Befunde direkt erfasst und müssen nicht besprochen werden. Tasks werden elektronisch zugeordnet und übermittelt. All das gibt dem Menschen die Möglichkeit sich zu verstecken. Ich bin nicht per se der Meinung, dass man diese Mittel nicht nutzen soll. Wir sollten sie aber nicht zum Eigenzweck, sondern als Unterstützung für die persönliche Interaktion anwenden.·      

Funktionierende Software mehr als umfassende Dokumentation

Für die Aufarbeitung einer Anforderung ist die schriftliche Form aus meiner Sicht enorm hilfreich. Sobald ich eine Anforderung formulieren muss, werden missachtete Punkte und vergessene Aspekte klarer. Zusätzliche gebe ich durch das geschriebene Wort anderen die Möglichkeit meine Gedanken zu verstehend. Diese Basis kann dann als Diskussionsgrundlage herbei gezogen werden.

Die Dokumentation darf aber nicht dazu verkommen, als einziges Kommunikationsmittel genutzt zu werden. Inhalte sollen von Angesicht zu Angesicht besprochen und die Anforderungen erklärt werden. Falls sich bei der Diskussion Änderungen ergeben, sollen die gleich in die Beschreibung miteinfliessen.

Im offiziellen Prozess unserer Organisation wird die Abgabe von spezifischen Dokumentationen festgelegt. Templates werden zur Verfügen gestellt und die geschriebenen Dokumentationen durch ein unabhängiges Board reviewed. Ich bin nicht sicher, ob dieser Prozess dem Ziel einer funktionierenden Software dient. Die Dokumente dienen nicht als Arbeitspapier, sondern müssen zur Zufriedenheit des Reviewboards gestaltet werden.

Bei uns im Projekt konnten wir uns mehrheitlich von diesem Prozess lösen. Wir haben auch Spezifikationen, die werden aber in erster Linie als Arbeitspapier verwendet. Häufig findet aber auch bei uns die Kommunikation via Mail statt, damit die sprachliche Barriere zum italienischen Provider ein bisschen überwunden werden kann. Vielleicht könnten wir uns einige Fragerunden sparen, wenn wir hier mehr Schwerpunkt in den persönlichen Kontakt via ConfCall legen würden.·    

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Gibt es was Zermürbendes als wochenlange Vertragsverhandlungen? Monate gehen ins Land bevor auch nur ein Strich Code geschrieben wird. Penaltys werden für den Fall einer zu späten oder unvollständigen Lieferung definiert und Preise gedrückt. Schlussendlich ist die Stimmung schon schlecht, bevor sich die Teammitglieder überhaupt kennen gelernt haben. Am Schluss werkelt jeder in seinem Kämmerchen und der prophezeite Penalty wird tatsächlich Realität. Waren das jetzt erfolgreiche Vertragsverhandlungen?

Bei uns habe ich beides schon erlebt. Projekte, die an den Vertragsverhandlungen scheiterten, weil die Energie nicht für die Software verwendet wurde, aber auch gute Zusammenarbeit und erfolgreiche Einführungen. Aus meiner Sicht steht und fällt der Erfolg mit der Wertschätzung, die die Teammitglieder spüren. Weiss der Entwickler des externen Providers, dass sein Input geschätzt wird? Kann ich mich als Business Analyst darauf verlassen, dass die Anforderungen so umgesetzt werden, wie ich sie priorisiert und kommuniziert habe? Die Zusammenarbeit ist ein Geben und Nehmen, das durch harte Vertragsverhandlung gestört werden kann.

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Im Grundsatz einen Plan zu haben, ist sicher sinnvoll. Mit einer Liste von Anforderungen, eingeordnet in den Kontext der Zeit, kann beurteilt werden, welche Ressourcen nötig sind und ob die Timeline eingehalten werden kann. Eine Planung zwingt aber auch zu einer klaren Priorisierung der Anforderungen. Aber der Plan darf nicht Sakrosankt sein, sondern soll unkompliziert angepasst werden können. Die Aufnahme neuer Anforderungen muss möglich sein, die Umpriorisierung von bestehenden Tasks darf nicht zu einem riesen Akt verkommen. Das Projektteam muss die Fähigkeit beibehalten agil auf Veränderungen zu reagieren.

Ich habe schon erlebt, wie Projekte laufen, die ohne Task- und Ressourcenplanung geführt werden. Am Schluss mussten wichtige Anforderungen verschoben werden, weil die Zeit ausging.

Obwohl bei uns in der Unternehmung festgelegt Planungssheets zur Verfügung stehen, steht und fällt der sinnvolle Umgang mit dem Projektleiter. Aktuell erlebe ich eine Situation, die in einem agilen Projekt mit grosser Wahrscheinlichkeit nicht geschehen wäre. Geplante Tasks haben weniger Zeit benötigt als erwartet, die neu geschaffene Zeit wird aber nicht durch Umplanung sinnvoll genutzt. In einem agilen Projekt könnte man im Sinne der Unternehmung agil auf diese Situation reagieren und die Zeit zweckmässig nutzen.

Diese Zusammenstellung zeigt, dass wir in unserer Unternehmung zwar nicht Meilenweilt von einer agilen Unternehmung entfernt sind, aber doch noch viele Stolpersteine vor uns liegen. Projekte sind ein People-Business und als das sollte es auch behandelt werden.

Posted in Agile Basics, Team Agility | No Comments »

Agilität – Stolperstein Mensch Part 1

Posted by Henry Dontschew on 06.10.2019

Nachdem ich in meinem letzten Blog-Beitrag einen Spike in die Basics des agilen Vorgehens unternommen habe, werde ich mich in diesem Beitrag auf agile Teams und damit auf die Menschen in der agilen Welt fokussieren.

Summary:
Agiles Arbeiten bringt Freiheit, stellt aber auch hohe Anforderungen an das Team und jeden Einzelnen.
Wer kein Engagement zeigt, Verantwortung übernimmt, Kritik akzeptiert und sich selbst reflektiert, fällt durch die Maschen der Agilität und gerät u. U. ins Abseits. Damit agile Zusammenarbeit gelingt und am Ende ein für den Kunden wertsteigerndes Ergebnis zu Tage gefördert werden kann, braucht es permanente Weiterentwicklung und Optimierung. Dies entpuppt sich vor allem beim Faktor Mensch als äusserst schwierig und herausfordernd.

(Agile) Teams als Grundpfeiler der Agilität
Agile Vorgehensmodelle wie Scrum und Kanban sind die eine Seite der Medaille. Sie liefern uns (mal mehr mal weniger) konkrete Anhaltspunkte zum Vorgehen und bilden damit das Rahmenwerk für die täglich Arbeit.
Doch was nützen all diese Frameworks mit ihren zugrundeliegenden Werten und Prinzipien wenn niemand diese versteht, anwenden und umsetzen kann?
Und hier kommt die zweite Seite der Medaille ins Spiel – Menschen, welche in Gruppen/Teams versuchen agile Modelle mit mehr oder weniger Erfolg anzuwenden.

Klassische Teams vs. Agile Teams
Was unterscheidet jedoch ein klassisches Team von einem agilen?
Grundsätzlich sind beides Gruppen von Menschen, die nach bestimmten Normen und Regeln kooperieren, um ein bestimmtes Ziel zu erreichen. Beide Arten von Teams können durchaus erfolgreich und effizient sein und benötigen dafür neben klaren Zielen, eine angemessene Führung, organisatorische Unterstützung, geeignete Aufgaben sowie Wertschätzung. Hier gibt es also keine Differenzierung. Der eigentliche Unterschied liegt in der Arbeitsweise, also dem WIE etwas getan wird. 

Agile Teams zeichnen sich durch eine ausgeprägte Kollaboration in Kombination mit einer offenen, respektvollen Kommunikation auf Augenhöhe aus. Oft sind agile Teams nicht statisch zusammengesetzt, wie man es von klassischen Teams kennt, sondern werden je nach der zu lösender Aufgabestellung, mit Teammitgliedern ergänzt bzw. reduziert. Damit wird dem agilen Grundsatz, dass ein Team über das notwendige Wissen zur Lösung eines Problems verfügen soll, Rechnung getragen.
Der entscheidende Unterschied zwischen klassischen und agilem Team ist jedoch das selbst organisierte Handeln und das gemeinsame Entscheiden.
Die klassische Führungsrolle wie die eines Teamleiters o. ä. entfällt und wird durch eine verteilte Verantwortung auf das ganze Team übertragen.

Doch gerade diese Selbstorganisation wirft bei mir einige Fragen auf.
Wie in vielen Organisationen ist auch mein aktueller Arbeitgeber klassisch, hierarchisch organisiert.
Beginnend mit dem CEO an der Spitze, verästelt sich die Organisation auf Business-Units, Abteilungen und Teams, welche jeweils einen “Lead” vorangestellt haben. Dabei ist einzig die IT-Abteilung mit ihren 4 Teams nach agilen Prinzipien (Scrum) aufgestellt. Internen Versuche Teams ohne Teamleiter agieren und sich selbst organisieren zu lassen sind gescheitert (Hierzu mehr in meinem nächsten Blog-Beitrag). Was dazu geführt hat, dass jedes Scrum-Team einen Teamleiter besitzt, der die personelle Verantwortung für das Dev.-Team übernimmt.
Diese Art der Organisation ist aus meiner Sicht in der heutigen Zeit häufig anzutreffen und steht nicht zwangsläufig im Widerspruch zu den agilen Bestrebungen, was sich auch in einem Zitat von Boris Gloger widerspiegelt.

…Selbstorganisation ohne Führung ist zum Scheitern verurteilt.”

Boris Gloger, 2017, S.4

Verlassen wir jedoch das Thema Führen in agilen Organisationen (ich bin schon sehr gespannt auf das CAS Modul Organizational Agility) und kommen zurück zu agilen Teams.

Wie die “Agilität” selber haben auch agile Teams die absolute Kundenorientierung, schnelle Entscheidungen, Innovation, optimale Technologieausnutzung und die Generierung von Business Value im Fokus.
Dr. Thomas Würzburger fasst dies aus meiner Sicht sehr prägnant zusammen:

“Der Zweck ist…: den Menschen möglichst leistungsfähig zu machen .”

Thomas Würzburger, Die Agilitätsfalle, 2019, S.21

Doch aus eigener “schmerzvoller” Erfahrung kann ich behaupten, dass dies einer der ersten Stolpersteine in der agilen Transformation ist. Denn wer glaubt mit der Einführung agiler Methoden wie Scrum oder Kanban, der Durchführung einer Mitarbeiterschulung mit Unterstützung eines Agile Coach schon am Ziel zu sein wird wohl schon nach kurzer Zeit eines Besseren belehrt.

An dieser Stelle kommt mir einer meiner letzten Workshops in den Sinn. In diesem hat der Agile Coach immer wieder betont wie wichtig die Lieferung von Business Value ist. Leider hat er vergessen zu erwähnen was notwendig ist, um konsequenten Kunden-/Geschäftswert zu generieren. Denn die Rahmenbedingungen und das im Agilitätskontext häufig anzutreffende Buzz-Word “Mindset” sind matchentscheidend. Sind diese nicht gegeben sind agile Bestrebungen kaum möglich.

Ein Team das (Höchst)Leistung erbringen soll sich dabei selbst organisiert, gemeinsam entscheidet und dabei maximal kundenorientiert ist braucht aus meiner Sicht vor allem zwei Dinge:
Motivation und den Willen sich permanent weiterzuentwickeln.

Team-Motivation:
Team-Leistung bedingt Motivation jedes Einzelnen.
Doch wie entsteht Motivation?
Diese Frage stelle ich mir in meiner Rolle fast täglich. Denn als Teamleiter ist es einer meiner Hauptaufgaben mein Team zu motivieren, es zu unterstützen, zu ermutigen und bei Fehlern in Schutz zu nehmen. Doch gerade das Motivieren eines ganzen Teams als Einheit zu funktionieren, Entscheidungen selbstständig zu treffen und effizient zu handeln scheint an manchen Tagen ein aussichtsloser Kampf.
Jeder Mensch (oder Teammitglied) hat eigene Wünsche, Ziele, Stärken und Schwächen. Werden diese nicht berücksichtigt sinkt die Motivation und damit die Leistungsbereitschaft.

Letztendlich heisst das Battle:
Eigene Ziele vs. Übergeordnete Ziele oder  Motivation vs. Business Value

Leistungsbereitschaft oder Agilität im Allgemeinen können nicht erzwungen oder antrainiert werden. Ebenso wenig kann Motivation eingefordert oder erkauft werden. Was hinzukommt und ich immer wieder im Alltag feststelle ist, dass einige Menschen schlichtweg mit Agilität überfordert sind und versuchen sich in ihre Komfortzone zurückzuziehen. Sie wollen gar nicht die Freiheit Entscheidungen zu treffen, Neues zu probieren oder gewohnte Prozesse und Strukturen verlassen. Was sie wollen ist eine klare Aufgabe, (k)einen Termin und ihre Ruhe.

Somit stellt sich die Frage:
Fallen diese Menschen durch die Maschen der Agilität oder können auch sie weiterentwickelt werden, um mit der Agilität Schritt zu halten?

(Weiter)Entwicklung des agilen Teams:
Weiterentwicklung bedeutet Lernen und Adaptieren. Dies wiederum bedeutet Fehler zu machen, Kritik entgegenzunehmen und zu reflektieren um daraus wiederum zu lernen und zu verbessern. Es handelt sich hier also um ein iteratives-inkrementelles Vorgehen, was ein wesentliches Merkmal agiler Ansätze darstellt. Im Kontext der agilen Teamentwicklung taucht schnell der Begriff “Retrospektive” auf.

Ziel einer Retrospektive ist die kontinuierliche Optimierung der Teamzusammenarbeit, um bessere Ergebnisse zu liefern. An dieser Stelle sei kurz auf den letzten Punkt der 12 Prinzipien zum Manifesto for Agile Software Development verwiesen.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

https://agilemanifesto.org/principles.html

Im Gegensatz zu einem Review (im Scrum das sogenannte Sprint-Review) bei dem es um die Klärung der Frage: “Tuen wir das Richtige?” geht und damit der inhaltliche Aspekt im Vordergrund steht, beschäftigt sich die Retrospektive mit der Frage: “Wie tuen wir es richtig?”. Hier rückt also die Arbeitsweise und Zusammenarbeit im Team in den Fokus.

Betrachtet man ein Team als System, so kann die Retrospektive als Regelkreis verstanden werden.
Vereinfacht ausgedrückt wiederholen sich in einem Regelkreis (vgl. https://de.wikipedia.org/wiki/Regelkreis)  folgende drei Schritte:

  1. Handlung: eine Interaktion des Systems
  2. Reaktion: Beobachtung des Systems
  3. Analysieren: aus dem Verhalten des Systems lernen

Übertragen auf die Teamarbeit heisst dies also, dass die Zusammenarbeit eines Teams zur Lösung eines Problems als Interaktion aufgefasst werden kann. Diese Interaktionen werden von den einzelnen Teammitgliedern wahrgenommen und beobachtet. Die Beobachtungen werden in zyklischen Abständen z. B. nach Abschluss eines Sprints (alle 2-4 Wochen) analysiert, um Störfaktoren zu identifizieren und zu beheben. Damit entsteht ein System aus Rückkopplung und Kalibrierung, welches sich an vielen Orten in der agilen Welt wiederfinden lässt.
Bei technischen Systemen scheint die Anwendung eines Regelkreises recht simpel. Übertragen auf die menschliche Zusammenarbeit ist dies jedoch eine der grössten (aus meiner Sicht sogar die grösste) Herausforderungen in der agilen Bestrebung.
Denn das System “agiles Team” besitzt eine Vielzahl von Stellschrauben wie Motivation, Verantwortungsübernahme, Umsetzungskompetenz, Kommunikationsfähigkeit und viele mehr, welche es zu justieren gilt. Hinzukommt, dass ein Team ein Sub-System eines grösseren Systems (Organisation) ist und dieses übergeordnete System ebenso viel “Stellschrauben” zur Kalibrierung besitzt.

Die Challenge in der Agilität ist demnach der Mensch.

Posted in Team Agility | Tagged: , , | No Comments »