Agile Reflection

Es gibt ein berühmtes Zitat, das oft herangezogen wird, um den Unterschied zwischen inkrementeller Verbesserung und bahnbrechender Innovation zu illustrieren: „Die Glühbirne war keine kontinuierliche Verbesserung der Kerze.“ Diese einfache Weisheit bietet eine Metapher für die Herausforderungen und Chancen, mit denen Organisationen in der heutigen schnelllebigen und disruptiven Geschäftswelt konfrontiert sind.

Warum kontinuierliche Verbesserung nicht ausreicht

Kontinuierliche Verbesserung, ein Prinzip, das tief in den Philosophien des Lean Managements und der agilen Entwicklung verwurzelt ist, betont die Bedeutung von ständigen, schrittweisen Veränderungen zur Effizienzsteigerung und zur Reduzierung von Verschwendung. Obwohl dies für die Optimierung bestehender Prozesse und Produkte unerlässlich ist, kann es Organisationen in eine Falle der Zufriedenheit locken, die radikale Innovationen – die „Glühbirnen“ – behindert.

Die Notwendigkeit für radikale Innovation

In einer Welt, die von technologischen Umwälzungen, sich wandelnden Konsumentenbedürfnissen und globaler Konkurrenz geprägt ist, reicht es nicht aus, die Kerze zu verbessern. Organisationen müssen bereit sein, nach der nächsten Glühbirne zu suchen – nach der nächsten bahnbrechenden Innovation, die Spielregeln ändert und neue Märkte erschließt.

Muster für die nächste Organisationsform

Um sich von einer kontinuierlichen Verbesserung zu radikalen Innovationen zu bewegen, sollten Organisationen folgende Muster annehmen:

1. Förderung einer Kultur des Experimentierens: Organisationen müssen eine Kultur schaffen, in der Experimentieren und Lernen aus Fehlern nicht nur akzeptiert, sondern aktiv gefördert wird. Dies schafft einen Nährboden für Innovation und ermutigt Teams, über den Tellerrand hinauszudenken.
2. Umarmung der Agilität auf allen Ebenen: Agilität sollte über die Softwareentwicklung hinausgehen und zu einem integralen Bestandteil der Organisationsstruktur und -kultur werden. Dies ermöglicht es Organisationen, schnell auf Veränderungen zu reagieren und disruptive Ideen effektiver zu verfolgen.
3. Fokus auf Nutzerzentrierung: Die tiefgehende Verständnis und Empathie für die Bedürfnisse und Probleme der Nutzer sind der Schlüssel zur Identifizierung disruptiver Innovationen. Organisationen müssen eng mit ihren Nutzern zusammenarbeiten und sie in den Innovationsprozess einbeziehen.
4. Förderung von Diversität und interdisziplinärer Zusammenarbeit: Durch die Zusammenführung verschiedener Perspektiven und Fachkenntnisse können Organisationen komplexe Probleme aus neuen Blickwinkeln betrachten und innovative Lösungen finden.
5. Investition in Technologie und Forschung: Die Bereitschaft, in neue Technologien und Forschung zu investieren, auch wenn der unmittelbare Nutzen nicht offensichtlich ist, ist entscheidend, um bahnbrechende Innovationen hervorzubringen.

Zusammenfassung

Die Transformation von Organisationen in Richtung radikaler Innovation erfordert Mut, Vision und die Bereitschaft, bestehende Geschäftsmodelle zu hinterfragen. Wie die Ablösung der Kerze durch die Glühbirne gezeigt hat, können die Belohnungen für solche Bemühungen jedoch die Landschaft verändern und den Weg für eine hellere Zukunft ebnen. Organisationen, die bereit sind, diese Muster anzunehmen und die Grenzen des Möglichen zu erweitern, werden nicht nur überleben, sondern gedeihen in der Ära der Disruption.

Übrigens…

Die Behauptung, „Agile ist tot“, könnte nicht weiter von der Wahrheit entfernt sein. In einer Welt, die von ständigem Wandel und Unsicherheit geprägt ist, erweist sich die Agilität mehr denn je als unverzichtbar.

Die Investition in Aus- und Weiterbildung auf allen Ebenen – von Teammitgliedern bis zur Führungsetage – ist dabei entscheidend. Sie stellt sicher, dass alle Beteiligten nicht nur die Fähigkeiten und das Wissen besitzen, um in einem agilen Umfeld zu navigieren, sondern auch die Einstellung und die Werte, die für den Erfolg in solch einem Umfeld erforderlich sind. „Leadership on all levels“ ist nicht nur ein Schlagwort, sondern eine Notwendigkeit für Unternehmen, die in der heutigen schnelllebigen Geschäftswelt erfolgreich sein wollen. Indem wir unsere Belegschaft auf neue Herausforderungen vorbereiten, stärken wir die Resilienz und Innovationskraft unserer Organisationen für die Zukunft.

In der Welt der Produktentwicklung herrscht oft die Annahme, dass agile Methoden nicht für Projekte geeignet sind, bei denen es auf den Zeitpunkt der Markteinführung ankommt. Dieser Artikel möchte mit diesem Mythos aufräumen und aufzeigen, dass gerade die Agilität es uns ermöglicht, Produkte zeitgerecht und mit einem klaren Fokus auf Kundenzufriedenheit und Marktvitalität zu liefern.

Betrachten wir den Prozess durch eine vertraute Linse: die Herstellung von Schokoladen-Osterhasen. Die Herausforderung ist, diese rechtzeitig zu Ostern auf den Markt zu bringen.
Traditionelle Projektmanagementmethoden konzentrieren sich oft auf das Endprodukt – den perfekten Osterhasen –, ohne die vielen variablen Elemente wie Innovation, Design, Entwicklung, Qualität, Architektur, Marketing, Vertrieb und Sicherheit ausreichend flexibel zu handhaben. Diese Variablen sind jedoch entscheidend für die Anpassungsfähigkeit und Relevanz des Produkts in einem sich schnell wandelnden Marktumfeld.

