Schlagwortarchiv für: Agile

CoMo Camp Wien: Die erste (Un-)Konferenz zu Collaborative Modelling

/von

Agile Frameworks haben Deine komplexen Probleme nicht gelöst, sondern nur transparent gemacht? Dann lass uns beim CoMo Camp gemeinsam an einer Lösung arbeiten. 

TechTalk unterstützt die erste (Un)Konferenz zum Thema Collaborative Modelling, und das Beste daran, sie findet in Wien statt!  

Aber stop: was ist Collaborative Modelling eigentlich?

Deine Toolbox um komplexe Herausforderung zu meistern! Einfach gesagt ist Collaborative Modelling der Gattungsbegriff für ein Methodenset, das sich als hilfreich herausgestellt hat, wenn mehrere Personen zusammenarbeiten, um komplexe Probleme schneller zu verstehen, Lösungsansätze zu finden und Entscheidungen effizienter zu treffen. Kommend aus dem Bereich der Software-Entwicklung (Domain Driven Design) hat sich Collaborative Modelling mittlerweile als Best Practice im Produktdesign und der Organisationsentwicklung etabliert.

Collaborative Modelling-Tools: die 3 besten Tools um kollaborativ zu arbeiten  

  • EventStorming by Alberto Brandolini (hilfreich um mit einer großen Menge an Menschen komplexe Sachverhalte und Prozessketten zu visualisieren)
  • Business Model Kanvas by Alexander Osterwalder & Yves Pigneur (hilfreich um herauszufinden, ob man mit einer Idee auch Geld machen kann)
  • Domain Story Telling by Stefan Hofer and Henning Schwentner (hilfreich um Domänenwissen rasch für nicht-Expert:innen greifbar zu machen)

Darüber hinaus gibt es viele weitere Methoden und Tools, die alle gemein haben, dass sie nicht dogmatisch sind und einen starken Fokus auf Visualisierung haben. Visualisierungen helfen uns das konkrete System und zu lösende Problem besser zu verstehen (problem space). Missverständnisse werden dabei frühzeitig erkannt und beseitigt. Das ist die Grundlage, um kund:innenorientierte Produkte und erste Schritte auf deren Umsetzungsweg zu erarbeiten (solution space). 

Warum solltest Du das ComoCamp nicht verpassen: Ikonen und interessante Workshops/OpenSpaces 

Das ComoCamp in der Praxis: Nicht nur dabei sein, sondern was schaffen!  Das ComoCamp bringt Expert:innen vom Kaliber eines Alberto Brandolini (Erfinder EventStorming) oder Gojko Adzic (Erfinder Impact Mapping) zusammen, um über die neuesten Entwicklungen und Best Practices im Bereich Collaborative Modelling zu diskutieren. Die Veranstaltung bietet eine Vielzahl von Open Spaces, die von den Expert:innen und Teilnehmer:innen gestaltet werden. Das gemeinsame Interesse aller Beteiligten ist

  • voneinander zu lernen, welche Methoden wann am besten eingesetzt werden können,
  • zu verstehen wie die Methoden am besten in einander greifen,
  • eventuelle Widersprüche oder weiße Flecken zu entdecken,
  • alternative Ansätze oder Ergänzungen einzubringen und
  • Impulse für konkrete eigene Problemstellungen mitzunehmen.

TechTalk und COMOCAMP Logo Grafik

TechTalk als Enabler des ComoCamps 

Was wir derzeit beobachten:

Viele österreichische Organisationen sagen heute, dass sie erfolgreich agile Frameworks wie Scrum auf Teamebene einsetzen. Manche haben auch schon in der Skalierung Lösungen gefunden und liefern somit effizient. Oftmals wird aber die Frage der Effektivität („Tun wir die richtigen Dinge?“ vs. „Tun wir die Dinge richtig?“ – Effizienz) vernachlässigt oder sie wird zum Politikum – sowohl auf der Produkt- als auch auf der Architekturebene. Dies passiert aus unserer Sicht nicht mit böser Absicht, sondern deshalb, weil die Aufgabenstellungen zu komplex werden oder zumindest erscheinen.

Florian Raimann, TechTalk Experts Ansprechpartner

In genau solchen Situationen ist unserer Meinung nach Collaborative Modelling hilfreich, um voranzukommen, indem wir ein gemeinsames Bild schaffen, Komplexität oftmals reduziert werden kann und alle am gleichen Strang ziehen. Deshalb unterstützen wir das ComoCamp mit voller Leidenschaft und entlang unseres Leitsatzes „Deliver software that matters“.

Collaborative Modelling-Trends: Was erwartet uns in Zukunft in diesem Bereich? 

Diese Frage werden wir nach dem ComoCamp 2023 gemeinsam beantworten können – wir freuen uns auf Dich und Deine Inputs!

Wollt Ihr mehr zum Thema Collaborative Modelling erfahren?

Dann verpass das ComoCamp nicht!

Jetzt Tickets kaufen

Agile Breakfast: Courageous Change – based on Fearless Journey

/von

Change is hard and leading is dangerous – no matter what your role is! And sometimes you can feel like there’s no way forward and change is impossible. 

Zvonimir Durcevic and Robert Finan would like to inspire and equip you with some ideas for courageously overcoming obstacles to change. First we will look at some of the concepts and patterns that can be used to overcome resistance to new ideas, as described in the book Fearless Change (by Linda Rising and Mary Manns). Then we will play the Fearless Journey game, (created by Deborah Preuss) which explores these patterns in more detail. During the game you will have time to have a conversation about their application to the obstacles you face in the real world. Through this we hope to help you find new ways of leading change!

Details zur Veranstaltung:

15.11.2022, von 08:30 bis 10:00 Uhr
Techtalk GmbH, im Saturn Tower, 16. Stock
Leonard-Bernstein-Strasse 10, 1220 Wien 

Anmeldung

Ja, ich komme sehr gerne!

Wir würden uns freuen, Sie begrüßen zu dürfen.

PS: Sollten Sie verhindert sein, informieren wir Sie gerne über künftige Ausgaben unserer Agile Events.

