Schlagwortarchiv für: Agile Coaching

Warum ist ein Scrum Master kein Projektmanager?

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.

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

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

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.

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

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!

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.

Impact durch Frechheit

Oliver Holle ist Gründer und Managing Partner von Speedinvest – dem ersten Frühphaseninvestor Österreichs. Speedinvest investiert in Start-Ups, die noch in den Kinderschuhen stecken, um sie auf ihrem Weg zu einem großen Unternehmen zu unterstützen. In diesem Interview erzählt Oliver, aufgrund welcher Eigenschaften er und sein Team sich für ein Start-Up entscheiden. Außerdem spricht er darüber, wo Wirksamkeit schnell erzielt und welche Art von Kultur etabliert werden sollte, um erfolgreich zu sein.


Speedinvest hat den richtigen Riecher – Wie trefft ihr eure Investitionsentscheidung?

Speedinvest ist der erste Frühphaseninvestor Österreichs und entwickelt heimische Start-Ups zu großen börsennotierten Scale-Ups. Das Portfolio von Speedinvest kann sich sehen lassen! Bekannte Größen wie Bitpanda, Shpock, GoStudent, MyClubs oder TIER, der Marktführer im Bereich E-Scooter. Das sind nur einige Start-Ups die durch Speedinvest in einer rasanten Geschwindigkeit wachsen konnten. Aber wie erkennt man welche Start-Ups viel Erfolgspotential besitzen? Genau auf diese Frage geht Oliver Holle in diesem Interview ein.

Oliver Holle, Gründer und Managing Partner von Speedinvest.

“Vertrauen schafft Schnelligkeit.”

– Oliver Holle


Was können große Unternehmen von Start-Ups lernen?

Richard Brenner, Agile Coach bei TechTalk.

Mein Interview mit Oliver Holle gibt interessante Einsichten über die Entscheidungsfindung von Investoren und welche Eigenschaften im Leadership eines Start-Ups wesentlich sind. Wann es sich lohnt, auch mal frech zu sein, erfahren Sie im Video.

“Wenn das Start-Up zu einem großen Unternehmen geworden ist, ist eine positive Kultur und Kulturträger im Middle Management besonders wichtig. Eine gute Kultur lebt mit Prozessen und Strukturen die eingeführt werden. 100% Impact und Fokus sind besonders wichtig. Das sind die Unternehmen die dann extrem gut funktionieren.

– Oliver Holle


Verpassen Sie nicht unser nächstes Interview!

Im TechTalk Business Agility Dialogue durchleuchten wir kritisch die Themen Agilität und Transformation in großen Organisationen. Wir werfen einen Blick auf die wichtigsten Stolpersteine und Learnings mit Agile Change Leadern.

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.

Solution Focus: Fragen Sie nach der erwünschten Zukunft und nicht nach den Problemen

Als Agile Coach bin ich öfter mit Rahmenbedingungen konfrontiert, die Personen oder ganze Teams daran hindern, konstruktiv und zielgerichtet zusammenzuarbeiten. Dadurch verursachte Irritationen sind nicht nur im Team selbst spürbar. Auch die Führungspersonen bemerken, dass in Ihrem Bereich etwas nicht rund läuft.  

Die Probleme können in unterschiedlichsten Bereichen angesiedelt sein. Hier nur einige Beispiele: 

  • Fehlende, unklare oder widersprüchliche Zielvorgaben für Teams 
  • Missverständnisse bei der operativen Zusammenarbeit  
  • Äußere Abhängigkeiten, die schwer adressiert werden können

Die betroffenen Teams oder auch einzelne Personen beschäftigen sich häufig sehr intensiv mit diesen Problemen. Sie versuchen, sie bis ins letzte Detail zu analysieren und zu verstehen, damit sie dann endlich eine Lösung dafür finden können. Diese Problemanalyse nimmt viel Zeit in Anspruch.

Mit Solution Focus stellen Sie die Lösung in den Mittelpunkt!

Typisch für lösungsfokussiertes Arbeiten ist ein starker Fokus auf die erwünschte Zukunft. Dafür werden alle bereits existierenden Ressourcen genutzt. Es werden positive Unterschiede betrachtet und analysiert, was genau funktioniert unter welchen Bedingungen bereits gut. Mit kleinen, schnell greifbaren Veränderungen wird ein konkret formuliertes Ziel angesteuert.  

Dem Problemfokus und damit  auch der Problemanalyse wird keine Aufmerksamkeit geschenkt.  „Der Lösung ist egal, wie das Problem entstanden ist“ (Insoo Kim Berg). Gemäss dieser Denkweise nutzt man im Solution Focus das simple und zugleich unheimlich kraftvolle Werkzeug der „Fragen und sprachlichen Interventionen“.