Agile Methoden ermöglichen es uns, genau hier anzusetzen. Statt das Produkt als starre Einheit zu sehen, deren Perfektion vor dem Launch erreicht werden muss, sehen wir es als dynamisches Zusammenspiel verschiedener Faktoren, die je nach Bedarf angepasst werden können. Die Kunst liegt darin, diese Variablen so zu steuern, dass sie zur richtigen Zeit in der richtigen Qualität zusammenkommen – wie bei der rechtzeitigen Lieferung unserer Schokoladen-Osterhasen zum Fest.

Eine Möglichkeit, diesen Prozess zu veranschaulichen, ist die Anwendung einer mathematischen Formel, die diese Variablen in Abhängigkeit von der Zeit darstellt. Nehmen wir an, jede Variable V – wie Innovation (I), Design (D), Qualität (Q), etc. – trägt zu einem bestimmten Zeitpunkt t unterschiedlich zum Gesamtprodukt P bei. Die Formel könnte so aussehen:

P(t)=f(I(t),D(t),Q(t),…)

Diese Formel zeigt, wie agiles Management es ermöglicht, an den Größen der einzelnen Variablen V zu „schrauben“, um das Produkt P kontinuierlich anzupassen und zu verbessern, ohne dabei den Fokus auf die Kernfaktoren – Kundenzufriedenheit und Marktvitalität – zu verlieren. Selbst wenn P kleiner ausfällt als ursprünglich gedacht, enthält es immer die minimalen Faktoren, die Begeisterung bei den Kunden auslösen und die Lebensfähigkeit des Produkts sichern.

Agile Methoden lehren uns, dass der Weg zum Erfolg nicht in der Starrheit, sondern in der Flexibilität liegt. Indem wir lernen, mit den variablen Elementen unseres Projekts geschickt umzugehen, können wir sicherstellen, dass unsere Schokoladen-Osterhasen – oder jedes andere Produkt – nicht nur rechtzeitig, sondern auch in der Qualität, die unsere Kunden begeistert, auf den Markt kommen.

PS: Falls sich jemand für die Formel interessiert, ich werde vermutlich diese Formal noch ein wenig in den nächsten Beiträgen nutzen. 😉

Ok, das ist jetzt vermutlich etwas reisserisch. Aber du bist ja schon am Lesen…

Warum die Investition in Teamkompetenz der erste Schritt zur technischen Exzellenz ist

Heute ist technische Exzellenz ein entscheidender Erfolgsfaktor für Unternehmen, die in ihren Branchen wettbewerbsfähig bleiben möchten. Doch wie erreicht man diese technische Exzellenz? Viele Unternehmen neigen dazu, sich direkt auf die Verbesserung ihrer technischen Fähigkeiten und Infrastruktur zu konzentrieren, ohne zuvor in die Kompetenz ihres Teams zu investieren. Dies ist jedoch ein Fehler.

Teamkompetenz als Grundlage

Die Kompetenz eines Teams bildet das Fundament für technische Exzellenz. Ein Team, das über die richtigen Fähigkeiten, das nötige Fachwissen und eine effektive Zusammenarbeit verfügt, ist besser gerüstet, um komplexe technische Herausforderungen zu bewältigen und innovative Lösungen zu entwickeln. Indem Unternehmen in die Entwicklung der Kompetenz ihres Teams investieren, legen sie den Grundstein für langfristigen Erfolg und Wachstum.

Die Rolle von Teamkompetenz bei der Erreichung technischer Exzellenz

Technische Exzellenz erfordert mehr als nur das Beherrschen von Programmiersprachen oder die Implementierung neuer Technologien. Sie erfordert ein tiefes Verständnis der zugrunde liegenden Prinzipien, bewährte Praktiken und die Fähigkeit, komplexe Probleme zu lösen. Ein kompetentes Team ist in der Lage, diese Anforderungen zu erfüllen und die Herausforderungen der modernen Technologielandschaft erfolgreich zu meistern.

Investition in Teamkompetenz als strategische Entscheidung

Die Investition in Teamkompetenz sollte als strategische Entscheidung betrachtet werden, die langfristige Auswirkungen auf den Erfolg eines Unternehmens hat. Unternehmen, die in die kontinuierliche Weiterbildung, Schulung und Entwicklung ihrer Mitarbeiter investieren, schaffen ein Umfeld, in dem technische Exzellenz gedeihen kann. Dies ermöglicht es erst, sich schnell an sich verändernde Marktbedingungen anzupassen, innovative Produkte und Dienstleistungen zu entwickeln und ihre Wettbewerbsfähigkeit zu steigern.

Ein Beispiel?

In einer Notaufnahme eines Krankenhauses ist ein hochqualifiziertes Team tätig. Diese Teams haben nicht nur umfangreiche Kenntnisse in ihren jeweiligen Fachgebieten, sondern auch eine enge Zusammenarbeit und klare Kommunikation entwickelt. Durch kontinuierliche Schulungen, Simulationen und praktische Erfahrungen haben sie ihre Fähigkeiten perfektioniert und sind in der Lage, auch unter extremen Bedingungen effektiv zu arbeiten.

Ein Beispiel für die technische Exzellenz dieses Teams zeigt sich in der Behandlung eines schwer verletzten Patienten, der mit lebensbedrohlichen Verletzungen in die Notaufnahme gebracht wird. Das Team reagiert sofort und koordiniert ihre Handlungen nahtlos, um den Patienten zu stabilisieren und ihm die bestmögliche Versorgung zu bieten. Jedes Teammitglied weiss genau, was zu tun ist, und arbeitet effizient zusammen, um den Patienten zu retten.

Die Fähigkeit des Teams, unter Druck zu arbeiten, komplexe Probleme zu lösen und schnell Entscheidungen zu treffen, beruht auf ihrer fundierten Ausbildung, ihrer Erfahrung und ihrer Fähigkeit zur Zusammenarbeit. Diese Kombination von Fachkompetenz und Teamarbeit ermöglicht es dem Team, auch in anspruchsvollen Situationen Spitzenleistungen zu erbringen und technische Exzellenz zu demonstrieren.

