Business Agility – was ist das eigentlich?

Es war eine der spannenden Sessions des Global SAFe Summit Ende des letzten Jahres. Die erfahrensten agile Coaches waren zusammen gekommen, um über die zukünftigen Themen zu sprechen. Was wird die agile Community in den nächsten Jahren beschäftigen? Welche praktischen Fragestellungen müssen in den nächsten Jahren beantwortet werden?

Eine der häufig genannten Antworten war „Business Agility!“

Allgemeine Zustimmung machte sich breit, jeder hatte sein persönliches Bild vor Augen, wo er mit der sehr IT-zentrierten Agilisierung in der letzten Zeit an Grenzen gestoßen war. Wir schienen auf eines der zentralen Probleme gestoßen zu sein. Doch dann stellte Dean Leffingwell eine seiner so einfachen und entlarvenden Fragen: „Was ist denn das? Welches Problem konkret ist denn da zu lösen – Business Agility?“ Raunen ging durch die Reihen, jeder versuchte, seinem Nachbarn sein Bild zu erklären, es schien doch so klar zu sein…Aber der Nachbar erzählte von einem ganz anderen Bild. Also bildeten wir ein Team, das die Themen der Business Agility mal konkretisieren sollte. Die 10 besten Leute aus allen Kontinenten waren schnell zusammengestellt und los ging´s….und schnell wurde es zäh.

Zäh wird eine Diskussion entweder, wenn keiner was zu sagen hat – oder wenn keiner richtig zuhört – und den Eindruck hatte ich in dieser Diskussion von lauter Alpha-Tieren (und Tierinnen 😉). „Es geht darum, die Fachbereiche in den Entwicklungsprozess richtig einzubinden!“ war eine der frühen Thesen. „Genau! Und wir müssen aufpassen, dass die McKinseys dieser Welt ihrer Strategieberatung nicht einfach ein agiles Stempelchen aufdrücken und als neuen heißen strategischen Scheiß verkaufen, obwohl sie die agilen Prinzipien und Werte gar nicht richtig verstanden haben! Wir müssen eine echte agile Strategieberatung aufbauen – als Leadership-Komponente des Lean Agile Enterprise der Zukunft!“ holte der zweite aus. – „Genau! Leadership-Training und Coaching ist DER kritische Erfolgsfaktor für die agile Transformation. Wir sollten mal ein echtes und umfassendes agile Leadership-Training konzipieren!“-„Genau! Und dann müssen wir klar herausstellen, wie denn die Aufbau-Organisation in einem agilen Großunternehmen aussieht!“-„Richtig! Wie bei einem meiner letzten Projekte – der agilen Transformation einer Gesamtbank!“ – „Aber wie habt ihr denn den Schalter-Service der Bank agil transformiert!“ fragte endlich einer mal was… “Ja, das haben wir in unserer Gesamtbank-Transformations-Roadmap erst mal etwas niedriger priorisiert!“ – „Habt Ihr Elemente der Sociocraty oder der Holocracy implementiert? Damit könnt ihr die Entscheidungsstrukturen im Unternehmen agil machen. Dazu habe ich sehr interessante Bücher gelesen.“

So ähnlich wogte die Diskussion, viele Post Its füllten sich und am Ende der geplanten 30 Minuten stellte sich jeder mehr oder weniger die Frage: Was konkret machen wir denn jetzt? Ich persönlich habe mir danach vorgenommen, die ersten Monate des Jahres 2019 dafür zu nutzen, die Interpretation von Business Agility zu vervollständigen und gängige Lösungsansätze auf einer Landkarte zur Business Agility zusammenzufassen. Die erste Fassung dieser Karte werde ich während meines Vortrags auf der OOP skizzieren – am 22.01. Bin schon auf die Zurufe gespannt – was auf der Landkarte noch alles fehlt!

18. January 2019|By |Blog|0 Comments

Brauchen wir DevOps? 2/2