Die große Palette an Methoden und Tools im Solution Focus basiert fast ausschließlich auf Fragetechniken und sprachlichen Interventionen. Als Führungsperson können Sie damit u.a. folgende Veränderungen unterstützen:

  1. die Teambildung positiv beeinflussen  und die Zusammenarbeit stärken
  2. die Definition von gemeinsamen Zielen (sowie damit verbundene erkennbare Kriterien für die Zielerreichung) fördern
  3. die Veränderungsprozesse in der Organisation (Change Prozesse) sinnvoll begleiten und gestalten
  4. die rasche Überwindung von Krisen begünstigen.

Hier einige wirkungsvolle Anregungen für die Formulierung Ihrer Fragen im Business Kontext:

  • Offene Fragen laden Ihre Gesprächspartner ein, ihre Gedanken mit Ihnen zu teilen. Versuchen Sie statt „Denkt ihr, wir bekommen das hin?“ oder gar „Denkt ihr, ihr bekommt das hin?“ einfach mal „Wie können wir das gemeinsam hinbekommen?“. Oder statt „Können wir den Zeitplan halten?“ die Frage „Wie können wir den Zeitplan halten?“ 
  • Setzen Sie gerichtete und ungerichtete Fragen bewusst ein.
    • Verwenden Sie gerichtete Fragen, um möglichst konkrete und auch verbindlichere Antworten zu erhalten. Zum Beispiel statt einem „Was müsste man besser machen?“ ein „Was könnt ihr zur Verbesserung beitragen?“. Oder statt „Kann der Zeitplan gehalten werden?“ die Frage „In welchem Zeitraum könnt ihr es schaffen?“ 
    • Verwenden Sie ungerichtete Fragen, um eine Vielzahl an Ideen zusammenzutragen und die Anzahl an Antworten zu erhöhen. Ungerichtete Fragen fördern die Kreativität, und erst in einem zweiten Schritt wird aus den möglichen Optionen gewählt, was am wirkungsvollsten in der jeweiligen Situation erscheint. Statt „Wie könnt ihr das lösen?“ ein „Wie könnte man das lösen?“. Oder statt „Wieso ist die Performance so schlecht?“ die Frage „Wie könnte man die Performance verbessern?“ 
    • Fragen Sie nach Ausnahmen. Kein Problem tritt ohne Unterbrechungen auf, fragen Sie nach positiven Unterschieden. In den positiven Unterschieden sind oft erste Lösungsmöglichkeiten begründet. Hören Sie zum Beispiel „Nie schaffen wir das, was wir uns vorgenommen haben.“, dann fragen Sie „Wirklich nie? Wann ist es euch doch einmal gelungen? Und was war da anders?“. Sagt man zu Ihnen „Immer kommt X zu spät.“ dann fragen Sie „Wirklich immer? Wann ist X mal pünktlich gewesen? Wie ist es dazu gekommen, dass X da pünktlich sein konnte?“ 

Mit diesem Beitrag leiten wir eine Blog Post Serie ein, die Führungspersonen, Agile Coaches und Scrum Mastern nützliche Ideen für die tägliche Arbeit liefern soll.

Von „Doing Agile“ zu „Being Agile“

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

Business Agility Dialogue mit Erste Bank CEO Peter Bosek (Teil 2/2)

Im TechTalk Business Agility Dialogue durchleuchten wir kritisch die Themen Agilität und Transformation in großen Organisationen mit deren hochkarätigen Vertretern. Wir werfen einen Blick auf die wichtigsten Stolpersteine und Learnings mit Agile Change Leadern.

Im ersten Teil des Interviews haben wir mit Peter Bosek (CEO Erste Bank and Chief Retail Officer Erste Group) über die Kernelemente des Erfolges von George, die Herausforderungen ein innovatives Produkt wie George zu entwickeln und dieses letztendlich in bestehende Strukturen zu integrieren, gesprochen.

Im zweiten Teil dieses Business Agility Dialogues sprechen Richard Brenner, Agile Coach bei TechTalk und Erste Bank CEO Peter Bosek über die Zukunft der Agilität.

Wir befinden uns in einer Krise die einiges verändert hat. Diese Krise triggert ein Verhalten, welches wir oft bei Agile Methoden auch hervorrufen möchten. Teams beginnen cross-functional zu arbeiten, um mit einem klaren Ziel aus dieser Krise zu kommen. Ist das ein Treiber für erfolgreiche Initiativen? 

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.