Fazit; wenn du nicht in dein Team (Kompetenz) investierst, bekommst du auch keine (technische) Excellenz!

Technische Exzellenz ist ein zwingendes Ziel für jedes Unternehmen. Doch bevor man sich darauf konzentriert, ist es entscheidend, in die Kompetenz des Teams zu investieren. Denn nur ein kompetentes Team ist in der Lage, die Herausforderungen der modernen Technologiewelt erfolgreich zu bewältigen und technische Exzellenz zu erreichen.

(Ja, einzelne Starspieler ins Team holen hilft auch nicht immer… 🙂

Wenn wir über die Rolle Product Owner sprechen ist meistens der „Scrum Product Owner“ gemeint. (Singel Team, Single Product)
Ich schreibe heute mit der Rolle des Product Owners in einem eher ganzheitlichen Kontext im Fokus. Das geht meiner Meinung nach weit über die Produktverantortung einer Person für ein Produkt und ein Team hinaus. Am ehsten kann das im LeSS gesehen werden. Da hat ein PO wirklich den Gestaltungsfreiraum um ein Produkt an den Kunden zu bringen.

Ein PO setzt nicht einfach die Roadmap des Portfolio Teams um. Ein PO hat auch nicht nur Features in seinem Backlog. Ein Product Owner verantwortet die ganzheitliche Produktentwicklung und ist für den ganzen Produkt Lebenszyklus verantwortlich. An dieser Stelle sollte ich mal Marty Cagan erwähnen.

Marty Cagan ist ein bekannter Experte im Bereich des Produktmanagements und gilt als Pionier auf diesem Gebiet. Er war ein wichtiger Mitarbeiter bei eBay und AOL und gründete später die Firma Silicon Valley Product Group (SVPG), die sich auf die Beratung von Technologieunternehmen im Bereich Produktmanagement spezialisiert hat. Cagan ist Autor des Buches „Inspired: How To Create Products Customers Love“ und ist bekannt für seine wegweisenden Ansichten und Praktiken im Bereich des Produktmanagements, insbesondere im Hinblick auf die Schaffung erfolgreicher und kundenorientierter Produkte.

Ich möchte an dieser Stelle eine Element in seinen Themen aufgreifen. Er spricht vom empowerd Product Team. Was meint er damit?

Ein „empowered product team“ (ermächtigtes Produktteam) nach Marty Cagan bezieht sich auf ein Team, dem die notwendige Befugnis, Verantwortung und Ressourcen übertragen wurden, um unabhängig und effektiv zu handeln. Hier sind einige Schlüsselelemente eines ermächtigten Produktteams nach Marty Cagan:

1. Selbstständigkeit:
   • Ein ermächtigtes Produktteam ist in der Lage, weitgehend autonom zu handeln. Es sollte nicht ständig auf Anweisungen von oben warten müssen, sondern in der Lage sein, Entscheidungen selbstständig zu treffen.
2. Befugnisse und Verantwortlichkeiten:
   • Das Team hat die notwendigen Befugnisse und Verantwortlichkeiten, um das Produkt zu gestalten und zu führen. Dies schließt die Möglichkeit ein, wichtige Produktentscheidungen zu treffen, Prioritäten zu setzen und das Team in Richtung der Produktvision zu führen.
3. Multifunktionales Team:
   • Cagan betont die Bedeutung von multifunktionalen Teams, die alle erforderlichen Fähigkeiten und Kenntnisse haben, um das Produkt zu entwickeln und zu liefern. Dies kann Entwickler, Designer, Produktmanager und andere Rollen umfassen.
4. Direkter Kundenkontakt:
   • Teammitglieder sollten in der Lage sein, direkt mit Kunden zu interagieren, ihre Bedürfnisse zu verstehen und Feedback zu sammeln. Das unterstützt ein tieferes Verständnis für die Kundenerwartungen.
5. Experimentieren und Lernen:
   • Ein ermächtigtes Team ist in der Lage, Experimente durchzuführen und aus den gewonnenen Erkenntnissen zu lernen. Dies ermöglicht eine kontinuierliche Verbesserung und Anpassung der Produktstrategie.
6. Fokus auf Ergebnisse:
   • Das Team sollte nicht nur darauf abzielen, Funktionen zu liefern, sondern auch darauf, messbare Ergebnisse zu erzielen. Der Fokus liegt auf dem Mehrwert für den Kunden und dem Beitrag zum Geschäftserfolg.
7. Schnelle Iteration:
   • Ein ermächtigtes Produktteam kann schnell iterieren, um auf Veränderungen in den Marktbedingungen oder Kundenanforderungen zu reagieren. Dies erfordert flexible Prozesse und schnelle Entscheidungswege.
8. Kontinuierliches Feedback:
   • Ein starkes Feedbacksystem sollte etabliert sein, um sicherzustellen, dass das Team kontinuierlich lernt und sich verbessert. Dies kann sowohl internes Feedback zwischen Teammitgliedern als auch externes Feedback von Stakeholdern und Kunden umfassen.

Die Schaffung ermächtigter Produktteams ist ein zentrales Element im agilen Produktmanagement und ermöglicht es Unternehmen, flexibel und reaktionsschnell auf die sich schnell ändernde Geschäftsumgebung zu reagieren.

Hier kommt die Begründung warum ein 2-3 Tage dauernder PO Trainings Event nicht reicht um ein erfolgreicher PO zu sein.

Wenn man sich überlegt was es alles braucht um ein empowerd Product Team zu haben, dann ist das ein Skillset welches weit über das Wissen von Scrum, agile und User Stories hinaus geht. Selbst wenn viele der Aufgaben natürlich an den Scrum Master delegiert werden, sollte der PO diesen Teamentwicklungs- und Organisationsentwicklungsauftrag in Auftrag geben, anleiten, finanzieren und einfordern.

Diese Aufgaben sind eher im Management zu finden. Das sind Aufgaben welche von Führungskräften wahrgenommen werden.

Genau hier liegt der Fehler welche viele Organisationen machen. Sie delegieren die Rolle des PO’s an eine extrovertierte Persönlichkeit auf Teamlevel. Ohne die Chance zu haben das Arbeitssystem zu verändern oder Changes einfordern zu können.

2-3 Tage sich mit der Rolle Prodct Owner auseinanderzu setzen ist ok als Startpunkt. Aber es braucht weit mehr Weiterbildung und Entwicklung damit die agile Produktentwicklung tatsächlich alle die Vorteile bringt welche sich die Top Führungskräfte erhoffen.

Manchmal muss man ja auch nicht alles selber schreiben. Manchmel hilft es ja schon sehr wenn man etwas bestehendes einfach übersetzt. Ich bin kürzlich auf der Suche nach Zitaten über eine Seite gestolpert. Craig Larman hat es mit seinem Beitrag ziemlich perfekt auf den Punkt gebracht, wonach ich gesucht habe. Nur gibt es noch keine deutsche Übersetzung. Oder ich habe sie bis jetzt mindestens nicht gefunden.

Daher hier sein Text: (Hier der Link zum Orighinal)

Larman’s Gesetze des Organisationsverhaltens

Nach jahrzehntelanger Beobachtung und Organisationsberatung sind hier Larmans Gesetze des Organisationsverhaltens. Es handelt sich eher um Beobachtungen als um Gesetze, die man befolgen sollte 😉

1. Organisationen sind implizit darauf optimiert, den Status quo der mittleren und ersten Führungsebene und der „Spezialisten“-Positionen und Machtstrukturen nicht zu verändern.
2. Als logische Folge von (1) wird jede Veränderungsinitiative darauf reduziert, die neue Terminologie neu zu definieren oder zu überfrachten, so dass sie im Grunde dasselbe bedeutet wie der Status quo.
3. Als Folge von (1) wird jede Veränderungsinitiative als „puristisch“, „theoretisch“, „revolutionär“, „Religion“ und „pragmatische Anpassung an lokale Belange“ verspottet – was davon ablenkt, sich mit den Schwächen und dem Status quo der Manager/Spezialisten zu befassen.
4. Als logische Folge von (1) werden einige Manager und einzelne Fachleute, wenn sie nach der Veränderung immer noch versetzt werden, zu „Coaches/Trainern“ für die Veränderung, was häufig (2) und (3) verstärkt und den falschen Eindruck erweckt, „die Veränderung sei vollzogen“, was die Geschäftsleitung und künftige Veränderungsversuche täuscht, woraufhin sie zu Branchenberatern werden.

5) (In großen, etablierten Unternehmen) folgt die Kultur der Struktur. Und in kleinen, jungen Unternehmen folgt die Struktur der Kultur.