… bitte laden Sie mich zum nächsten Termin ein und senden Sie mir die Slides von diesem Agile Breakfast zu!

Warum ist ein Scrum Master kein Projektmanager?

/von

In einem zunehmend dynamischen und komplexen Geschäftsumfeld setzen Unternehmen gerne auf „agile“ Arbeitsmethoden. Sie reorganisieren reflexartig ganze Unternehmensbereiche in „agile Teams“ und ordnen den Menschen neue agile Rollen zu. Ein besonders beliebter Ansatz: Projektmanager werden zu Scrum Mastern, weil das ja ohnehin nahezu dasselbe wäre. Ein Irrtum, der so manche agile Transformation gefährdet.

Aus Projektmanagern werden Scrum Master?

Mit dem Wechsel zu agilen Arbeitsweisen nimmt der Bedarf für klassisches, planungsgetriebenes Projektmanagement ab. Damit stellt sich im Unternehmen die Frage, welche Aufgaben Projektmanager in Zukunft wahrnehmen werden. Oftmals lautet die Schlussfolgerung: Wir machen Projektmanager zu Scrum Mastern – das ist ohnehin nahezu dasselbe!

Es ist natürlich völlig in Ordnung, einen Projektmanager zu einem Scrum Master auszubilden. Aber es ist ein Irrtum zu glauben, dass es keinen großen Unterschied gibt zwischen dem gibt, was die Person bisher gemacht hat und dem, was sie zukünftig tun soll.

Projektmanager und Scrum Master ist nicht dasselbe

Lyssa Adkins stellt in ihrem Buch „Coaching Agile Teams – A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition“ klar, dass die Rolle des „Projektmanagers” und die Rolle des „Scrum Masters” nichts miteinander zu tun haben:

„A Project Manager plans and controls, supervising throughout. A Scrum Master guides. A project manager’s success equals the success of the project. A Scrum Master’s success equals the Team’s continual improvement and their pursuit of high performance. The two are focused on completely different things and thus act completely differently. For these reasons, the road from Project Manager to Scrum Master may be a bit longer than others. Core underpinnings of Project Management are replaced.”

Das bedeutet: sich „Scrum Master” zu nennen, aber in der Rolle des „Projektmanagers“ weiterzumachen, geht nicht.

Zwei Tage Training machen noch keinen Scrum Master

Wer viele Jahre oder Jahrzehnte als Projektmanager gearbeitet hat, der kann nicht von heute auf morgen seine hart erkämpften Werte und Prinzipien über Bord werfen. Schon gar nicht, wenn er von der Linienorganisation zum „Scrum Master” ernannt wird und ein 2-Tages-Training als Fundament für seine neue Rolle bekommt. Jeder neue Scrum Master braucht mindestens 3-6 Monate Begleitung und Coaching durch einen erfahrenen Scrum Master oder Agile Coach.

Gravitation wirkt – wer zweifelt daran?

Das Coaching eines neuen Scrum Masters beginnt bei der Auseinandersetzung mit den Werten und Prinzipien, die ihm als Projektmanager bisher Halt und Motivation in der täglichen Arbeit gegeben haben. Lyssa Adkins schlägt vor, sich dabei am Bild der Gravitation als Naturgesetz zu orientieren: Wir akzeptieren die Gravitation ohne Diskussion. Sie ist immer da und lässt sich nicht hinterfragen. Gleiches gilt auch für neue Business-Gesetze in einer zunehmend dynamischen, volatilen und komplexen Geschäftswelt, die wir akzeptieren müssen, wie beispielsweise:hahnicht hinterfragen. Gleiches gilt auch für neue Business-Gesetze in einer zunehmend dynamischen, volatilen und komplexen Geschäftswelt, die wir akzeptieren müssen, wie beispielsweise:

  • Die Geschäftswelt bewegt sich rasend schnell. Es entstehen laufend Situationen, die niemand vorhersehen konnte.
  • Die Bedürfnisse der Kunden verändern sich laufend.
  • Was ein Team leisten kann, weiß nur das Team selbst.
  • Man kann kein Commitment für jemand anderen eingehen und dann davon ausgehen, dass sich diese Person gemäß dem eigenen Commitment verhält.

Projektmanager halten gerne reflexartig an planungsgetriebenen Werten und Prinzipien fest, um diesen neuen Business-Gesetzen zu begegnen, vor allem wenn der Erwartungsdruck steigt. Das hat aber wenig Aussicht auf Erfolg.

John P. Kotter meint dazu in seinem Buch „Accelerate: Building Strategic Agility for a Faster-Moving World”: „The world is now changing at a rate at which the basic systems, structures, and cultures built over the past century cannot keep up with the demands being placed on them”. Siehe https://www.kotterinc.com/book/accelerate/

Daniel Pink verdeutlicht in seinem Buch „Drive -The Surprising Truth About What Motivates Us “, dass Wissensarbeiter – beispielsweise Mitarbeiter in Projekten –  durch äußere Anreizen wie Geld und Prestige oder durch „Zuckerbrot und Peitsche“ nicht zu motivieren sind. Siehe https://www.youtube.com/watch?v=u6XAPnuFjJc

Projektmanager müssen neue Werte und Prinzipien annehmen

Um die neuen Business-Gesetze zu akzeptieren und damit erfolgreich zu sein, braucht es neue Werte und Prinzipien. Lyssa Adkins schlägt dazu vor:

Planungsgetriebene PrinzipienZu ersetzen durch
Wir können alle Arbeit planen und wir arbeiten nur so, wie wir geplant haben.Planen ist wichtig, aber ein fixierter Plan ist wertlos.
Die Planungsfaktoren Budget, Leistungsumfang (Scope) und Zeit (Meilensteine) sind fixiert (Iron Project Management Triangle)Zeit und Budget (Ressourcen) werden konstant gehalten. Aber der Leistungsumfang (Scope) ist variabel.
Ein Plan wird im Laufe der Zeit immer präziser durch die Phasen, die ein Projekt durchläuft: Requirements, Design, Entwicklung, Test, …Ein Plan wird im Laufe der Zeit immer präziser, weil er laufend angepasst wird an die Gegebenheiten der Realität und an die tatsächliche Leistungsfähigkeit der Teams.
Erfolg bedeutet, den fixierten Leistungsumfang in der vorgegebenen Zeit und dem dafür allokierten Budget zu liefern.Erfolg bedeutet, möglichst schnell und laufend Wert für Kunden zu generieren.
Der Leistungsumfang ist vorab fixiert. Jede Veränderung muss über Change Requests verhandelt werden.Der Leistungsumfang ist flexibel. Jede Veränderung ist willkommen, weil sie das Projekt der Realität näher bringt.
Laufendes Controlling über einen präzisen, fixierten Projektplan ist die wichtigste Aufgabe.Controlling über einen fixierten Projektplan ist unmöglich. Vertrauen in die Leistungsfähigkeit der Teams und volle Transparenz zum Lieferfortschritt sind wichtige Controlling-Faktoren.
Fortschritt ist messbar über erledigte Tasks und die Einhaltung von Lieferungen für die vorgegebenen Meilensteine.Fortschritt ist messbar über den Wert, der bei den Kunden tatsächlich ankommt.

Woran ist erkennbar, ob ein Projektmanager zu einem Scrum Master wird?

Lyssa Adkins benennt konkrete Beobachtungen, an denen sich festmachen lässt, ob ein Projektmanager die Transformation zum Scrum Master erfolgreich durchläuft:

  • Legt den Fokus auf die Zusammenarbeit des gesamten Teams und nicht mehr auf die Koordination von Individualleistungen.
  • Ist mehr ein Katalysator für das Wachstum des Teams und weniger ein Fachexperte.
  • Investiert mehr in die Performance des gesamten Teams und weniger in die Fertigstellung bestimmter Lieferpakete zu einem bestimmten Meilenstein.
  • Fragt immer zuerst das Team um Antworten und gibt nicht alle Antworten gleich selbst.
  • Lässt das Team seine Arbeitsweise selbst bestimmen und ist kein Micromanager.
  • Vermittelt dem Team Sinn, Bedeutung und Wichtigkeit und treibt keine Ergebnisse gemäß Projektplan ein.
  • Lenkt das Augenmerk auf die laufende Generierung von Kundenwert (was ist jetzt das Richtige für den Kunden), und nicht auf Meilenstein-Lieferungen für ein bestmögliches Gesamtpaket.
  • Bringt Probleme zur Lösung in das Team und ist nicht immer selbst derjenige, der die Probleme für das Team löst.

Was wäre ein erster sinnvoller Schritt?

Es ist völlig klar, dass Projektmanager die hart erarbeiteten Werte und Prinzipien einer planungsgetriebenen Projektumsetzung nicht über Nacht ersetzen können durch agile Werte und Prinzipien.

Aber jeder neu nominierte Scrum Master, der zuvor als Projektmanager gearbeitet hat, sollte sich die folgenden Fragen stellen: Bin ich bereit, meine bisherigen Überzeugungen aufzugeben und mich auf die neuen Business-Gesetze einer zunehmend dynamischen, volatilen und komplexen Geschäftswelt einzulassen? Habe ich die Neugier, das Interesse und die Offenheit, einen anderen Weg einzuschlagen? Bin ich zutiefst davon überzeugt, dass es der richtige Weg für das Unternehmen ist?

Lyssa Adkins beschreibt zehn typische Wesensmerkmale eines Scrum Masters, die auch jeder Projektmanager inne haben sollte, der sich auf die Reise zum Scrum Master begibt:

  1. Hat ein intuitives Gespür für die Emotionen, die in einem Raum voller Menschen vorhanden sind.
  2. Kümmert sich lieber um die Menschen, die großartige Ergebnisse zustande bringen, als um die Ergebnisse selbst.
  3. Bewahrt sich eine natürliche, kindliche Neugier und stellt laufend Fragen, um mehr zu erfahren. Er weiß, dass er nicht alles wissen kann.
  4. Glaubt an das Gute in den Menschen.
  5. Agiert im Moment mit den Teams, weil morgen alles anders sein kann.
  6. Ist lernbegierig und wissensdurstig. Er will jeden Tag weiter wachsen, so wie das Team, das er begleitet.
  7. Glaubt daran, dass alle Menschen zu großartigen Dingen fähig sind, wenn man sie arbeiten lässt und ihnen das Vertrauen dafür gibt.
  8. Hat wenig Verständnis für institutionelle und bürokratische Hindernisse, die die Teams daran hindern, großartige Dinge zu tun. Ansagen wie „Das war schon immer so” oder „Wir wissen, dass das ineffizient ist, aber so arbeiten wir hier nun mal“ treiben ihn zur Weißglut.
  9. Kann sich darauf einlassen, dass jede Veränderung auch Unordnung und Leistungseinbußen mit sich bringt.
  10. Riskiert, mit Experimenten auch mal falsch zu liegen. Er übernimmt Verantwortung für Fehlschläge, lernt daraus und probiert etwas anderes.

Fazit und Take-Away

Liebe Projektmanager, seid Ihr bereit, Eure persönliche Reise als Scrum Master im Unternehmen zu starten? Der erste kleine Schritt: bitte versteht, dass „Scrum Master” nicht einfach ein anderes Wort ist für „Projektmanager”. Und erklärt das mit Nachdruck jedem in Eurem Unternehmen!

Dieser Beitrag wurde von Karl Mayrhofer, Agile Enterprise Coach bei UNIQA Insurance Group AG, erstellt.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

[mc4wp_form id=”25641″]

Agile Breakfast: “Unleashing Leadership! – Harnessing Management to Power Change”

/von

Change is everywhere, and it is accelerating. To stay relevant, organizations need to adapt. They need to find ways of engaging and mobilizing employees to deal with the VUCA (volatility, uncertainty, complexity, and ambiguity) world. 

Who needs to adapt? Firstly, all the people working in organizations, i.e. their employees. Secondly, the management of organizations, referring to people who broadly and traditionally run and change the business.