Selbstorganisation und Verantwortung in der agilen Welt – Müssen jetzt alle Häuptlinge sein?

Im Rahmen des agilen Arbeitens erhält Selbstorganisation einen sehr hohen Stellenwert und damit auch die Rolle der Verantwortung. Man möchte weg von einer HiPPO-Entscheidung (Highest Paid Persons Opinion) oder dem LVD (loudest voice dominates) hin zu einer Entscheidung, die dort getroffen wird, wo die Information liegt, die notwendig ist, die beste Entscheidung zu treffen (siehe auch Intent-Based Leadership). 

Bei agilen Transformationen und bei neu aufgestellten Agilen Teams kommt es bei dieser Neuverteilung der Entscheidungskompetenz manchmal zu Widerständen. Es gibt Ängste für Fehlentscheidungen verantwortlich gemacht zu werden und eine Unsicherheit aufgrund der neuen „Last“, die die neue Verantwortung mit sich bringt.  

Es stellt sich die Frage – „Inwiefern müssen alle Menschen selbstbestimmt sein und Verantwortung übernehmen?“. Diese Frage stellte Markus Knopp im Rahmen einer Open Space Session der Freiräume Unkonferenz, die Mitte November stattfand. Aus dieser Session möchte ich zwei Erkenntnisse teilen.  

Räume aufmachen und Räume schließen 

Es ist wichtig, v.a. in der Rolle als Scrum Master, Agile Coach oder Führungskraft, zu reflektieren welche Freiräume offen sind und wo es hilft einzelnen Personen und dem Team diese auch wieder zu schließen. Beispiele für das „Schließen“ von Freiräumen sind z.B. das detailliertere Vorgeben von Regeln und Rahmenbedingungen oder Entscheidungen für das Team (vorläufig) treffen. Das Schließen von Räumen kann helfen den Fokus auf ein Thema zu lenken und dem Team oder Einzelnen auch Schutz und Sicherheit zu geben, um voran zu kommen. 

Ein Beispiel aus der Praxis: Es kann den Mitarbeitern helfen einen Fokus in der Weiterbildung zu treffen, wenn eine strategische Technologieentscheidung im Unternehmen klar getroffen und kommuniziert wird.  

Für die Gestaltung und Diskussion dieser Freiräume, z.B. in Bezug auf ein Team, gibt es auch methodische Möglichkeiten zum Beispiel mit dem Delegation Poker, um Verantwortlichkeiten zu diskutieren, sichtbar zu machen und zu vereinbaren.  

Das Team als wichtiges Element in der Selbstorganisation 

Ein weiterer wichtiger Kernpunkt in der Diskussion war auch, dass die Verantwortlichkeit und Selbstorganisation nicht auf individueller Ebene betrachtet und gefordert werden soll, sondern dass dies auf Teamebene betrachtet wird.  

 „The best architecturesrequirements, and designs emerge from self-organizing teams.“ (Agile principle) 

Dabei ist es sinnvoll, das Team als eine Einheit zu betrachten – die einzelnen Individuen in diesem Team sind dann mehr oder weniger selbstorganisiert, sind diverse Persönlichkeiten und ergänzen sich im Idealfall gut. In einem Teamgefüge ist es sogar wünschenswert, dass nicht alle Personen Häuptlinge sind.  

Die Conclusio für uns zur Selbstorganisation und Verantwortung war: Das Team ist selbstorganisiert und verantwortlich, und nicht das Individuum. Das Team trägt das Individuum mit. 

„Für eine wirklich gelungene Veranstaltung braucht man sowohl Bühnenmenschen als auch Publikum.“ (Zitat Teilnehmerin im Open Space) 

Und manchmal muss die Selbstorganisation auch über eine Teamgrenze hinaus betrachtet werden, vor allem, wenn Teams zusammenarbeiten bzw. Abhängigkeiten haben. Dies ist z.B. in Scrum of Scrums oder SAFe relevant. Hier spielt dann wieder das Öffnen und Schließen von Räumen eine Rolle, denn es kann nicht jedes Team völlig unabhängig von anderen Teams selbstorganisiert Entscheidungen treffen, sondern es müssen klare Verantwortlichkeiten und Entscheidungsrahmen vorhanden sein. 

Von „Doing Agile“ zu „Being Agile“

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

Für einen tiefergehenden Austausch stehen meine Coach-Kollegen gerne zur Verfügung. Mehr zur Stärkung der Verantwortung im Team durch eine neue Art des Leadership gibt es auch im Rahmen des Intent-Based Leadership Trainings von Jenni Jespen. 

Weiterführende Literatur: