Schlagwortarchiv für: Agile

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.

Roulettespiel oder Management?

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!

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

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.

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

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.

Reduzieren von Technical Debt in SAFe®

Technische Schulden sind der Fluch eines jeden modernen (und nicht so modernen) IT-Produkts. Wie bei einem faulen Kredit hat man Mühe, die Zinsen zurückzuzahlen, geschweige denn die Schulden zu tilgen. 

Technical Debt nimmt viele heimtückische Formen an, wie z. B. fehlende Testautomatisierung, veraltete Dokumentation, ineffizienter Code, veraltete Architektur und Sicherheitsschwachstellen aus alten Technologien. Und es interessiert die Stakeholder meistens erst dann, wenn sie beginnen die schlechte Leistung oder die lange Entwicklungsdauer und damit steigende Kosten neuer Funktionen zu hinterfragen.  Oft erreicht man den Punkt, an dem die Kosten für den Austausch des systemkritischen Produkts geringer sind als das Risiko, weitere Änderungen vorzunehmen. Muss das so sein?

Ist das auch für Agile Coaches relevant? Aus meiner Sicht absolut, da wir alle Rahmenbedingungen berücksichtigen müssen, um einen effektiven Agile Release Train oder auch ein einzelnes Team zu coachen. Oft müssen erst die technischen Hausaufgaben erledigt und die technischen Rahmenbedingungen geschaffen werden, bevor man tatsächlich iterativ inkrementell entwickeln kann. Im schlimmsten Fall beschleunigt man sonst sogar den Aufbau von technical Debt. 

Technischer Schuld vorbeugen

Wenn wir heute in klassischen Organisationen damit beginnen in kurzen Zyklen zu arbeiten — sei es ein einzelnes Scrum – oder mehrere agile Teams, die mit SAFe® arbeiten —so wird eine Kernkompetenz des Scaled Agile Framework oftmals unterschätzt: „Team and Technical Agility“.

Bereits in Scrum spricht man am Ende eines Sprints von einem „Potentially Releasable Increment“. Das heißt, dass die Teams nach 2-4 Wochen ein Stück Software bereitstellen, das so gute Qualität hat, dass man es potentiell releasen kann ohne dafür noch einen „Hardening“-Sprint (Antipattern) oder Release-Phasen von 6 Wochen zu benötigen.

In SAFe existiert hierfür die System Demo, die alle zwei Wochen eine über alle Teams integrierte Lösung bereitstellt. Das erhöht natürlich die Qualitätsanforderungen nochmals. Der Spruch „you can’t scale crappy code“ trifft es ziemlich genau.

Nur wenn wir dem Konzept von Built-In-Quality rigide folgen, können wir in so einer Geschwindigkeit liefern, sonst erhöhen sich die technischen Schulden noch viel rascher als in einem klassischen Vorgehen.

Quelle: Scaled Agile

Konkret benötigt jedes agile Team heutzutage folgende Skills, für die das Scaled Agile Framework auch jeweils aussagekräftige  tiefgehende Artikel zur Verfügung stellt:

  • Agile Architecture, die Software-Architektur muss zulassen, dass Systeme über die Zeit wachsen und sich verändern
  • Agile Testing, ein test-first Ansatz, der weit darüber hinaus geht, nur über „Unit Tests“ zu sprechen.
  • Behaviour-Driven Development (BDD): Ein weiterer Aspekt des agilen Testens, bei dem es darum geht System-Verhalten zu beschreiben und automatisiert zu testen.
  • Test-Driven Development: Test schreiben, alle Tests laufen lassen, danach nur so viel Code schreiben, dass der Test grün wird und erst danach Refactoring anwenden, wenn benötigt.
  • Refactoring: Der Quellcode und das System werden kontinuierlich auf Basis der neuen Anforderungen angepasst und erweitert. Auch dies erfordert, dass das System diese Veränderung zulässt und wir eine ausreichende Testabdeckung vorliegen haben, um sicherzustellen, dass man nichts durch dieses Refactoring zerstört hat.
  • Spikes: Oft versucht man eine Story fertig zu machen, auch wenn noch zu viele technische Risiken dahinterliegen. SAFe® bietet hierfür das Konzept der „Enabler“, die künftige Story Umsetzung ermöglichen („enablen“) sollen. Ein Spike ist eine konkrete Ausformulierung eines Enablers um vorab wichtige Experimenten durchzuführen, sodass das Risiko mitigiert wird.

All diese Kompetenzen werden heute von „Software Engineers“ erwartet, die mehr sind als nur „Coder“. Wenn wir agil arbeiten und zum Beispiel ein Stream Aligned Team aufsetzen möchten, dann benötigen wir hochqualifizierte Engineers, die genau diese Praktiken verstehen und umsetzen. 

Von Agile Coaches und Scrum Mastern erwarten wir heutzutage umfangreiches Wissen über diese Praktiken, sonst fehlt ein wesentlicher Teil des Coachings.

Nur so vermeiden wir technische Schuld und vor allem auch den raschen Aufbau technischer Schuld über agile Vorgehensweisen.

Strategie für bestehende Technische Schuld 

Gratulation, Sie haben technische Schulden? Ab jetzt haben Sie die Wahl zwischen einer teuren Lösung um neue Funktionalität hinzuzufügen oder einer günstigen „Augen zu und durch“ Variante. Zweite Lösung wird leider oft präferiert und führt nur zu noch mehr technischen Schulden.

Was sind die meisten Gründe für technische Schulden?

In einem Artikel von DZone wird eine Studie des Software Engineering Institute erwähnt, die 1319 Entwickler gefragt hat, was aus Ihrer Sicht die Gründe dafür sind:

Quelle: DZone

Deckt sich diese Beobachtung mit ihrer Wahrnehmung? Was sind bei Ihnen die Gründe? Schlecht qualifizierte Entwickler, die von sich aus den Shortcut über der guten Lösung wählen? Markt-Druck? Druck vom Fachbereich, der mehr Features will und kein Verständnis für refactoring hat? Falsche Architektur?

Erster Schritt: Technical Debt transparent und quantifizierbar machen

Ein Technical Debt Backlog kann dabei helfen konkret quantifizierbar und messbar zu machen, wie viel Aufwand bereits in die Beseitigung von technischen Schulden geht.

Capacity Allocation

Planen Sie in jedem Fall eine gewisse Kapazität Ihres Backlogs dafür ein, „Enabler“ Stories ohne Diskussion machen zu können.

So vermeiden Sie unnötige Diskussionen mit dem Fachbereich oder den Business Stakeholdern warum gewisse technische Dinge getan werden müssen. 

Wenn die benötigte Kapazität zu hoch wird kann man dann auch darüber diskutieren, warum das geschieht. Also auch hier gilt es, transparent zu sein und ständig zu beobachten ob zum Beispiel Bugs und die Behebung von technischen Schulden verhältnismäßig die Überhand übernimmt gegenüber Neuentwicklungen.

Just do your Job as an Engineer

Eine sehr persönliche Meinung von mir als Agile Coach und ehemaliger Software Engineer ist, dass es in der Verantwortung jedes Entwicklers und Team-Mitglieds liegt gute Qualität zu liefern und nicht zu viele Kompromisse einzugehen. Jeder Entwickler ist der Experte für seinen Job. Das Team an sich benötigt ein gut abgestimmtes Qualitäts-Verständnis und ist in der Verantwortung dies auch durchzusetzen. Leider lassen die Teams oft zu schnell zu, dass man Kompromisse und Shortcuts in der Qualität eingeht. 

Conclusio

Technical Agility ist ein Kernkonzept in SAFe. Mit einem Test-First Mindset, verhindert SAFe den Aufbau von mehr Technical Debt und unterstützt proaktiv den Abbau von Technical Debt.

Gleichzeitig fördert SAFe über die Kombination von IT- und den für Business verantwortlichen Rollen auf allen Ebenen den ständigen Dialog auf Augenhöhe. IT ist nicht der “Lieferant” für Business. Wir sitzen alle im gleichen Boot. Stellen wir sicher, dass es gut schwimmt. 😉

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.