Alle Artikel in der Kategorie “Blog

Posts der methodenfabrik. Themen und Ideen zu Methoden und fachlichen Topics

Kommentare 0

DevOps ist mehr als Tooling

Microservices and FaaS drive Organizational Change
#trust #devops #organization #change

Die Anzahl von deployment Einheiten hat über die letzten Jahre zugenommen. Infrastruktur wird als Code auf public oder private Clouds verwaltet. Der Server-Less Trend treibt Entwickler dazu noch kleinteiliger zu deployen. Komponenten der Infrastruktur sollen es nicht mehr sein. Nur einzelne Codefragmente welche Anwendungsfunktionen bereitstellen (Functions as a Service) sollen es heute sein. Bezahlen erfolgt nach Laufzeit und Aufrufen der Funktionen.  Alles wird kleinteiliger. Abhängigkeiten nehmen zu.

Dieser Trend führt dazu dass große Betriebsanteile zu Cloud Providern abwandern. Betriebsszenarien wanden sich. Google bildet Site Reliability Engineering (SRE) Teams. Die Aufgabe dieser Teams ist es die Applikation so zu betreiben, dass für den Betrieb das menschliche Eingreifen minimiert wird. Ziel ist manuelle Interaktion von Null. Ausfälle werden behoben, die Ursache analysiert und die Ursache in Code für die Zukunft vermieden. Das Wissen darum wird über Teamgrenzen geteilt. Die Stabilität der Applikation nimmt zu, Automatisierung und Wissen um Fehler werden in der Organisation geteilt. Das Bedarf eine gesunde Einstellung zu Fehlern und dem Willen zur Transparenz.

In Kategorie: Blog
Kommentare 0

Story Splitting Techniken für Enterprise SAP Projekte helfen bei der Transformation

Monopoly Geld ist unser Value – Domain Vertreter kaufen Backlog Elemente

In unserem aktuellen agile Transition Team gehen wir auf die verschiedenen Business Divisions zu und binden diese in unsere agile Entwicklung ein. Die Vertreter der Division stoßen zu unserem Product Team als Domain Experten. Die Domains sind Distribution, Ordering, Pricing, Finance, Invoicing und 3 Produkt-Domains die jeweils durch einen Domain PO’s vertreten sind.

Oft haben die Vertreter aus den Business Divisions früher Anforderungen in großen Dokumenten beschrieben, welche sehr lang bearbeitet wurden und dann auch noch in lange Freigabeprozesse weitergereicht wurden. Diese großen Enterprise Prozesse betreffen mehrere Domains und müssen landesspezifisch auch rechtskonform sein.

#Priorisierung funktioniert auf dem Level dieser großen Anforderungen schlecht.

So haben sich Verhaltensweisen eingeschliffen: Wir müssen mit dem Prozess beginnen, welcher zuerst fertig spezifiziert ist und auch freigegeben wurde. Wenn kurz darauf eine andere große Anforderung freigegeben wird, muss das Team auch sofort mit der Umsetzung dieser beginnen. Es dauert ja sowieso schon so lange – also beginnt gleich.

Ergebnis – Das Team hat alles in Bearbeitung, aber es wird nichts fertig.

Mit der hohen Komplexität der Enterprise-Prozesse die in SAP abgebildet oder verändert werden ist dann auch verbunden:

#Story-Splitting hilft die kleinen wertschöpfenden Elemente aus den großen Prozessen zu finden und diese dann auch wirksam zu priorisieren. Dazu müssen diese großen Elemente aber wirksam zerteilt werden und dennoch in jedem Stück ein Kundennutzen erhalten bleiben. Die Skepsis bei den Stakeholdern dazu ist groß.

Unser Ansatz besteht zuerst einmal darin diese Bedenken ernst zu nehmen.

Über viele Jahre wurde das Verhalten geübt und belohnt. Wenn Deine Anforderungen größer, komplexer und teurer sind, diese aber dennoch umgesetzt werden hast Du mehr Macht.

Auch die Optimierung nach Effizienz hat das Verhalten begünstigt. Die Dienstleister sollte alles kostengünstig umsetzen. Also auch alle Systemkomponenten, Schnittstellen, Skripte nur einmal anfassen. Es sollte ja auch nur einmal der Aufwand für das Testen entstehen. Alles wurde in die Anforderungen hineingepackt – man wollte ja nichts vergessen und dann sollte das alles auch gleich mit gemacht werden.  

Praktisch nutzen wir die vorhandenen großen Anforderungsdokumente als Ausgangspunkt und gehen als Coaches mit den Domain Product Ownern und den SMEs (Special Matter Experts) aus den Ländergesellschaften in einen fachlichen Dialog. Wir hinterfragen den Sinn, arbeiten den Nutzen heraus und trennen die Anforderung (WAS) von der Vorgabe der technischen Realisierung (WIE).

So werden klarere, kleinere und wertschöpfende Dinge sichtbar. Dann sind es auch schon mehrere wertschöpfende Dinge. Statt alles „vom Prozess“ zu sehen fragen wir nach dem Nutzen. Wer hat durch die Umsetzung wann wieviel Nutzen?

Tooling halten wir von den Gesprächspartnern fern. Wir nutzen kleine formlose Word-Dokumente ohne Struktur, Karten, Flipcharts, Bilder und ähnliches. Die wertvolle Zeit mit den wirklichen fachlichen Experten stecken wir in die Gespräche (personal interactions) statt in Arbeitsabläufe oder Tool-Diskussionen.

Unsere Fragetechniken für das Teilen des zusammenhängenden Ganzen:

  • Für wen entsteht Nutzen?
    • Gibt es unterschiedliche Nutzer? Oder Nutzergruppen?
    • Machen alle das gleiche?
    • Gibt es Experten-/ Profi Nutzer und Gelegenheits-Nutzer?
    • Gibt es Länder oder Regionen welche die Funktion nicht benötigen?
  • Gibt es „Brot und Butter“ Fälle und Sonderfälle?
    • Was ist der Standard-Fall des Prozesses?
    • Welche unterschiedlichen Sonderfälle gibt es?
    • Wie oft kommen diese in welchen Ländern vor?
    • Kann die Performance für Sonderfälle erstmal schlechter sein?
  • Auf welchen Endgeräten entsteht der Nutzen?
    • Am Arbeitsplatz-PC?
    • Tablet/ Mobile Geräte im Außendienst?
    • Kunden-Terminals oder Point of Sales?
  • Werden für einen Prozess-Ablauf alle Daten und Systeme benötigt?
    • Gibt es Varianten wo nur bestimmte Daten benötigt werden?
    • Gibt es Prozesse-Varianten bei denen andere System nicht eingebunden sind?
    • Können bestimmte Teile (erstmal) manuell gemacht werden?
  • Gibt es bestimmte Risiken in einem Bereich?
    • Haben einige Schritte im Prozess einen hohen Einfluss auf Kosten-Risiken?
    • Gibt es technische Schritte, welche wir das erste Mal machen müssen?
    • Gibt es Schritte, bei denen wir kein fachliches Wissen haben?
    • Heben uns manche Schritte vom Wettbewerb ab? (Differentiators)
  • Rechtliche oder Finanzielle Compliance
    • Welche Schritte sind für sich Compliance relevant?
    • Welche Ergebnisse/ Dokumente oä. sind es?
    • Wer prüft diese Compliance wann?
    • Was sind die Kosten der Verletzung?  

Diese Fragen setzen wir aber nicht strikt nach Kochrezept oder gar in einer Reihenfolge ein, sondern fragen situativ und skizzieren dabei die Teile des Ganzen visuell für alle sichtbar mit. Nach einigen praktischen Übungen kommen die Ideen zum Teilen von den Teilnehmern selbst.

Im Ergebnis haben wir aus einem komplexen zusammenhängenden Lastenheft viele für sich nutzbringende Teile gemacht. Diese bringen wir auf Karten.

Jetzt bekommt jeder Domain Product Owner im Verhältnis des Budgets einen Stapel Monopoly Geld. Mit diesem Budget können jetzt Karten gekauft werden. Das Geld wird mit Büro-Klammern an die Karte geklammert. Das repräsentiert den Wert der Karte. Ein hoher Wert bringt die Karte „nach vorn“. Da Monopoly Geld verschiedene Farben hat können die Teilnehmer die Werte im Anschluss auch noch korrigieren, wenn jeder weiß was „sein“ Geld war.

Die Teilnehmer sehen, dass eine Verteilung des Budgets auf viele Elemente nicht zum gewünschten Erfolg führt. Sie entscheiden sich daher zunehmend für das „Pushen“ einiger weniger Karten. Wir bekommen unseren Backlog.

Im Anschluss bringen wir Moderatoren die Karten in’s Jira und das Geld wird zu Value Einheiten und der Value schiebt die Elemente auf „Ihre“ Positionen auf dem Board. Ohne Schulungen in Anforderungsmanagement für alle kommen wir so schnell und zuverlässig zu kleinen werthaltigen Elementen und können #DevOps machen. Wir treiben die #Transformation ohne groß über den Prozess oder die Methodik zu sprechen.

In Kategorie: Blog
Kommentare 0

Money for Nothing

Es gibt einen Punkt im Verlauf der agilen Produktentwicklung, an dem die Kosten der Iteration den geschaffenen Kunden-Nutzen übersteigen. Das ist der Fall, weil die Elemente nach Nutzen sortiert sind und an dem Punkt alle sehr werthaltigen Dinge schon umgesetzt sind. Das Team steigt dann in den „Long Tail“ der Produktentwicklung ein und realisiert Dinge mit weniger Nutzen.

Die wirtschaftliche Entscheidung des Auftraggebers an diesem Punkt sollte es sein, die Entwicklung dort zu beenden und die Ressourcen der Organisation für ein anderes Vorhaben mit höherem Nutzen einzusetzen. Dazu muss dieser Abbruch im Vertrag verankert sein. Wenn das Team zu großen Teilen extern besetzt ist, hat der Dienstleister jedoch wenig Interesse diesen Punkt schnell zu erreichen. Bei Abbruch der Entwicklung, der vor der vereinbarten Projektlaufzeit liegt, entsteht dem Dienstleister ein finanzieller Nachteil.

Money for Nothing: Zur Kompensation dieses Nachteils erhält der Auftragnehmer einen Teil des eingesparten Projektbudgets, ohne dafür Leistungen zu erbringen. Der Auftraggeber spart Geld für die Umsetzung von Funktionen mit wenig Nutzen. Die Laufzeit der Produktentwicklung wird kleiner und Kosten der eigenen Organisation sinken ebenfalls.

Der Dienstleister hat ein Interesse diesen Punkt sehr schnell zu erreichen, weil der dann größere verbleibende Anteil, ohne Leistung geteilt wird.

Diese Idee basiert auf mehreren Ansätzen, die gleichzeitig entwickelt wurden. Jeff Sutherland hat diesen Namen 2008 in einem Blog-Post so genutzt, dieser Begriff hat sich dann für diese Vertragsklausel durchgesetzt.

In Kategorie: Blog
Kommentare 0

Procurement – The undervalued agile Enabler

Mit agilen Produkt-Entwicklungen oder auch DevOps Teams geht es dem Unternehmen um Geschwindigkeitszuwachs und den Fokus auf das Wesentliche. „Das Wesentliche“ ist dabei das Element der Liefergegenstände mit dem größten Business Nutzen. Nun gibt es viele Ideen und Methoden das Wichtige vom weniger wichtigen zu unterscheiden, dem Business Nutzen zu messen und zu priorisieren. Ebenso geht es bei agilen Methoden auch immer um die Beschleunigung von Prozessen, schnellen Entscheidungen und Verringerung von Wartezeiten.

In realen Projekten werden diese Benefits für das Unternehmen dennoch nicht immer so schnell oder gut erreicht. StartUp‘s bekommen das besser hin als große Organisationen höre ich dann oft.
Banal ist es dann, danach zu fragen was die Motivation der Teammitglieder ist. Ein komplett extern eingekauftes Team (ggf. auch noch von einem Dienstleister) wird dann auf Time & Material eingekauft. In Langform heißt das: Wir, Dein Kunde bezahlen mehr Geld an Dich, wenn die Tätigkeiten die Du uns in Rechnung stellst lange dauern.
Die Zufriedenheit des Kunden muss dabei vom Team so hoch gehalten werden, dass der Kunde die Kosten und das Risiko für das Austauschen des Teams nicht eingehen möchte. Dieser Tradeoff muss nicht formuliert sein oder von den Teammitgliedern absichtlich ausgerechnet werden, aber schwingt doch irgendwie mit. Entscheiden die Teams wirklich selbst wer wann zum Team kommt, oder werden Entwickler vom eingekauften Unternehmen (vom Management) entsendet? Nach welchen Kriterien entscheidet das Management dort?

Der Einkauf hat mit der Vertragsgestaltung und dem darin festgelegtem Anreizsystem einen hohen Einfluss auf das Realisieren von agilen Werten im Unternehmen. In meiner Wahrnehmung wird der Einkauf aber in Transformationsprozessen für diese wichtige Rolle noch zu wenig eingebunden. Agile Anreizsysteme, Themen zu Festpreisprojekten, Aufwandsschätzungen, Erfolgsbeteiligungen und Risk-Sharing Modellen sind aus meiner Sicht wesentliche Enabler für das Realisieren von hartem messbarem Business-Value. Das agile Verhalten der Teams wird so besser belohnt.

In Kategorie: Blog
Kommentare 0

Hire attitude not skills

Bei Einstellungsgesprächen aber auch bei Interviews externer Coaches erlebe ich immer wieder wie Personalabteilung oder Manager die Checkliste von Skills durchgehen. Gerade heute hatte ich wieder ein Telefonat, in dem nach Branchenknowhow Pharma und einem speziellen Agile Tool zur Testautomatisierung gefragt wurde.

Im gleichen Unternehmen laufen lange und teure Change Prozesse, um agiles Mindset zu etablieren. Wie wertvoll ist da ein passendes Mindset bei einem Mitarbeiter dem ein Jira Kurs fehlt?

In Kategorie: Blog
Kommentare 0

Organization follows Purpose

Eine erfolgreiche Organisation hat ein klares, kommunizierbares Ziel und arbeitet gemeinsam als auch messbar auf dieses hin. Organisationselemente, Skills der Teams und Werkzeuge werden in der Gründungsphase auf dieses gemeinsame Ziel ausgerichtet. Mit diesem Grund der Organisationsbildung entsteht Alignment. Produkte der Organisation sind Schritte auf die Zielerreichung hin. Produkte verändern sich schneller als der Purpose.  Der Grund, das Ziel ist der stabile Kompass dieser Veränderung.

Die lernende Organisation versteht sich dabei nie als „fertig“. Produkte unterliegen einem Lebenszyklus und verändern sich.  Statt einer Transformation der Organisation kann sich eine transformierbare Organisation besser auf die Veränderungen einstellen als eine „fertig“ transformierte auf die nächste Veränderung.

Wenn eine Organisation aber nach Produkten gefragt wird, statt der Kunde; oder wenn gar die Organisation nach dem Ziel befragt wird, ist damit die Organisation selbst dieser Kompass. Die Organisation wird zum Purpose. Anpassungen erfolgen dann so an den Produkten, dass diese noch besser und schneller von der gegebenen Organisation erzeugt werden können. Der Kundennutzen tritt dabei in den Hintergrund. Das Alignment an den Zielen nimmt ab, da ja alle Organisationeinheiten die Ziele mitformuliert haben. Die Ziele decken die Tätigkeiten aller ab. Jeder findet sich wieder.

Leadership ist die Aufgabe einen klaren Purpose zu definieren und Freiheiten zu schaffen, dass sich die Organisation darauf ausrichten kann. Das Ergebnis fühlt sich gut an. Als erfahrener Experte (mastery), kann ich mit diesen Freiheiten (autonomy) optimal auf dieses Ziel (purpose) hinarbeiten.

In Kategorie: Blog
Kommentare 0

Verantwortung übernehmen statt Verantwortlichkeiten erfüllen

Verantwortung ist etwas was man sich selbst nimmt, weil man etwas erreichen möchte.

Verantwortlichkeit bekommt man zumeist übertragen und muss etwas tun von dem man nicht immer überzeugt ist, dass es das richtige ist – aber man wird eben „verantwortlich gemacht“.

Wenn die Einstellung (Ziel) und die Fähigkeiten (Mastery) nur unzureichend mit den übertragenen Aufgaben zusammenpassen wird das Ergebnis darunter leiden. In einer Umgebung, die jemanden dafür bestraft, dass man aus Überzeugung Verantwortung übernimmt und proaktiv denkt, Aufgaben übernimmt und Entscheidungen trifft, zahlt sich Verantwortung nicht aus. Wenn motivierte, fähige Menschen tun sollen was man Ihnen und Verantwortung unterdrückt wird, ziehen sich diese Menschen auf Ihre „Aufgaben“ zurück und leben Verantwortlichkeiten. Das Ergebnis der Arbeit wird das zeigen.
Die Illusion der Strukturierung von Zuständigkeiten sollte nicht mit Führung verwechselt werden. Eine RACI Matrix über 3 Seiten wird die Übernahme von Verantwortung nicht begünstigen. Die Matrix wird genutzt werden, um zu beweisen, dass man selbst „nicht schuld“ war – weil man ja nicht zuständig war.
Verantwortung kommt aus der Motivation für ein Ergebnis, braucht Raum und Support. Diese Einstellung ermöglicht exzellente Ergebnisse und ist gute Führung.

Siehe dazu auch „The Responsibility Process” von Christopher Avery.

In Kategorie: Blog
Kommentare 0

Was ich aus organisatorischer Veränderung über mich sich selbst lernen kann

Wir nehmen so viele Eindrücke auf, dass wir diese Flut filtern müssen. Wir nehmen Zustände oder Verhalten um uns herum selektiv wahr. Manche dieser Beobachtungen führen dazu, dass wir auch den Antrieb verspüren das beobachtete Verhalten der Menschen oder Zustände der Organisation zu verändern. In diesen Fällen wurden „Trigger“ in uns ausgelöst. Der Trigger ist ein Ausdruck für einen Widersprüche zwischen Beobachtung und unseren eigenen Überzeugungen. Überzeugungen und Glaubenssätze sind müssen uns nicht immer selbst bewusst sein. An diesen Widersprüchen zwischen Überzeugung und Beobachtung reiben wir uns aber so, dass wir das Beobachtete verändern wollen, um diesen inneren Konflikt aufzulösen. Wir wollen die Organisation verändern, um die zwei Sichten anzugleichen und den Konflikt damit für uns abzubauen.
Im Meeting beschäftigen sich 3 Teilnehmer mit dem PC und der Organisator des Meetings hat die Agenda nicht vorbereitet. Wenn Sie nun den Grundsatz haben: „Mehrere Personen zusammen sollten aus Respekt zueinander die Zeit effektiv nutzen.“; fällt Ihnen das auf. Je nachdem wie wichtig Ihnen dieser Grundsatz ist, wollen Sie dieses Verhalten dann evtl. auch verändern.

Interventionen betreffen nun andere Menschen. In den Fällen, wo diese Interventionen im Widerspruch zu Glaubenssätzen dieser betroffenen Personen stehen, ergibt sich Widerstand. In diesen Fällen ist die Arbeit an den Überzeugungen wichtig. Alleinige Maßnahmen zur Veränderung der Situation löst diesen Widerspruch nicht auf.
Reflektieren Sie für sich doch mal Situationen, die Sie dazu bewegt haben, aktiv Veränderungen zu beginnen. Sie werden bewusste und unbewusste Überzeugungen finden. Wenn diese dann wieder einmal getriggert werden – kennen Sie das Prinzip und können bewusst darauf reagieren.

In Kategorie: Blog