Ausarbeitung:

Eine längere Form lautet: In großen, etablierten Gruppen folgt die Kultur/das Verhalten/die Denkweise den Veränderungen im Organisationssystem und -design und wird von diesen beeinflusst.

Das heißt, wenn man in großen, etablierten Organisationen die Kultur wirklich ändern will, muss man mit der Änderung des Organisationssystems beginnen (Gruppen, Teams, Rollen und Verantwortlichkeiten, Hierarchien, Karrierewege, Richtlinien, Mess- und Belohnungsmechanismen usw.), weil sich die Kultur sonst nicht wirklich ändert. Anders ausgedrückt: Das Organisationssystem hat einen starken Einfluss auf Denkweise und Verhalten.

Der Verfechter des Systemdenkens John Seddon hat dies ebenfalls beobachtet: „Der Versuch, die Kultur einer Organisation zu ändern, ist eine Torheit und scheitert immer. Das Verhalten der Menschen (die Kultur) ist ein Produkt des Systems; wenn man das System ändert, ändert sich das Verhalten der Menschen.“

Dies ist eine Beobachtung in großen, etablierten Organisationen; im Gegensatz dazu ist es in kleinen Start-ups genau umgekehrt: Die Struktur folgt der Kultur. Das heißt, die (wahrscheinlich einfache und informelle) Organisationsstruktur spiegelt die Denkweise und Kultur der wenigen Mitglieder des Start-ups wider. Wenn die Organisation wächst, kehrt sich das in der Regel irgendwann um und die Kultur folgt der Struktur.

Und „culture follows structure“ (in großen Gruppen) ist der Grund, warum reine „Mindset“-Ansätze wie organisatorisches Lernen in großen Gruppen nicht sehr nachhaltig oder wirkungsvoll sind und warum Frameworks wie Scrum (die sich zu Beginn stark auf strukturelle Veränderungen konzentrieren) dazu neigen, die Kultur schneller zu beeinflussen – wenn die strukturellen Veränderungen, die Scrum mit sich bringt, tatsächlich umgesetzt werden.

Hervorhebungen stammen von mir, sind im Original nicht vorhanden.

Ich habe oft beobachtet, dass Scrum Master ohne das Involvement des Teams rekrutiert werden. Ist das sinnvoll?

Genau diese Frage haben wir heute in unserem Wertwandler coffee talk besprochen…

Jedes Team ist einzigartig mit ihren Produkten, Teammitgliedern und Herausforderungen. Wir stellten die Hypothese auf, dass sie deshalb auch unterschiedliche Bedürfnisse an die Fähigkeiten eines Scrum Masters haben.

Ein paar Beispiele:

• Ist die Stimmung in einem Team angespannt, dann braucht es einen Scrum Master, der die Fähigkeit besitzt diese Stimmung zu erkennen und gemeinsam mit den Menschen daran zu arbeiten. EMPATHIE
• Hat ein Team Schwierigkeiten am Ende eines Sprints laufende Software zu liefern, braucht es einen Scrum Master, der Techniken oder Prozessadaptionen kennt dem zu begegnen. PROZESSE
• Gibt es Herausforderungen bezüglich der Abstimmung mit anderen Abteilungen in der Firma, hilft ein Scrum Master, der Erfahrung im Bereich Stakeholdermanagement mitbringt. KOMMUNIKATION
• Ist ein Team ganz neu mit Scrum unterwegs, braucht es einen Scrum Master, der ein guter Facilitator ist. FACILITATION