In our agile breakfast, we will talk about:

  • Leadership and management and why they describe related but very different processes. In particular, why we need them both.
  • Culture and leadership and how they deeply influence each other.
  • Change and what the ground conditions for change are.
  • What can managers do to create an environment where everybody can dare to take responsibility for their world. 

In the second half of our agile breakfast, we will invite you to join the conversation about the topic using the fishbowl format.

Details zur Veranstaltung:

09.08.2022, von 08:30 bis 10:00 Uhr
Techtalk GmbH, im Saturn Tower, 16. Stock
Leonard-Bernstein-Strasse 10, 1220 Wien 

Anmeldung

Ja, ich komme sehr gerne!

Wir würden uns freuen, Sie begrüßen zu dürfen.

PS: Sollten Sie verhindert sein, informieren wir Sie gerne über künftige Ausgaben unserer Agile Events.

… bitte laden Sie mich zum nächsten Termin ein und senden Sie mir die Slides von diesem Agile Breakfast zu!

Resources:

  • Heifetz, R.A., Linsky, M. (2017) Leadership on the Line, With a New Preface: Staying Alive Through the Dangers of Change, Revised Edition, Harvard Business Review Press, Boston, Massachusetts
  • Hamman, M. (2019) Evolvagility, Agile Leadership Institute, Lopez Island, WA
  • Schein, E.H. (2017) Organizational Culture and Leadership, 5th Edition, John Wiley & Sons, Inc., Hoboken, New Jersey
  • Wikipedia (2022) Management
  • Wikipedia (2021) Fishbowl (conversation)

Teamarbeit in einer agilen Transformation

/von

In einem zunehmend dynamischen und komplexen Umfeld setzen Unternehmen gerne auf „agile“ Arbeitsmethoden. Sie reorganisieren ganze Unternehmensbereiche in „agile Teams“. Die Verteilung von Arbeit erfolgt aber oftmals weiterhin durch Zuweisen von Aufgaben an Einzelpersonen. Das bringt nicht den erhofften Effekt. Im Gegenteil, es verschlechtert die Leistungs- und Lieferfähigkeit.

Der “VUCA-Reflex”: Reorganisation in “agile” Teams

Unternehmen kommen heute zunehmend in Bedrängnis, weil die traditionelle, phasenbasierte Umsetzung von Projektvorhaben (“Wasserfall”) in einem zunehmend dynamischen, komplexen und volatilen Umfeld an seine Grenzen stößt.

Sie reagieren darauf mittlerweile nahezu reflexartig mit der Reorganisation ganzer Unternehmensbereiche in „agile Teams“. Durch den Einsatz agiler Arbeitsmethoden soll sich die Leistungs- und Lieferfähigkeit deutlich verbessern.

Team-Rhetorik – aber Management von Einzelpersonen?

Nach der Reorganisation in Teams behält das (Projekt-) Management oftmals die bewährte  Arbeitsweise bei, den einzelnen Teammitgliedern individuell Aufgaben zuzuweisen und sie regelmäßig über deren Erledigung berichten zu lassen.

Beispiel für die Zuweisung von Tasks an Einzelpersonen in Teams

Warum bleibt das wirkungslos?

Richard Hackman erklärt in seinem Buch „Leading Teams“ sehr anschaulich, warum diese Form der Reorganisation nicht den erhofften Effekt hat:

A great deal of organizational work is performed these days by sets of people who are called “teams” but who really are co-acting groups. Managers in organizations where this is done may harbour the hope that they can harvest the widely touted benefits of teamwork while continuing to directly manage the behaviour of individual team members. That hope is misplaced: If you want the benefits of teamwork, you have to give the team the work.

So there is a choice here: Either design the work for a team, or design it for individuals. If done well, either strategy can yield fine results. What is not fine is to send mixed signals: to use the rhetoric of teams when the work really is performed by individuals, or to directly supervise individual members when the work really is a team’s responsibility”

Entweder Teamarbeit oder Einzelarbeit

Das Management muss Arbeit also entweder für Einzelpersonen organisieren oder für Teams. Niemals aber darf die Führung kommunizieren, dass die Arbeit ab sofort in Teams erfolgt und gleichzeitig immer noch Aufgaben an Einzelpersonen zuweisen. Das führt zu Verwirrung in der Organisation und verschlechtert die Liefer- und Leistungsfähigkeit.

Was gute Teamarbeit ausmacht, hat beispielsweise auch Google seit 2012 in einer Studie zur Effektivität von Teams sehr eindrucksvoll erarbeitet.

Scrum setzt auf Teamarbeit

Agile Frameworks wie Scrum (Unser Trainingsangebot) setzen klar auf die Organisation von Arbeit für Teams und nicht für Einzelpersonen. Agile Frameworks wie Scrum setzen klar auf die Organisation von Arbeit für Teams und nicht für Einzelpersonen. Scrum ist ein leichtgewichtiges Rahmenwerk, das Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

Für jede ausgewählte User Story plant das Team gemeinsam die notwendige Arbeit.

Das Team ist umsetzungs- und ergebnisverantwortlich

Das Team zieht sich Arbeits- oder Lieferpakete (Work Items, User Stories) aus einem priorisierten Backlog. Es ist dafür gemeinsam umsetzungs- und ergebnisverantwortlich. Das Team ist daher auch befähigt und berechtigt, sich die Arbeit für die Umsetzung und Lieferung selbst zu organisieren.

Steve Denning schreibt in diesem Zusammenhang auch vom “Law of the Small Team” als einem zentralen Element von Agilität.

Das Team organisiert sich die Arbeit im Sprint selbst

Das Team plant die Umsetzung der ausgewählten Arbeits- und Lieferpakete durch Zerlegung in kleinere Arbeitseinheiten von einem Tag oder weniger (Tasks, Aufgaben).  Wie dies geschieht, liegt im alleinigen Ermessen des Teams. Niemand sagt dem Team von außen, wie es seine Arbeit organisieren soll.

