Wie kann ich unsere Unternehmensführung mit unserem agilen Team in Kontakt bringen?

Ich sehe weiterhin agile Einführungen, die sich auf das F&E- oder Engineering-Team konzentrieren. Es scheint diese Akzeptanz zu geben, dass der Kern von Agile dort liegt. Ich bin absolut nicht überzeugt. Ich denke, wenn das Unternehmen die agile Transformation nicht vollständig annimmt, ist es zum Scheitern verurteilt. Wie kann ich das Unternehmen effektiv in unsere agile Transformation einbeziehen?

Ich denke, es würde helfen zu verstehen, warum Sie denken, dass Agile im Engineering scheitern wird, weil das gesamte Unternehmen keine agile Transformation durchmacht. Müssen zum Beispiel Abteilungen wie Legal, Compliance, HR oder Investor Relations agil werden, damit Agilität im Engineering gut funktioniert?
Ich habe leidenschaftliche Engineering-Gruppen gesehen, die sich Agile zu eigen gemacht haben, und dann zusehen müssen, wie die Agile-Initiative letztendlich scheiterte. Ich habe HR-Praktiken gesehen, die von eigenmächtiger, kollaborativer Arbeit im Gegensatz zu Heldentaten absehen. Ich habe Compliance-Auditoren gesehen, die sich weigern zu akzeptieren, dass Agile ein disziplinierter und konformer Ansatz sein kann. Und ich habe gesehen, dass Führungskräfte eine nach Rangordnung geordnete Arbeit oder einen begrenzten Arbeitsansatz nicht unterstützen; Das heißt, sie treiben weiterhin "feuergetriebene Entwicklung" voran und damit Chaos, reine Qualität und Lieferung. Das führt zu der Ansicht, dass Agile fehlerhaft ist. Dieser Mangel an Unterstützung außerhalb des Engineerings führt dazu, dass Agile aufgegeben wird.
Was hast du schon probiert? Warum hat das in Ihrer Organisation bei Ihnen nicht funktioniert?
Ich denke, der Standardzustand jeder vorgeschlagenen Transformation (agile oder andere) ist ein Scheitern, es sei denn, sie wird von effektiven Sponsoren unterstützt. Trägheit und Tradition sind sehr effektiv darin, Neuheit und Veränderung zu töten. Trotzdem denke ich, dass ToddA.Jacobs Recht hat - wir können die Frage nicht verstehen oder nützliche Antworten geben, wenn wir nicht wissen, was Sie versucht haben und warum es fehlgeschlagen ist. Ich denke auch, dass die Informationen, die @jeantabaka in Kommentaren bereitgestellt hat , in der Frage enthalten sein müssen .

Antworten (7)

Ich schätze, dass Ihre Frage darauf abzielt, Engagement mit dem agilen Team zu schaffen, und nicht, das Unternehmen dazu zu bringen, agil zu sein. Ich empfehle Ihnen, mit einer Denkweise zu beginnen, bei der es keinen Unterschied zwischen dem Unternehmen und den Teams gibt. Entscheiden Sie sich dafür, zu glauben, dass beide Gruppen vollständig auf eine einzige Vision ausgerichtet sind ... und sprechen Sie dann die Teile an, die nicht mit Ihrer inneren Realität übereinstimmen.

Diese Denkweise zu übernehmen, dass es keine Grenzen gibt, hilft mir, Fehler zu vermeiden, die ich in der Vergangenheit zu oft begangen habe:

  • Agiles Verkaufen : Es geht nicht um „Agile“, es geht um bessere Geschäftsergebnisse durch die konsistente Bereitstellung hochwertiger Software, vorausgesetzt, die Software löst das Problem. Die Verwendung einer ergebnisorientierten Sprache anstelle unseres agilen Jargons hilft dem Unternehmen, leicht zu erkennen, wie sehr mir der Erfolg der Organisation am Herzen liegt, und wird dadurch viel weniger bedrohlich
  • Silo-basiertes Denken : Ich kann ein Problem nicht aus der Schublade heraus lösen. Wenn ich mich auf eine Grenze zwischen Gruppen konzentriere, weil ich mich in einer der Gruppen befinde , werde ich immer die Sprache „Wir“ vs. „Sie“ verwenden. Stattdessen werde ich eine einzelne Gruppe sehen, die ein paar Dinge tut, die keinen Sinn ergeben.
  • Undurchsichtige Ziele : Eine vollständige Transparenz über Ihre Ziele trägt viel dazu bei, Vertrauen aufzubauen. Dies erfordert jedoch, dass Sie das Silo-Denken hinter sich gelassen haben, denn diese Voreingenommenheit wird sich in Ihrer Sprache durchsetzen, wenn Sie transparent sind, und die Zuhörer werden die Fehlausrichtung zwischen Ihren Worten und Ihren Überzeugungen leicht erkennen.