Wir glauben, dass es zunächst wichtig ist zu verstehen, was die grössten Herausforderungen eines Teams sind.

Des weiteren bin ich persönlich überzeugt, dass das Verhältnis zwischen den Teammitgliedern sehr relevant ist für ein performantes Team – gute Stimmung = gute Ergebnisse.

Daher würde ich bei der Rekrutierung von Menschen, die so eng miteinander arbeiten die Beteiligten mit einbeziehen. Wie siehst du das?

In der Welt des Managements ist der Begriff „Adaptives Management“ ein Game Changer, sagen sie. Aber woher kommt der Begriff? Was hat das für Auswirkungen oder Konsequenzen auf die Organisation?

Ursprünge: Der Begriff wurde in den 1970er Jahren geprägt, besonders im Kontext der Entwicklungszusammenarbeit. Er steht für eine flexible, lernorientierte Herangehensweise an komplexe Probleme.

Abgrenzung zum klassischen Management: Wo das klassische Management auf stabile Strukturen setzt, blüht das adaptive Management in der Unsicherheit auf. Es ist ein Ansatz, der Veränderungen nicht als Störung, sondern als Chance betrachtet.

Agiles Mindset: Adaptives Management fördert ein agiles Mindset – die Fähigkeit, sich anzupassen, zu lernen und in unsicheren Umgebungen erfolgreich zu navigieren.

Die Zukunft gestalten: Heute ist adaptives Management nicht nur in der Entwicklungszusammenarbeit relevant, sondern auch in Unternehmen, die in dynamischen Märkten gedeihen wollen.

Entdecke die Macht der Anpassung: [Hier den Link zu deinem Angebot einfügen]

Etwas konkreter:

Adaptives Management: Die Symbiose von Führung und Management

Führung vs. Management: Eine Gegenüberstellung:

Führung: Führung konzentriert sich auf die Inspiration, Ausrichtung und Motivation von Teams. Ein Leader setzt die Vision, inspiriert Mitarbeiter und schafft eine Umgebung, in der Kreativität und Innovation gedeihen können.

Management: Management hingegen ist auf Effizienz, Organisation und Umsetzung ausgerichtet. Ein Manager plant, organisiert, kontrolliert und optimiert Prozesse, um sicherzustellen, dass die Ziele erreicht werden.

Die Vorteile beider Ansätze:

Führung: Führung schafft Sinn, fördert Engagement und ermutigt zu Veränderungen. Sie ist der treibende Motor hinter Innovation und Kreativität und stärkt die Beziehung zwischen Mitarbeitern und der Unternehmensvision.

Management: Management gewährleistet Effizienz, Disziplin und Ausführung. Es bietet Struktur und Kontrolle, was in sich schnell verändernden Umgebungen von entscheidender Bedeutung ist.

Warum Adaptive Management?

Flexibilität: Adaptive Manager können nahtlos zwischen den Rollen von Leadership Persönlichkeit und Managern wechseln, je nach den Bedürfnissen der Situation.

Kontinuierliche Anpassung: In einer sich ständig wandelnden Geschäftswelt ist es entscheidend, schnell auf neue Herausforderungen zu reagieren. Adaptive Manager sind in der Lage, flexibel und proaktiv auf Veränderungen zu reagieren.

Ganzheitlicher Ansatz: Indem beide Führung und Management kombiniert werden, schafft Adaptives Management eine ganzheitliche Herangehensweise an die Unternehmensführung. Es bringt Inspiration und Effizienz in Einklang.

Fazit: Die Debatte um Führung versus Management ist nicht nur akademisch, sondern hat praktische Auswirkungen auf den Erfolg von Organisationen.
Durch die Annahme eines adaptiven Managementansatzes erkennen Unternehmen an, dass sowohl Führung als auch Management integraler Bestandteil einer erfolgreichen Strategie sind.

Eine solche Integration fördert nicht nur ein dynamisches und innovatives Arbeitsumfeld, sondern ermöglicht es Unternehmen auch, sich flexibel an eine sich ständig verändernde Welt anzupassen. In der Synthese von Führung und Management liegt die Kraft des adaptiven Managements.

---

Als Coach oder Scrum Master nimmt man sein Team an verschiedenen Anlässen oder Meetings in den Blick. Stell dich einmal an den Rand des Raumes und beobachte, wie sich die Mitglieder deines Teams miteinander unterhalten. Hast du schon einmal darüber nachgedacht, ob es in der internen Teamkommunikation Muster gibt?

Ich behaupte, dass du als Coach oder Scrum Master viel über dein Team lernen kannst, wenn du die Kommunikationsmuster erkennst.

Ich nutze zur Unterscheidung folgende Begrifflichkeit: Dialog, Diskussion, Diskurs, Debatte und Interview. Bevor wir loslegen, hier eine Unterscheidung der verschiedenen Formen:

Diese Gesprächsformen lassen sich grob in zwei Kategorien unterteilen: strukturierte Gespräche und informelle Gespräche.

Strukturierte Gespräche:

Debatte:

• Charakteristik: In einer Debatte vertreten zwei oder mehr Parteien unterschiedliche Standpunkte zu einem Thema.
• Ziel: Überzeugen des Publikums von der Richtigkeit des eigenen Standpunkts.

Diskussion:

• Charakteristik: Ein informeller Austausch von Meinungen und Ideen.
• Ziel: Verständnis fördern, unterschiedliche Perspektiven beleuchten.

Interview:

• Charakteristik: Eine Person stellt Fragen, eine andere antwortet.
• Ziel: Informationen sammeln, eine Perspektive vertiefen.

Informelle Gespräche:

Dialog:

• Charakteristik: Ein offener Austausch von Ideen zwischen zwei oder mehr Personen.
• Ziel: Gemeinsames Verständnis entwickeln.

Diskurs:

• Charakteristik: Ein breiter und strukturierter Austausch von Ideen zu einem Thema.
• Ziel: Tiefgehende Untersuchung eines Themas, oft in einem akademischen Kontext.