Das Team verwendet dafür zumeist ein Team-Board bzw. Task-Board, als visuelles Echtzeitbild der Arbeit, die das Team während des Sprints ausführt (Information Radiator). Das Board zeigt das Sprint-Ziel (warum ist der Sprint für das Team wichtig), die ausgewählten Arbeits- und Lieferpakete (was wird das Team liefern) sowie die Arbeitsschritte für die Umsetzung (wie organisieren wir die Arbeit im Team, um zu liefern).

Ein beispielhaftes Scrum Team Board ein einem physischen Setup (Quelle: Agile but Pragmatic)

Teamarbeit bedeutet Selbstbestimmung

Wenn das (Projekt-) Management die Liefer- und Leistungsfähigkeit über Teamarbeit steigern will, dann MUSS es den Teams zugestehen, sich die Arbeit selbst zu organisieren. Teams zu organisieren und trotzdem weiterhin Micromanagement zu betreiben durch Zuweisen von Aufgaben an Einzelpersonen, führt nicht zu mehr Leistungsmotivation, sondern im Gegenteil zu mehr Frustration und Verwirrung.

Konzernanwendungen als Hürde

Nach der Reorganisation finden sich „agile“ Teams in Unternehmen oftmals eingebettet in bestehende Konzern-Projektportfolios und die dafür definierten Konzernprozesse. Diese Abläufe sind gehärtet, sorgen für Stabilität und lassen sich nicht ohne erheblichen Aufwand anpassen.

Konzernanwendungen wie beispielsweise Atlassian Jira® unterstützen diese Prozessabläufe. Praktischerweise sowohl in der phasenbasierten Projektabwicklung als auch beim Umstieg auf „agile“ Teams.

Dies fördert jedoch die Verschränkung von traditionellen Projektmanagement-Praktiken mit „agilen“ Arbeitsweisen und die daraus entstehende Verwirrung. Beispielsweise führt das Projektmanagement oft klassische Aufgabenlisten (Jira® Tasks) nach der Reorganisation weiter als „Product Backlogs“. Beim Sprint Planning weist es weiterhin den einzelnen Teammitgliedern Aufgaben zu. Diese buchen dann über Jira® Tempo wie bisher die aufgewendete Arbeitszeit auf ihre Aufgaben für das Projekt Controlling.



Das (Projekt-) Management muss agilen Teams zugestehen, sich die Arbeit selbst zu organisieren.

Was wäre ein erster sinnvoller Schritt im Unternehmen?

In einem ersten Schritt sollte das Unternehmen ein kleines, überschaubares Pilotvorhaben nominieren, in dem die Arbeit tatsächlich einem Team übertragen wird und nicht einzelnen Personen.

  • Der Product Owner des Teams erarbeitet für das Pilotvorhaben ein priorisiertes Backlog, als Liste von priorisierten, kleinteiligen Arbeits- und Lieferpaketen (Work Items, User Stories).
  • Das Backlog enthält keine Aufgaben und Tasks für Einzelpersonen. Es legt nicht fest, wer was in einem Sprint erledigen muss!
  • Im Sprint Planning zieht sich das Team in Abstimmung mit dem Product Owner Arbeits- und Lieferpakete aus dem priorisierten Backlog. Es organisiert sich danach die Arbeit selbst, also wer was im Team tun muss, damit das Team liefert (Aufgaben, Tasks).
  • Am Sprintende zählt nur, ob es dem Team gemeinsam gelungen ist, die vereinbarten Arbeits- und Lieferpakete umzusetzen – wie immer es sich dafür die Arbeit auch organisiert hat.

Fazit und Take-Away

Die Führung muss agilen Teams zugestehen, sich die Arbeit selbst organisieren dürfen. Nur dann entsteht echte Teamarbeit. Und im Team wächst damit die Zuversicht, mehr Verantwortung zu übernehmen und eigenständig großartige Ergebnisse zu schaffen.

Dieser Beitrag wurde von Karl Mayrhofer, Agile Enterprise Coach bei UNIQA Insurance Group AG, erstellt.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

[mc4wp_form id=”25641″]

Agile Breakfast: “Wie Sie Ihren Führungsstil durch die richtige Ausdrucksweise verbessern”

/von

Am 11.05.2022 fand unser Agile Breakfast mit Jenni Jepsen statt!

Neben dem Frühstück, bekamen unsere Gäste einen Einblick in die Methoden und Prinzipien von Intent-Based Leadership (IBL). Jenni Jepsen, Autorin und Leadership-Expertin stellte bei diesem Networking-Event das IBL Kommunikationswerkzeug vor.

Mit kleinen Veränderungen Ihrer Redeweise Micro-Management hinter sich lassen und MitarbeiterInnen oder KollegInnen mehr Verantwortung geben.

Schauen Sie sich gerne hier die ganze Präsentation an! Vielen Dank an alle, die da waren!

Verändern wir die Welt mit Sprache durch Intent-Based Leadership!

/von

Agile Organisationen erfordern einen neuen Führungsstil. Dieser zeichnet sich durch Befähigung, Motivation und Eigeninitiative jedes einzelnen Mitarbeiters aus.

Führungspersonen und auch jede KollegIn mit fachlichen und technischen Führungsaufgaben fokussieren sich hierbei darauf, die Teams möglichst gut in die Eigenverantwortung zu bringen und selbst Entscheidungen treffen zu lassen. 

Intent-Based Leadership (IBL) liefert hierzu den passenden Ansatz. 

Was bedeutet Intent-Based Leadership?

Während agile Arbeitsweisen darauf abzielen, flache Hierarchien zu schaffen und MitarbeiterInnen in den Teams mehr Freiraum einzuräumen, spiegelt sich dieser neue Führungsstil jedoch nicht in der Sprache der meisten Führungspersonen wider.

Intent-Based Leadership (IBL) schafft hier Abhilfe. IBL legt den Fokus auf die Kommunikation und Sprache, die Führungspersonen und Teams verwenden, um bei der Arbeit zu kommunizieren. Hierbei handelt es sich vornehmlich um die Wörter, die wir im täglichen Miteinander und bei Fragestellungen verwenden.

Ich möchte, dass ihr ein wöchentliches Kundenmeeting abhält und Trello verwendet.

Manager Kommunikation – klassisch