In vielerlei Hinsicht kommt es einfach auf die Kernwerte von Scrum zurück: Engagement, Fokus, Offenheit, Respekt und Mut. Demonstrieren Sie diese im Laufe eines zielgerichteten Engagements, und die Menschen werden diese Werte teilen und das Engagement und die Aufmerksamkeit, die Sie anbieten, zurückgeben.

Ich bin verwundert über die Antworten von Trevor und Mark und würde mich interessieren, was „Agile“ für sie bedeutet.

Für mich sind Agile (die Philosophie) und seine verschiedenen Inkarnationen XP, Scrum etc. nur eine Möglichkeit, die Frage anzugehen, woran ich wann arbeiten soll. Sie sind ein Rahmen, um Ihr Team (und es ist mir egal, ob Sie ein Entwickler, Buchhalter oder Anwalt sind) auf die wichtigste Arbeit zu konzentrieren und Ihren Fortschritt oder Mangel daran zu kommunizieren.

Ich glaube nicht, dass irgendjemand behaupten könnte, dass Kommunikation etwas Gutes ist und dass dies das Fundament agiler Prozesse ist.

Der Wert eines Rückstands an Arbeitsaufgaben, den das gesamte Unternehmen sehen kann, kann gar nicht hoch genug eingeschätzt werden

  • Ein Verständnis dafür, was für das Unternehmen wichtig ist und in welcher Reihenfolge
  • Welchen Anteil jede Abteilung des Unternehmens daran hat, dieses Ziel zu verwirklichen
  • Einblick in die funktionsübergreifenden Abhängigkeiten
  • Und vielleicht am wichtigsten ist die Fähigkeit des Einzelnen zu sehen, wie er zum Unternehmen beiträgt, was den Effekt hat, sowohl die Qualität als auch die Quantität der produzierten Arbeit zu steigern.

Agile wurde kürzlich von meiner Organisation eingeführt (von einem teils Wasserfall- und teils kontinuierlichen Integrations-Entwicklungsmodell)

Und die Vorgehensweise des Beraters (der Agile verkaufte) ging folgendermaßen vor:

  1. Erfahren Sie, „warum“ Sie Agile einführen möchten und woran die Organisation derzeit leidet, die Sie durch Agile lösen möchten. In unserem Fall war es wenig Vorhersehbarkeit bei der Lieferung, kontinuierliche Integration, die sich nachteilig auf ein nachhaltiges Qualitätsniveau auswirkte, Menschen, die in verschiedene Richtungen gezogen wurden, kaum Wissenstransfer und Mangel an umsetzbarer Vision.

  2. Erklären und beweisen Sie, „wie“ Agile die oben genannten Probleme lösen und die Geschäftsanforderungen erfüllen wird. Auch in unserem Fall ging es um Fallgeschichten, Schulungen, Probe-SPRINTs mit dem tatsächlichen Team und vor allem darum, die Konflikte offen zu zeigen und die Konflikte mit den im obigen Punkt erwähnten Problemen in Beziehung zu setzen.

  3. Stärken Sie das Team und implementieren Sie die erforderlichen Änderungen. Es wurde teilweise durch ein paar Pilotsprints durchgeführt.

Ich persönlich habe sowohl Unternehmen gesehen, die nicht agil arbeiten, als auch Unternehmen, die agil arbeiten (die Teams, die agil arbeiten), und beide funktionieren. Meistens kann das Team, das Agile betreibt, ein Vorläufer sein und in das Unternehmen einsickern, das beginnt, Agile zu betreiben, aber manchmal passiert dies nicht. Agile leitet sich aus zwei Hauptprinzipien ab, die in Agile vergraben sind, prüfen und anpassen und das Team entscheiden lassen

Ich sehe viele Konzepte, die dieser Software ähneln, die Sie verwenden. Sie mögen diese Stackexchange-Schnittstelle. Dasselbe gilt für Teams und das Geschäft ... die Schnittstelle zum Geschäft muss sich nicht ändern (obwohl ich es vorziehe, es zu ändern, da es ein Wettbewerbsvorteil ist, flexibler und agiler zu sein, hilft dabei). Ich würde also sagen, ja, Agile kann immer noch funktionieren, ohne dass das Unternehmen Agile betreibt, aber meiner Meinung nach wäre es für das Unternehmen besser, sich ebenfalls Agilität zu eigen zu machen.

Ihr Unternehmen dazu zu bringen, Agile einzuführen oder zu akzeptieren, ist dasselbe wie jede andere Veränderungsinitiative. Sie müssen den Wert davon demonstrieren.

Zwei Punkte damit -

Zunächst müssen Sie konkrete Vorteile aufzeigen, die Agilität bietet (und anders nicht erreicht werden kann). "Alle machen es" ist nicht gut genug. Es muss für die Organisation passen.

Zweitens - Sie müssen sich daran erinnern, dass Agile keine Wunderwaffe ist. Agile ist nicht in allen Situationen anwendbar, und selbst dort ist es möglicherweise nicht die beste Lösung. Wie Mark sagte, macht es in manchen Abteilungen einfach keinen Sinn.

Kannst du mir anhand meiner Bemerkungen zu Mark mehr sagen?
Sicher - Agile selbst ist in erster Linie ein Eng-Prozess, daher wird seine Anwendung in anderen Bereichen begrenzt sein. Aber High Performing Teams können auch anderswo implementiert werden; nur nicht Großhandel. Wenn Sie möchten, dass sich Mgmt „einkauft“, müssen Sie ihnen einen Grund nennen, der sich aus Beweisen und nicht aus Behauptungen ergibt. Bringen Sie sie dazu, zuzustimmen, es in einer begrenzten, sogar eigenständigen Anwendung auszuprobieren, um die Ergebnisse zu sehen. Beweisen Sie ihnen, dass es auch in anderen Bereichen funktionieren kann. Aber jede Änderung wird inkrementell und begrenzt sein. Wenn Sie erwarten, dass Mgmt einfach zu Agile wechselt, dann sind Sie fertig, bevor Sie beginnen. Es wird einfach nicht passieren. Und ehrlich gesagt, sollte es nicht.

Letztendlich kommt es meiner Meinung nach beim agilen Übergang auf Akzeptanzvorteile im Vergleich zu agilen Phobien an .

  • Einführungsvorteile sind hauptsächlich für das Team relevant (verbesserte Qualität, Kommunikation usw.) und ich denke, dass sie auch für das Unternehmen leicht zu erreichen sind (Zeit bis zur Markteinführung, verbesserter ROI, Kundenzufriedenheit usw.).
  • Agile Phobien sind in den Managementabteilungen stark ausgeprägt (unfähig, Verpflichtungen einzugehen, unvereinbar mit verteiltem Team, nicht skalieren, ich werde als Führungskraft nichts mehr zu tun haben usw.)

Aber meiner Erfahrung nach sind Geschäftsführer oft wirklich an Führungskräfte gebunden. Es ist also eine 2-gegen-1-Situation, in der Scrum-Teams oft verdeckt bleiben, wie Sie es beschrieben haben. Vielleicht sollten Sie sich Ihre Situation genau ansehen, wenn Sie den geschäftlichen Widerstand nicht mit dem verwechseln, was wirklich dahintersteckt: dem Managementwiderstand .

Also ja, wenn Sie diesen Irrglauben über Agilität oder Scrum vom Management nicht ansprechen, wird die Einführung letztendlich scheitern.

Mögliche Vorschläge sind: Ausbildung, Beförderung, Unzufriedenheit mit dem Status quo erzeugen, Gefühl der Dringlichkeit schaffen, individuelle Ängste ansprechen, Zeit laufen lassen, Saboteure feuern, richtiges Verhalten loben, Menschen einbeziehen, etc, etc...

Eine großartige Möglichkeit, den „Geschäftsleuten“ in Ihrer Organisation agile und xp-Methoden vorzustellen, besteht darin, einen Workshop zu veranstalten und das xp-Spiel zu spielen .

Beachten Sie, dass jedes Team einen Trainer haben sollte, der auch als Kunde des Teams fungiert. Teilen Sie Gruppen von „Business / Sales / Developers“ in einen gemeinsamen Bereich auf, in dem mehrere Teams erstellt werden können. Viel Spaß damit, aber stellen Sie sicher, dass Sie die Schlüsselprinzipien Ihrer agilen Einführung ansprechen.

Einige Beispiele:

  • Geschäftswert
  • Geschwindigkeit
  • Einschätzung
  • Priorität
  • Akzeptanzkriterien / Annahmen

Dies ist ein Beispiel für das letzte Spiel, das ich mit einer Gruppe solcher Leute gespielt habe. Iteration 1 faltete Papier so, dass es wie ein Hut aussah, Iteration 2 baute ein Flugzeug, Iteration 3 blies Luftballons auf:

Wiederholung 1

  • Alles geht
  • Sei sanft zu ihnen

Wiederholung 2

  • Machen Sie es angesichts der leeren Blicke, die Sie von Iteration 1 bekommen, schwieriger oder einfacher
  • Anforderungen / Akzeptanzkriterien

Wiederholung 3

  • Geschichten spritzen
  • Geschichten mit hohem Wert

Hüte

  • Muss auf dem Kopf sitzen
  • 3 Falten

  • Benötigt Firmenlogo
  • Muss wie ein Hut aussehen

Flugzeuge

  • Muss wie ein Flugzeug aussehen
  • Distanz
  • Nicht-parabolische Flugbahn
  • Kunstflieger
  • Firmenlogo

Luftballons

  • Logo / Größe
  • Farben)
  • Größe
  • Gummi Ring
  • Etwas darin

Einige andere tolle Ideen finden Sie hier: http://tastycupcakes.org/

Das ganze Ziel dieser Übung ist es, Menschen außerhalb Ihrer agilen Teams dabei zu helfen, die Vorteile agiler Methoden zu erkennen.