Die Unterschiede zwischen ihnen liegen in der Struktur, dem Ziel und der Art der beteiligten Personen. Eine Debatte ist oft formeller und hat das klare Ziel, eine Seite zu überzeugen, während ein Dialog oder eine Diskussion eher auf Verständnis und Zusammenarbeit abzielt. Ein Diskurs kann tiefer und akademischer sein, während ein Interview spezifischer darauf abzielt, Informationen von einer Person zu erhalten. Alle diese Formen können je nach Kontext und Ziel variieren.

Wenn ich nun die Gruppe betrachte, frage ich mich, welche Dialogform gerade genutzt wird. In einem Planning erwarte ich Dialog oder Diskurs. Manchmal ist auch eine Diskussion hilfreich, zum Beispiel, wenn der Security-, Architektur- oder Test-Mensch das Team von etwas überzeugen möchte. Interview oder Debatte finde ich eher unangemessen.

In einer Retro wünsche ich mir am ehesten einen Diskurs oder einen Dialog.

Es gibt viele Beispiele, in denen ich als Coach oder Scrum Master überlege, welche Dialogform die richtige wäre und was mein Team jetzt gerade benötigt. Meine Interventionen zielen dann eher darauf ab, die Kommunikationsform zu ändern, und ich übernehme die Moderation mit diesem Ziel.

Beim Stöbern in der Bücherecke bin ich über „Uncle Bob’s“ Buch Clean Agile. Die Essenz der agilen Softwareentwicklung – Zurück zu den Ursprüngen: Die agilen Werte und Prinzipien effektiv in der Praxis umsetzen gestolpert. Es ist bereits im July 2020 raus gekommen, aber das ist an mir vorbeigerauscht… Jetzt habe ich es entdeckt und gelesen. Ich finde es ein sehr cooles Buch. Es beschreibt die Ursprünge der agilen Bewegung und um was es sich wirklich geht.

Dabei hat er die Bill of Rights der Kunden und der Entwickler erwähnt. Das kannte ich bis heute nicht. Finde diesen als Zusatz zum agilen Manifesto aber sehr spannend und hilfreich.

Einige der Autoren des Agilen Manifests haben die Customer Bill of Rights und die Developer Bill of Rights entwickelt. Durch diese Rechte wird klarer, was agile Entwicklung ist und was nicht. Die Kenntnis dieser gegenseitigen Rechte hilft dem Kunden, den Entwickler zu verstehen und umgekehrt.

Hier die Übersicht:

Kundenrechte (Bill of Rights)
Die Kundenrechte beinhalten die folgenden Punkte:

• Du hast das Recht auf einen Gesamtplan und darauf zu wissen, was wann und zu welchen Kosten erreicht werden kann.
• Du hast das Recht, aus jeder Iteration den größtmöglichen Nutzen zu ziehen.
• Du hast das Recht, den Fortschritt in einem laufenden System zu sehen, das durch wiederholbare Tests, die du festgelegt hast, bewiesen hat, dass es funktioniert.
• Du hast das Recht, deine Meinung zu ändern, Funktionen auszutauschen und Prioritäten zu ändern, ohne exorbitante Kosten zu zahlen.
• Du hast das Recht, über Änderungen im Zeitplan und im Kostenvoranschlag informiert zu werden, so dass du rechtzeitig entscheiden kannst, wie du den Umfang reduzierst, um den gewünschten Termin einzuhalten. Du kannst jederzeit kündigen und erhältst ein funktionierendes System, das deine bisherigen Investitionen widerspiegelt.

Rechte des Entwicklers
Die Rechte des Entwicklers umfassen Folgendes:

• Du hast das Recht zu wissen, was benötigt wird, und zwar mit klaren Prioritätserklärungen.
• Du hast das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.
• Du hast das Recht, um Hilfe von Kollegen, Managern und Kunden zu bitten und diese zu erhalten.
• Du hast das Recht, deine eigenen Schätzungen zu erstellen und zu aktualisieren.
• Du hast das Recht, deine Verantwortung zu übernehmen, anstatt sie dir auferlegen zu lassen.

Das sind sehr starke Aussagen. Wir sollten sie nacheinander betrachten. Der nachfolgende Text stammt im Original von Robert C. Martin Oct 29, 2019

Ich habe den Text übersetzt und an einigen Stellen leicht angepasst.

Rechte der Kunden

Das Wort „Kunde“ bezieht sich in diesem Zusammenhang auf Geschäftsleute im Allgemeinen. Dazu gehören echte Kunden, Manager, Führungskräfte, Projektleiter und alle anderen, die die Verantwortung für den Zeitplan und das Budget tragen oder die für die Ausführung des Systems bezahlen und davon profitieren werden.

1. Die Kunden haben das Recht auf einen Gesamtplan und darauf zu wissen, was wann und zu welchen Kosten erreicht werden kann.

Viele Menschen haben behauptet, dass die Planung im Voraus nicht Teil der agilen Entwicklung ist. Schon das erste Kundenrecht widerlegt diese Behauptung. Natürlich braucht das Unternehmen einen Plan. Natürlich muss dieser Plan den Zeitplan und die Kosten enthalten. Und natürlich sollte dieser Plan so genau und präzise wie möglich sein.

Gerade der letzte Punkt bringt uns oft in Schwierigkeiten, denn die einzige Möglichkeit, sowohl genau als auch präzise zu sein, besteht darin, das Projekt tatsächlich zu entwickeln. Wenn wir weniger tun, ist es unmöglich, beides zu erreichen. Um dieses Recht zu gewährleisten, müssen wir Entwickler also sicherstellen, dass unsere Pläne, Schätzungen und Zeitpläne den Grad unserer Unsicherheit richtig beschreiben und die Mittel festlegen, mit denen diese Unsicherheit gemindert werden kann.