Mein Ziel ist, dass wir kundenzentrierter arbeiten und ein gemeinsames System verwenden, sodass die Arbeit des Gesamtsystems transparent dargestellt werden kann.

Kommunikation nach Intent-Based Leadership Prinzip

Bei der richtigen Wortwahl können TeamleiterInnen ihren Mitarbeitern die nötige Kontrolle vermitteln, ohne selbst in einen Befehlsmodus zu verfallen. Gleichzeitig können Teammitglieder eine Sprache benutzen, um Gespräche auf Augenhöhe zu führen. Bei diesem neuen Führungsparadigma wenden sich Teammitglieder an Führungspersonen, indem sie beschreiben, was sie sehen, denken und vorhaben. 

Wir brauchen mehr Marketing Ressourcen.

Klassisches Mitarbeiter-Statement

Unsere Intention ist, dass wir eine höhere Qualität in der Marketing Produktion liefern möchten, dazu fehlen uns die Fähigkeiten im Team. Daher ist unser Plan einen zusätzlichen Social Media Experten in unser Team aufzunehmen.

Mitarbeiter-Kommunikation nach Intent-Based Leadership

Hierdurch wird nicht nur die Effektivität, sondern auch die Motivation und die Zufriedenheit aller Mitarbeiter deutlich gesteigert. IBL bietet einen sicheren Leitfaden für Organisationen, um neu zu definieren, was agile Führung bedeutet.

Was sind die wichtigsten Grundsätze von Intent-Based Leadership?

Das Konzept von Intent-Based Leadership ist das direkte Ergebnis davon, wie David Marquet, ehemaliger U-Boot-Kapitän, die USS Santa Fe vom schlechtesten zum besten Schiff der US-Marine machen konnte. In seinem Buch „Turn the Ship Around!“ beschreibt David Marquet genau, wie er dies erreichen konnte. Das Buch ist nicht nur für agile Führungspersonen äußerst empfehlenswert. 

Als David Marquet das Kommando über die USS Santa Fe übernahm,hatte er nur drei Wochen Zeit, um alles über das Schiff zu lernen – eine unmögliche Aufgabe, selbst für erfahrene Kapitäne.

Als er das Kommando übernahm, musste er schnell feststellen, dass alte Muster nicht nur ineffektiv, sondern auch gefährlich sein können. Wenn er Befehle in einer Umgebung erteilt, von der er nicht alles wusste und Untergebene diesen Befehlen blind folgen würden, könnten Menschenleben auf dem Spiel stehen. Daher beschloss er, anstelle Befehle zu erteilen, die sehr konkret waren, nur das Vorhaben (den Intent) zu beschreiben, wie zum Beispiel “ich möchte das U-Boot dorthin manövrieren, anstelle von “Luken schließen, Abtauchen, so und soviel grad einschlagen, etc..” 

Dadurch verlagerte er das Denken und Nachdenken über das “Wie erreiche ich das Ziel” zu seinen Crew Mitgliedern, die auch viel besser verstanden, warum Sie eine Aktion durchführen. Er erwähnt hier einen Mitarbeiter im Maschinenraum, der selbstständig entscheiden konnte, ob es jetzt eine gute Idee ist Lärm zu machen oder besser ist, ruhig zu sein, da er wusste, ob man sich gerade in feindlichem Gewässer befindet oder nicht.

David Marquets Führungsstil fasst die Grundsätze von IBL bestens zusammen: Führungspersonen müssen nicht immer Antworten auf alle Fragen haben oder ihre Untergebenen dazu bewegen, etwas zu vollbringen. Vielmehr geht es darum, Kontrolle abzugeben, um hierdurch die Effizienz zu steigern. Menschen, die am vertrautesten mit der Aufgabenstellung sind, werden die bestmöglichen Lösungsvorschläge liefern. 

Anwendungsbeispiel

Eines der besten Werkzeuge von Intent-Based Leadership ist die sogenannte „Ladder of Leadership“. Diese enthält einige einfache Fragen, die Führungspersonen stellen können, je nachdem, wie ihre Mitarbeiter mit ihnen sprechen. 

Wenn jemand beispielsweise sagt: „Bitte sagen Sie mir einfach, was ich tun soll“, befindet sich diese Person auf der untersten Ebene der Leiter. Die Führungsperson möchte die Mitarbeiterinnen und Mitarbeiter nach oben bringen, damit diese die nötige Sicherheit erhalten, um eigenständig Probleme zu lösen.

Die Frage, die hierzu gestellt wird, lautet schlicht und einfach: „Was sehen Sie?“ Dies ist der nächste Schritt auf der Leiter und ermöglicht den Mitarbeitern, in einer psychologisch sicheren Umgebung zu antworten, da TeamleiterInnen lediglich um eine wertfreie Beobachtung bitten. 

Auf diese Weise gewinnen Menschen schnell an Sicherheit und können bereits in kurzer Zeit die nötige Eigenständigkeit und Kontrolle übernehmen, damit sie eine Ebene erreichen, auf der sie ihrem Chef mit einer Absicht, etwas zu verändern, begegnen. Somit wird die Effizienz jedes einzelnen Mitarbeiters um ein Vielfaches gesteigert.

Wir decken in unserem Training neben der “Ladder of Leadership” noch 5 weitere Prinzipien von Intent-Based Leadership ab. Mehr erfahren.

IBL schafft neue Verantwortungsbereiche

Agile Führungspersonen, die IBL in ihren Führungsstil integrieren, müssen nicht zwangsläufig alle Antworten parat haben. Es geht nämlich primär nicht darum, Mitarbeiterinnen und Mitarbeiter zu einem bestimmten Verhalten oder einer bestimmten Aktion zu bewegen, sondern stattdessen zu ermächtigen, eigenständig Entscheidungen zu treffen sowie ein Verantwortungsgefühl zu entwickeln indem man eine klare Richtung bzw Intention des Vorhabens formuliert.

Intent-Based Leadership, führt, ähnlich wie andere agile Führungsstile auch, einen gewissen Kontrollverlust der Führungspersonen herbei. Durch diesen „Kontrollverlust“ auf sprachlicher Ebene werden gleichzeitig neue Verantwortungsbereiche geschaffen, was die Effizienz jedes einzelnen Mitarbeiters erhöht und gleichzeitig weitaus bessere Ergebnisse liefert.

Hierdurch können agile Teams und agile Organisation geschaffen werden, die sich besonders dadurch hervorheben, dass sie sich in kürzester Zeit an neue Veränderungen und Gegebenheiten anpassen können. Dies geschieht vornehmlich durch ein „Intent-based“ bzw. proaktives Verhalten der Belegschaft, was durch die Verwendung von IBL zielgerichtet gefördert wird.

Intent-Based Leadership ist die neue Grundlage agiler Unternehmen

Intent-Based Leadership hilft agilen Führungspersonen, ihren Führungsstil weiter auszubauen und Kompetenz und Eigeninitiative durch die richtige Wahl der Sprache zu vermitteln. Darüber hinaus hilft IBL selbst scheuen Mitarbeitern, Selbstbewusstsein zu entwickeln, um eigenständig die Initiative zu ergreifen.

Auch wenn das Grundprinzip nun klar sein sollte, erfordert IBL noch einiges mehr, um agile Führungspersonen in Intent-Based Leader zu verwandeln. Unser Training vermittelt neben den Grundprinzipien der Methodik auch anwendbare Werkzeuge, mit denen Sie Ihre Sprache in einer agilen Umgebung optimieren können.

Intent-Based Leadership: Ein Training mit Jenni Jepsen, einer international erfahrenen Expertin, am 12. Mai 2022 in Wien.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

[mc4wp_form id=”25641″]

Roulettespiel oder Management?

/von

Der Blick auf das große Ganze

Bei seinem Talk auf der Agile Tour Vienna lädt Peter Klimek zu einer Reise in die Welt der komplexen Systeme ein. Er definiert diese Systeme und zeigt welche Rolle einzelne Komponenten in Netzwerken spielen. Was haben Änderungen zur Folge und was bedeuten sie für unsere Organisation? Anhand von aktuellen Beispielen aus dem Gesundheits-, Finanz- und Organisationsbereich erklärt er diese Zusammenhänge.

Peter Klimek bei der Agile Tour 2021

Eins der wichtigsten Erkenntnisse aus der Komplexitätsforschung ist die Möglichkeit der Vorhersage von eintretenden Szenarien. Um dazu in der Lage zu sein, entwickeln Forscher wie Peter Klimek mathematische und statistische Modelle. Diese benötigen kleine oder große Datensätze, um solche Systeme und ihr Verhalten zu quantifizieren, verstehen und letztendlich besser handhabbar zu machen. Es ist ein spannender Vortrag, der es ermöglicht, einen Blick auf das große Ganze zu werfen und ein Verständnis für die Reichweite unserer Entscheidungen zu bekommen.

Hier geht es zum Video

Videos sind gut, aber Vorort ist besser.

Sei bei der nächsten Agile Tour mit dabei!

Agile Tour Vienna 2022

Das fehlende Lenkrad nach der „Agilisierung“ OKRs – Objectives and Key-Results

/von

Fast jede größere Organisation steckt derzeit in einem „Agilisierungsprozess“ oder hat diesen bereits vermeintlich abgeschlossen. Dieser Vorgang ist mit dem Umbau eines Raketenautos in ein Rallyeauto vergleichbar – bei voller Fahrt, wohlgemerkt. 

Raketenautos werden für die Jagd nach Höchstgeschwindigkeitsrekorden auf einer möglichst weiten und ebenen Strecke entwickelt. Dabei sind Richtungsänderungen und Bremsen unnötig, ja sogar unerwünscht und hinderlich. Das ist vergleichbar mit Geschäftsmodellen, die über Jahrzehnte skaliert und optimiert werden: nicht der Wendigste gewinnt, sondern wer am stärksten wächst und stabil die Spur halten kann. 

Rallyeautos sind dafür optimiert, kurvige Bergstraßen oder Schotterpisten möglichst schnell zu bewältigen. Vergleichbar mit dem sich immer schneller ändernden Kundenverhalten, Marktsituationen und Rahmenbedingungen der heutigen Geschäftswelt.

“The Bue Flame” ist ein Raketenauto, das am 23.10.1970 in Utah einen Geschwindigkeitsweltrekord aufstellte.
Rallyauto bei Hoher Geschwindigkeit und Kurvenfahrt.

Rekord- oder Crashkurs – Was brauchen wir?

Warum sich immer mehr große Organisationen in dieses waghalsige Unterfangen stürzen, ist ziemlich klar. Um beim Bild der Organisation als Raketenfahrzeug zu bleiben: diese befindet sich in voller Fahrt auf flacher Ebene. Und am Horizont erscheint eine Bergstraße, die es in Zukunft zu befahren gilt. 

Der Umbau selbst ist ebenfalls gut mit diesem Bild vergleichbar, denn die Windschutzscheibe muss vergrößert werden, um mehr Sicht zu haben. Analog zur Transparenz der Arbeit in agilen Teams. Die Lenkung wird direkter und der Wenderadius kleiner, um enge Kurven befahren zu können. Das entspricht den kürzeren Lieferzyklen und der adaptiven Planung. 

Kleine, autonome cross-funktionale Teams sind vergleichbar mit den elektronischen Hilfssystemen wie ABS, die bei rutschiger Fahrbahn schneller reagieren können als der Pilot selbst. Und idealerweise wird auch erkannt, dass der dicke, fette Fallschirm am Heck für die einmalige Vollbremsung auf einer Bergstraße nutzlos ist. Stattdessen werden Hochleistungsbremsen eingebaut, die von erfahrenen Piloten bedient werden, um die Bergstraße noch schneller befahren zu können. Das entspricht dem iterativen Vorgehen und den safe-to-fail Experimenten, die agile Teams zur Bewältigung der Komplexität unserer heutigen Geschäftswelt einsetzen.

Das Horrorszenario vermeiden mit OKRs

Organisationen sind gut beraten, nicht zu versuchen, alles auf einmal umzubauen. Stattdessen empfiehlt sich ein schrittweiser Umbau im Zeitraum von ein bis drei Jahren, bis das Management-Team im neuen Cockpit des Rallyeautos platznehmen kann. 

Was dann aber oft festgestellt wird, ist erschreckend: das Lenkrad fehlt! Im besten Fall ist ein behelfsmäßiger Hebel auf der Lenkspindel montiert, der vom Piloten reflexartig fixiert wird, um die Kontrolle über das Fahrzeug zu behalten. Im schlimmsten Fall blickt das Managementteam auf die nackte Lenkradmutter und stellt fest, dass damit nicht einmal mehr die Richtung festgelegt werden kann. Eine Kurvenfahrt auf der herannahenden Bergstraße ist damit ausgeschlossen. 

Objectives und Key Results sind das fehlende Lenkrad, das zur rechten Zeit eingebaut werden muss, um solch ein Horrorszenario zu vermeiden. Die OKR Methode kombiniert Methoden der Unternehmenssteuerung (MbO, SMART, Balanced Score Card, KPIs) mit agilen Prinzipien und Praktiken. Sie kommt auf allen Ebenen der Organisation (Team, Bereich, Gesamtportfolio) zur Anwendung, um messbare Zielsetzungen zu steuern. 

Einsatzbereich und Wirksamkeit von OKRs 

Ein Objective ist die verbale Definition einer Zielsetzung im Kontext einer spezifischen Situation. Dazu werden ein oder mehrere Key Results definiert, mit denen ein messbarer Fortschritt festgestellt werden kann. Die Kombination von Objective und Key Results wird als OKR-Set bezeichnet. 

Beispiel für ein OKR-Set: 

Situation: Unsere Standard Retail Produkte sind zu komplex und weder für den Kunden noch den Berater verständlich und daher aufwändig im Verkauf. Durch eine Reduktion auf die wichtigsten Deckungen und Verschlankung der Baustein-Varianten wollen wir die Effizienz steigern, Kosten senken und Kunden zufriedener machen. 

Objective: Wir haben einen sehr vereinfachten Produktrechner, der sowohl von Kunden besser verstanden wird, als auch vom Vertrieb besser für den Verkauf genutzt werden kann. Dieser wird für Kunden und einer Vertriebsgruppe online zur Verfügung gestellt. Die Verarbeitung erfolgt im Hintergrund manuell. 

Key Result #1: Die Testgruppe im Vertrieb verkauft das neue Produkt doppelt so häufig wie das alte, wenn sie selbst die Wahl haben, welches sie anbieten. 

Key Result #2: Die Kunden bewerten den Rechner (einfach, leicht verständlich) direkt nach Berechnung mit mehr als 4 (auf einer Skala 1-5). 

Key Result #3: Die Online Conversion liegt über 5%. 

OKR-Sets werden auf den verschiedenen Ebenen der Organisation (Portfolio – Team) in zyklischen Abständen definiert, abgestimmt und dann laufend verfolgt und bewertet. Die Erreichung der Ziele ist dabei ergebnisoffen und die laufende Beobachtung dient zur adaptiven Planung. 

Wozu dann noch andere agile Frameworks und Methoden? 

OKRs sind aber nur das Lenkrad des Rallyeautos. Windschutzscheibe, Lenkung und Bremsen müssen vorhanden sein, bevor die Lenkbewegungen Auswirkungen auf die Richtung des Fahrzeugs haben. Diese Funktionen erfüllen agile Prozess- und Skalierungsframeworks wie Scrum oder SAFe. Daher haben sie auch viele Mechanismen von OKRs bereits eingebaut: 

  • User Stories und Epics beschreiben bei richtiger Anwendung auch Experimente und messbare Zielsetzungen 
  • Retrospektiven definieren laufend Experimente und messbare Zielsetzungen zur Verbesserung der Zusammenarbeit 
  • SAFe Portfolio definiert „Strategic Themes“ („Objectives”) und „Key Results“ auf Value Stream Ebene 
  • Die Meetingstruktur von Scrum (Daily Scrum, Planning/Review, Retrospektiven) und SAFe (Program Increment Planning) entspricht den Meetings von OKRs (Daily Huddle, OKR Weekly, OKR Planning/Review/Retrospektive)

Daneben gibt es Methoden für Product Owner, mit denen die Lenkung an sich verbessert werden kann, die letztendlich mit dem Lenkrad verbunden wird, wie z.B.: 

Niemand möchte überrollt werden – Die richtige Einführung von OKRs

Um eine agile Steuerung der Organisation zu ermöglichen ist es daher notwendig, diese Mechanismen bereits frühzeitig im Umbau der Organisation auf Team- und Teamskalierungsebene zu berücksichtigen und zu lernen. Leider wird das bei agilen „Roll-Outs“ jedoch oft übersehen, wenn Teams schnell in neue Rollenbezeichnungen und Meetingformate gezwungen werden. „Roll-Overs“ wäre hier die bessere Bezeichnung, denn die Teams können die neu gewonnene Flexibilität nicht nutzen oder lernen, mit ihr umzugehen. 

Ein Lenkrad macht nur Sinn, wenn Lenkung, Bremsen und Windschutzscheibe vorhanden sind. Die Einführung von OKRs beginnt daher nicht mit dem Roll-Out eines OKR Werkzeugs oder einer OKR Methode, sondern mit dem Aufbau agiler Teams (z.B. nach Scrum), deren Skalierung (z.B. mit SAFe), sowie kompetenter Product Owner. Ist diese Basis einmal grundsätzlich vorhanden, ist es Zeit ein Lenkrad auf die Lenkspindel aufzusetzen, denn die Bergstraße kommt näher. 

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

[mc4wp_form id=”25641″]

Lassen Sie uns weitersprechen!

Sie wollen mehr zum Thema agile Transformation erfahren? Sie wollen in Ihrem Unternehmen ein Umfeld entwickeln, um die Arbeit nach agilen Methoden zu ermöglichen?

Kontaktieren Sie mich:

Christian Hassa
CEO & Agile Coach bei TechTalk
christian.hassa@techtalk.at