DevOps ist nicht das, was Ihre Firma braucht, es sei denn Sie betreiben Lean Startup, eine Social-Website, ein Musik-Streaming-Dienst oder ähnliches. Was Sie stattdessen brauchen, sind die Ergebnisse, die damit erzielt werden können.
Begrenzen wir das Thema auf rund 80% der Fälle, denen ich in meiner Arbeit als Agile Coach begegne.
Zum Teil verdankt DevOps seinen Erfolg dem Bestseller The Phoenix Project. Das Buch beschreibt die Art von IT-Katastrophe, an der viele „normale“ Firmen leiden. Es spricht Leser an, die den Schmerz schlechter Qualität in der IT nachempfinden können. Im Buch rettet DevOps eine Firma vor der Pleite. Ein Happy End also.
Wenn Sie keine praktische Erfahrung mit Agile und Lean in der IT haben, dann kann DevOps schon verwirrend sein. Es herrschen viele verschiedene Ansichten über DevOps, die, je nach Kontext und wen man fragt, variieren. Sie werden also keine einheitliche Definition dafür finden. Und wenn Sie der Meinung sind, doch eine gefunden zu haben, wird sie von den DevOps-Leuten bestritten, da die Definition von DevOps noch nicht ausgereift ist.
Es kann also schwierig sein anzukündigen, dass die IT in Ihrer Organisation DevOps „machen“ wird. Wie kann das implementiert werden, wenn Ihre Mitarbeiter sich nicht auf ein gemeinsames Verständnis des Konzeptes einigen können?
Umgehen wir das Problem indem wir eine andere Frage stellen: „Was ist das gewünschte Ergebnis von DevOps?“ oder: „Was ist der Geschäftswert von DevOps?“
Eine Firma, die mit DevOps erfolgreich arbeitet, kann von sich behaupten: „Wir können jederzeit ein fehlerfreies Rollout jeder Software, die wir – oder unsere Kunden – brauchen, starten“.
Dies zu bewerkstelligen verlangt viel Automation, Feedback und Testen. Im Buch ist es dargestellt als „first and second Way“.
Zur obigen Beschreibung des Geschäftswertes könnte man hinzufügen: „Das Ziel erreichen und in Zukunft beibehalten“, das könnte „the third Way“ sein.
Es ist mir schon bewusst, dass die Autoren dieses hervorragenden Buches womöglich beleidigt sein könnten. Meine Beschreibung von DevOps ist eine fürchterliche Übervereinfachung des Umgangs mit IT-Problemen, die über Jahre gewachsen sind und deren Lösung sich äußerst schwierig gestaltet. Im Grunde möchte ich sagen: DevOps handelt vom „Machen“.
Vor allem für bestehende Organisationen aber ist die Durchführung von DevOps keineswegs schnell und einfach durchzusetzen. Der Grund dafür ist die technische Altlast innerhalb der IT, woran jede Organisation leidet. Eine fiktive Geschichte lässt sich leichter schreiben, als sich Taten in der realen Welt verwirklichen lassen. Lesen Sie dazu meinen ersten Beitrag unter demselben Titel.
Mein Vorschlag für ein Unternehmen mit einem durchschnittlichen Technologiestand ist: Konzentrieren Sie sich auf den Geschäftswert. So bleibt alles leicht verständlich.
Aufgrund meiner Überlegungen rate ich davon ab, eine einheitliche Definition von DevOps anzustreben. Stattdessen möchten Sie vielleicht eine einzige Userstory erarbeiten. Nehmen wir als Beispiel den großen Chemiekonzern, für den ich gerade tätig bin. Eine solche Story könnte lauten: „Als ‚Business‘ möchte ich eine neue Version eines Softwareproduktes auswählen und ausrollen, ohne dass IT-Mitarbeiter per Hand eingreifen müssen“.
DevOps folgt dann ganz natürlich, sobald diese einfache Userstory aufgestellt wird. Wenn sie einmal besteht, dann wird jeder in Ihrer Firma wissen, was DevOps bedeutet.

IT-Strategien in Zeiten der Agilität

Agilität ist hipp, IT-Strategieentwicklung dagegen irgendwie altmodisch und unbeweglich.
Erst jetzt, wo es nicht nur die Early Adapter sind, die sich mit dem Thema Agilisierung beschäftigen,
merken wir, dass uns oft ein strategischer Rahmen fehlt, wenn wir nur mit der These starten:
„Wir müssen beweglicher werden.“ Eine gezielt entwickelte IT-Strategie gibt uns wichtige und wertvolle
Hinweise darauf, wo und in welchen Bereichen agile Prozesse einen wirklichen Nutzen erzeugen und wo nicht.

Zum Artikel

Über Vertrauen und Kontrolle

Editorial von Dr. Thorsten Janning in der Ausgabe Juli/August 2016 des OBJEKTspektrum.
In der internationalen politischen Landschaft gibt es in der jüngeren Zeit das Phänomen, dass viele Leute sich „den starken
Mann“ an die Führung wünschen. Viele Menschen wünschen sich keine differenzierten Diskurse in einer durch viele
Kulturen, Religionen und Anschauungen heterogenen Welt, sondern klare Ansagen, eine harte Hand und scheinbar überschaubare
nationale Lösungen in einer internationalisierten und wegen ihrer Komplexität eigentlich nicht mehr durch einen
Einzelnen überschaubaren Welt. Am Horizont ist ein neuer Autoritarismus erschienen.

Interview mit Dr. Thorsten Janning auf der Manage Agile 2015

Agilität. Wie weit sind wir heute?
Ist es ein “Hip-Thema”, dass wieder verschwindet?

Hier geht’s zum Interview!

Der Scrum Master

Die Definition zum Scrum Master ist im Scrum Guide der Scrum.org mit ein paar wenigen Zeilen beschrieben: „Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält. Der Scrum Master ist ein Servant Leader für das Scrum Team. Der Scrum Master hilft denjenigen, die kein Teil des Scrum Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team sich hilfreich auswirken und welche nicht. Der Scrum Master hilft dabei die Zusammenarbeit so zu optimieren, dass der durch das Scrum Team generierte Wert maximiert wird.“ (scrum.org)

Doch was heißt das für den Alltag eines Scrum Masters?
Vom Moderator, Regel-Einhalter bis hin zum Coach muss ein Scrum Master ein vielfältiges Aufgabenspektrum erfüllen. Am einfachsten gelingt hierbei noch der Regel-Einhalter. Mit dem Scrum Guide sind die Regeln festgelegt und können einfach angewendet werden. Schwieriger wird es schon beim Moderator. Meetings müssen moderiert werden und Retrospektiven so vorbereitet werden, dass ein gutes Ergebnis erzielt wird. Hierfür sind Techniken sowie Menschenkenntnis gefragt, die dem Scrum Master helfen, ein gutes Vertrauensverhältnis aufzubauen.
Am anspruchsvollsten wird es für den Scrum Master als Coach. Das Team muss so unterstützt werden, dass Lösungen erarbeitet, aber auch Konflikte gelöst werden können.

Was muss ein Scrum Master für Sie noch leisten können?

Führungskraft – Quo vadis?

Das Zeitalter der agilen Methoden bricht an und man bekommt das Gefühl, dass sich alles radikal verändert. Auch das Thema Führung wird intensiv diskutiert. Googelt man das Thema dann stößt man schnell auf Begriffe wie z.B. Leadership, Management 3.0, Führung, Beispiele für Organisationsformen und noch vieles mehr.

Selbstorganisation durch Freiräume

Agile Praktiken fordern von Teams und Mitarbeitern selbstorganisiertes Arbeiten. Viele Vorgesetze fordern diese Selbständigkeit zwar auch von ihren Mitarbeitern, im Gegenzug wollen sie aber bei Entscheidungen gefragt werden und ständiges Feedback erhalten.

Wie soll in diesem Umfeld mit ständiger Kontrolle selbständiges Arbeiten möglich sein?

Wie man einen Tanker beschleunigt

Die Geschwindigkeit der Bearbeitung von Anforderungen an meine Software wird zunehmend zum kritischen Erfolgsfaktor für Entwicklungsorganisationen. Die Erfahrung zeigt aber, dass die meiste Zeit nicht bei den Entwicklungsteams selbst, sondern auf dem Weg von der Idee bis zur Aufnahme in das Sprint Backlog verloren geht. In dem Vortrag werden erfolgreiche praktische Veränderungen real existierender Organisationen auf der Basis von Prinzipien des Product Development Flow von Don Reinertsen und in der Anwendung skalierter agiler Praktiken vorgestellt.

OOP 2015 Webcast KEGON AG from KEGON AG on Vimeo.

Kommunikation fördert Agilität

Kommunikation ist nicht erst seit dem Agilen Manifest ein Thema in Teams und Organisationen,
auch davor war es der Grundstein einer guten Zusammenarbeit. Dennoch steht die Kommunikation heute stärker im Focus denn je.