Kurz gesagt, wir können uns nicht darauf einigen, feste Umfänge zu festen Terminen zu liefern. Entweder müssen die Umfänge oder die Termine weich sein. Wir stellen diese Weichheit mit einer Wahrscheinlichkeitskurve dar. Wir schätzen zum Beispiel, dass es eine 95%ige Wahrscheinlichkeit gibt, dass wir die ersten zehn Stories bis zum Termin fertigstellen können. Eine 50%ige Chance, dass wir die nächsten fünf bis zum Termin fertigstellen können. Und eine 5 %ige Chance, dass die fünf darauffolgenden bis zum Termin fertig werden.

2. Die Kunden haben ein Recht auf diese Art von wahrscheinlichkeitsbasierten Plänen, weil sie ohne sie ihr Geschäft nicht führen können.

Die Kunden haben das Recht, aus jeder Iteration den größtmöglichen Nutzen zu ziehen.

Agile unterteilt den Entwicklungsaufwand in feste Zeitabschnitte, die Iterationen genannt werden. Das Unternehmen hat das Recht zu erwarten, dass die Entwickler zu jedem Zeitpunkt an den wichtigsten Dingen arbeiten und dass jede Iteration den größtmöglichen Nutzen für das Unternehmen bringt. Diese Wertpriorität wird vom Kunden in den Planungssitzungen zu Beginn einer jeden Iteration festgelegt. Die Kunden wählen die Storys aus, die ihnen den größten Nutzen bringen und die in die Schätzung des Entwicklers für die Iteration passen.

3. Die Kunden haben ein Recht darauf, den Fortschritt in einem laufenden System zu sehen, dessen Funktionstüchtigkeit durch wiederholbare, von ihnen festgelegte Tests nachgewiesen ist.

Das scheint offensichtlich zu sein, wenn du es aus der Sicht des Kunden betrachtest. Natürlich haben sie das Recht, schrittweise Fortschritte zu sehen. Natürlich hat er das Recht, die Kriterien für die Akzeptanz dieses Fortschritts festzulegen. Natürlich haben sie das Recht, schnell und wiederholt den Beweis zu sehen, dass ihre Abnahmekriterien erfüllt wurden.

4. Die Kunden haben das Recht, ihre Meinung zu ändern, Funktionen auszutauschen und Prioritäten zu ändern, ohne exorbitante Kosten zu zahlen.

Schließlich handelt es sich um Software. Der Sinn von Software besteht darin, dass wir das Verhalten unserer Maschinen leicht ändern können. Die Weichheit ist der Grund, warum Software überhaupt erst erfunden wurde. Deshalb haben die Kunden natürlich das Recht, die Anforderungen zu ändern.

5. Die Kunden haben das Recht, rechtzeitig über Änderungen im Zeitplan und in der Schätzung informiert zu werden, damit sie entscheiden können, wie sie den Umfang ändern, um den gewünschten Termin einzuhalten.

Die Kunden können jederzeit kündigen und erhalten ein brauchbares, funktionierendes System, das die bisherigen Investitionen widerspiegelt.

Beachte, dass die Kunden nicht das Recht haben, die Einhaltung des Zeitplans zu verlangen. Ihr Recht beschränkt sich darauf, den Zeitplan durch Änderung des Umfangs zu beeinflussen. Das Wichtigste, was dieses Recht mit sich bringt, ist das Recht zu wissen, dass der Zeitplan in Gefahr ist, damit er rechtzeitig geändert werden kann.

Die Rechte der Entwickler/innen

In diesem Zusammenhang sind Entwickler/innen alle, die an der Entwicklung von Code arbeiten. Dazu gehören Programmierer, QA, Tester und Business-Analysten.

1. Die Entwickler haben das Recht zu wissen, was benötigt wird, und zwar mit klaren Prioritätserklärungen.

Auch hier liegt der Schwerpunkt auf dem Wissen. Die Entwickler haben ein Recht darauf, die Anforderungen und die Wichtigkeit dieser Anforderungen genau zu kennen. Natürlich gelten für Anforderungen dieselben Einschränkungen der Praktikabilität wie für Schätzungen. Es ist nicht immer möglich, die Anforderungen genau zu formulieren. Und natürlich haben Kunden das Recht, ihre Meinung zu ändern.

Dieses Recht gilt also nur im Rahmen einer Iteration. Außerhalb einer Iteration werden sich die Anforderungen und Prioritäten verschieben und ändern. Aber innerhalb einer Iteration haben die Entwickler das Recht, sie als unveränderlich zu betrachten. Denke jedoch immer daran, dass die Entwickler/innen auf dieses Recht verzichten können, wenn sie eine geforderte Änderung für unbedeutend halten.

2. Entwickler/innen haben das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.

Dieses Recht ist vielleicht das wichtigste von allen. Entwicklerinnen und Entwickler haben das Recht, gute Arbeit zu leisten. Das Unternehmen hat kein Recht, den Entwicklern vorzuschreiben, dass sie Abstriche machen oder minderwertige Arbeit leisten sollen. Oder anders ausgedrückt: Das Unternehmen hat kein Recht, Entwickler/innen dazu zu zwingen, ihren beruflichen Ruf zu ruinieren oder gegen ihre Berufsethik zu verstoßen.

3. Entwickler/innen haben das Recht, um Hilfe von Kolleg/innen, Manager/innen und Kund/innen zu bitten und diese auch zu erhalten.

Diese Hilfe kommt in vielen Formen. Programmierer/innen können sich gegenseitig um Hilfe bei der Lösung eines Problems, der Überprüfung eines Ergebnisses oder dem Erlernen eines Frameworks bitten, um nur einige Beispiele zu nennen. Entwickler/innen können Kunden bitten, Anforderungen besser zu erklären oder Prioritäten zu verfeinern. Meistens gibt diese Erklärung den Programmierern das Recht zu kommunizieren. Und mit dem Recht, um Hilfe zu bitten, kommt auch die Verantwortung, Hilfe zu geben, wenn man darum gebeten wird.

4. Entwickler/innen haben das Recht, ihre eigenen Schätzungen zu erstellen und zu aktualisieren.

Keiner kann eine Aufgabe für dich schätzen. Und wenn du eine Aufgabe schätzt, kannst du deine Schätzung jederzeit ändern, wenn neue Faktoren ans Licht kommen. Kostenvoranschläge sind Schätzungen. Es sind zwar intelligente Schätzungen, aber es sind immer noch Schätzungen. Es sind Schätzungen, die mit der Zeit besser werden. Schätzungen sind niemals Verpflichtungen.

5. Entwickler/innen haben das Recht, ihre Aufgaben anzunehmen, anstatt sie zugewiesen zu bekommen.

Fachleute nehmen Arbeit an, sie bekommen keine Arbeit zugewiesen. Ein professioneller Entwickler hat das Recht, „nein“ zu einer bestimmten Aufgabe zu sagen. Es kann sein, dass der/die Entwickler/in sich nicht sicher ist, ob er/sie die Aufgabe erledigen kann, oder dass er/sie glaubt, dass die Aufgabe besser für jemand anderen geeignet ist. Oder es kann sein, dass der/die Entwickler/in die Aufgabe aus persönlichen oder moralischen Gründen ablehnt.6

In jedem Fall hat das Recht, eine Aufgabe anzunehmen, seinen Preis. Akzeptanz bedeutet Verantwortung. Der akzeptierende Entwickler übernimmt die Verantwortung für die Qualität und die Ausführung der Aufgabe, für die ständige Aktualisierung des Kostenvoranschlags, damit der Zeitplan eingehalten werden kann, für die Mitteilung des Status an das gesamte Team und für die Bitte um Hilfe, wenn diese benötigt wird.

Programmieren im Team bedeutet, eng mit Junioren und Senioren zusammenzuarbeiten. Das Team hat das Recht, gemeinsam zu entscheiden, wer was tun soll. Ein technischer Leiter kann einen Entwickler bitten, eine Aufgabe zu übernehmen, hat aber nicht das Recht, jemandem eine Aufgabe aufzudrängen.

In den letzten Wochen hatte ich wieder einige Dialoge mit Menschen über Sinn und Unsin von Skalierung geführt. Als Verfechter von möglichst puristischen und nach Einfachheit strebender Organisationsformen erhöht sich dann mein Puls immer ein wenig über den üblichen Wert hinaus.

Wie vielen anderen Menschen kommen mir dann einige Antworten eher spät in den Sinn. Darum schreibe ich mir hier mal eine auf… hoffentlich erinnere ich mich dann wieder daran. 🙂

Das Gesetz, auf das ich mich beziehe, wird oft als „Parkinsonsches Gesetz“ oder „Parkinsonsches Gesetz der Arbeit“ bezeichnet. Es wurde vom britischen Historiker und Schriftsteller Cyril Northcote Parkinson in seinem Essay „Parkinson’s Law“ im Jahr 1955 formuliert. Das Gesetz besagt, dass Arbeit sich in dem Maße ausdehnt, wie Zeit für ihre Erledigung zur Verfügung steht. Es bedeutet, dass, wenn Sie einer Aufgabe mehr Zeit geben, als eigentlich notwendig ist, die Aufgabe dazu neigt, diese zusätzliche Zeit in Anspruch zu nehmen, ohne dass dies unbedingt zu einer besseren Qualität führt.

Der Wert des Parkinsonschen Gesetzes in der Softwareentwicklung: Warum Scrum rockt!

In der Welt der Softwareentwicklung, wo Zeit, Ressourcen und Effizienz von entscheidender Bedeutung sind, kann das sogenannte Parkinsonsche Gesetz oft ein unerwarteter Verbündeter sein. In der heutigen schnelllebigen Geschäftswelt, in der Innovation und Marktanpassung von zentraler Bedeutung sind, können wir uns nicht leisten, Projekte zu haben, die sich endlos erstrecken. Das ist einer der Gründe, warum Scrum für die Softwareentwicklung, so brillant ist.

Kleine, konstante Schritte statt endloser Wartezeit

Scrum zwingt uns, in kurzen, regelmäßigen Intervallen – in der Regel zwei Wochen – Ergebnisse zu liefern. Warum ist das so wertvoll? Weil es das Parkinsonsche Gesetz zu Deinem Gunsten nutzt. Wenn wir Dir sagen, dass Du zwei Wochen Zeit hast, um eine Aufgabe zu erledigen, wirst Du diese Zeit auch nutzen. Das Ergebnis? Du erhältst in zwei Wochen ein lieferbares Stück Software, anstatt drei Monate oder länger zu warten.

Bessere Transparenz und Anpassungsfähigkeit

Scrum bietet auch eine unschätzbare Transparenz und Anpassungsfähigkeit. Durch die regelmäßigen Sprints weißt Du genau, wo das Projekt steht. Wenn sich die Anforderungen ändern oder neue Erkenntnisse auftauchen, können diese leicht in den nächsten Sprint einfließen, ohne dass eine monatelange Änderungsanfrage erforderlich ist.

Bessere Qualität und Kundenzufriedenheit

Das regelmäßige Testen und die kontinuierliche Integration in Scrum ermöglichen es, Qualitätsprobleme frühzeitig zu erkennen und zu beheben. Du erhältst in kurzen Abständen neue Funktionen und kannst schneller Feedback geben, was zu höherer Kundenzufriedenheit und besserem Produktdesign führt.

Also…..

In einer Welt, in der Zeit Geld ist und der Wettbewerb erbarmungslos ist, ist das Parkinsonsche Gesetz wichtig. Scrum nutzt dieses Gesetz, um die Lieferung von Ergebnissen zu beschleunigen, die Qualität zu verbessern und die Anpassungsfähigkeit zu erhöhen.

Anstatt Monate auf eine versprochene Lieferung zu warten, kannst Du mit Scrum alle zwei Wochen echten Fortschritt sehen. Und das ist der Grund, warum Scrum in der modernen Softwareentwicklung für Dich rockt!

Oder du triffst dich mit anderen Leidensgenossen regelmässig um zu planen was in 3 Monaten möglicherweise passiert sein soll, oder in den meisten Fällen eben nur Wunschdenken bleibt. Releaseplanung ist super, PI ist halt PIPI.