CAS Agile Organisation

making your organisation agile

Archive for the 'Organisation Agility' Category

Organizational Agility

Posted by Gils Glauser on 5th December 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 5th December 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 »

Muss es denn immer agil sein?

Posted by Cindy Wittmer on 30th November 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 »