Einführung der agilen Entwicklung nach dem traditionellen Projektstart

Vor ungefähr anderthalb Jahren betrat ich einen Arbeitsplatz, der behauptete, agile Entwicklung zu betreiben. Was ich gelernt habe war, dass dieser Ort mehrere agile Praktiken übernommen hat (wie tägliche Stand-ups, Sprint-Planungen und Sprint-Reviews), aber keines der Prinzipien (gerade rechtzeitig / gerade gut genug Mentalität, frühzeitige Aufdeckung von Fehlern, reichhaltige Kommunikation).

Ich wurde nun beauftragt, das Team agiler zu machen, und mir wurde versichert, dass ich das vollständige Buy-In von den Entwicklern und dem Business-Team erhalten habe. Als Pilotprogramm haben sie mir ein Projekt zur Verfügung gestellt, das gerade 15 Monate lang Anforderungen gesammelt hat, ein 110-seitiges Analyse- und Designdokument (als "in Stein gemeißelt" zu betrachten) und auf das ich bis zum Ende keinen Zugriff habe Benutzer (nur an das Komitee, das sich aus den Managern der Benutzer zusammensetzt, die das Produkt nicht tatsächlich verwenden).

Ich begann klein und gab ihnen eine Liste der erwarteten Ergebnisse für die ersten 5 Sprints (wobei die zukünftigen Sprints undefiniert blieben), eine Liste der Ziele für den ersten Sprint und sezierte das A & D-Dokument, um genügend User Stories zu erhalten, um die Ziele des ersten Sprints zu erreichen .

Seitdem haben sie gefragt, warum wir nicht alle Anforderungen für alle Sprints haben, warum ich nicht angefangen habe, an Sachen für den dritten Sprint zu arbeiten (was sie für wichtiger halten, aber auf den Ergebnissen des ersten Sprints basieren 2 Sprints) und fordern noch mehr Dokumentation, die mein gesamtes IT-Team als arbeitsintensiv oder nicht mit uns verbunden ansieht (z. B. das Schreiben des Benutzerhandbuchs im Voraus, das Dokumentieren aller Datenfelder von allen Sprints im Voraus und vieles mehr "vorab" arbeiten).

Für mich als neuen Projektmanager war das ziemlich schwierig, aber es gibt Verbesserungen, die ich effektiv implementiert habe, wie z. B. Scrumban für das Story-Management, Paarprogrammierung und die Durchführung von Kundenakzeptanztests durch das Unternehmen im Vorfeld (als Teil der Anforderungsdokumentation). .

Meine Fragen sind also:

1. Was kann ich tun, um Veränderungen in einem widerstandsfähigen Unternehmen effektiver einzuführen?
2. Gibt es andere Praktiken, die ich auf der IT-Seite einführen kann, um dem Unternehmen die Vorteile von Agilität zu zeigen?
3. Die Last der Dokumentation erwürgt uns - das Unternehmen sieht sie immer noch als Risikomanagementstrategie und nicht als Risiko. Was können wir tun, um ihre Bedenken und Anforderungen in Bezug auf die Dokumentation zu zerstreuen (insbesondere die Menge der Dokumentation und ihren Bedarf an all dem im Voraus)?
4. Wir befinden uns in einem von unserem Geschäft getrennten Gebäude, ungefähr 3 Blocks entfernt, und sie weigern sich, ihre Mitarbeiter an dem Projekt zu beteiligen, da diese Person "nicht in der Lage ist, an ihren anderen Projekten zu arbeiten, während sie bei uns ist Gebäude." Sie erwarten von uns, dass wir immer dorthin gehen und unsere Fragen bündeln, damit wir sie alle auf einmal stellen können und die Zeit dieser Person nicht mit "ständigen Unterbrechungen" verschwenden. Was können wir tun, um eine reichhaltigere Kommunikation von ihnen zu erhalten?

Jeder zusätzliche Rat wäre auch dankbar.

Vielen Dank!

Mir wurde versichert, dass ich ein vollständiges Buy-In von den Entwicklern und dem Business-Team habe. [...] Ich habe keinen Zugriff auf die Endbenutzer [...]

Eine Sache, die ganz klar ist, ist der Unterschied zwischen der mündlichen Zusicherung, dass Sie ein Buy-In haben, einerseits und dem tatsächlichen Engagement desjenigen, der Ihre Arbeit sponsert.

Mein bester Rat an Sie ist, das Label "Agile" ganz beiseite zu legen. Verbieten Sie das Wort so weit wie möglich aus dem Gespräch. Konzentrieren Sie sich stattdessen auf folgende Dinge:

• Welche Ergebnisse sollen Sie liefern (Sie speziell, nicht das Team) ?
• Was sind die Erfolgskriterien für Ihre Mission (wieder Ihre und nicht die des Teams) ?
• Was bedeutet , dass Sie zur Verfügung haben (einschließlich Personen, Zugang zu Personen, Zeit, Informationen, Schulungsbudget, was auch immer)?

"Das Team agiler machen" ist kein umsetzbares Ziel. Es ist nicht spezifisch genug, es ist nicht messbar, es hat keine Endbedingung. Was Sie benötigen, ist etwas Bestimmtes: Ein Ziel, ausgedrückt als X Prozent weniger Fehler oder Y Prozent Ihrer tatsächlich eingehaltenen Feature-Liefertermine bis zum Z-Datum.

Um diese Ziele zu erreichen, müssen Sie möglicherweise Änderungen vornehmen. Nun gelten einige Faustregeln. Jede Verbesserung ist eine Veränderung, aber nicht jede Veränderung ist eine Verbesserung. Es wird oft gesagt, dass Menschen sich Veränderungen widersetzen, aber tatsächlich widersetzen sich Menschen Veränderungen und wissen nicht, ob die Veränderung eine Verbesserung sein wird.

Konzentrieren Sie sich auf Praktiken, von denen Sie glauben, dass sie leicht zu gewinnen sind und tief hängende Früchte tragen. Konzentrieren Sie sich auf die Praktiken, die einen Rahmen nicht nur für die Umsetzung von Veränderungen schaffen, sondern auch für die Bewertung der Auswirkungen von Veränderungen, und versichern Sie den Menschen, dass sie eher zu Verbesserungen als zu Regression führen. "Informationsstrahler" sind gut, ebenso wie Rückblicke.

Einige dieser Änderungen können sowohl notwendig als auch als bedrohlich empfunden werden, z. B. ein besserer Zugang zu Personen mit Schlüsselinformationen. Gehen Sie hier keine Kompromisse ein: "Buy-in" bedeutet einen Verhandlungsprozess, bei dem Sie tatsächlich die Chance haben, das zu liefern, worum Sie gebeten werden, und nicht wie ein Lamm zum politischen Schlachten geführt zu werden.

Versuchen Sie, die Dinge so einzurichten, dass es schwierig ist, die Schuld auf Sie zu verlagern, wenn die Dinge nicht richtig laufen (und wahrscheinlich wird viel schief gehen). Seien Sie sich bewusst, dass dies passieren kann, und seien Sie darauf vorbereitet: Kennen Sie Ihre Exit-Strategie.

Um eine neue Sache reibungslos einzuführen, müssen Sie sicherstellen, dass die Leute sie nicht als Bedrohung und dauerhaft ansehen .

Viele von uns sind natürlich dazu verdrahtet, neue Dinge zu vermeiden. Es ist biologisch. Menschen, die normalerweise nach Neuheiten suchen, werden Ihnen niemals Probleme bereiten. Sie müssen sicherstellen, dass ängstlichere Menschen Ihren Vorschlag nicht als Bedrohung für ihren aktuellen Komfort ansehen.

Der ideale Weg für ein Team, eine Praxis oder Idee zu übernehmen, besteht darin, sicherzustellen, dass die Idee von ihnen stammt und nicht von externen Personen wie dem Management oder, schlimmer noch, einigen zufälligen Beratern. Erstellen Sie dazu Brainstorming-Meetings mit dem gesamten Team mit nur einem Thema. Das Thema sollte das Problem sein. In der Besprechung müssen Sie die Ideen sorgfältig einbringen und Argumente und Fakten vorlegen.

Wir treffen keine Entscheidungen über dauerhafte Dinge. Wir sind bereits besorgt über die Auswirkungen einer möglichen Änderung. Dieses Verhalten ist in Tierhandlungen bekannt. Der Kauf eines Hundes ist eine sehr große Entscheidung und wird wahrscheinlich Ihr Leben radikal verändern. Wenn Sie im Geschäft sind, schlägt der Verkäufer Ihnen häufig vor, es mit nach Hause zu nehmen und zurückzugeben, wenn Sie es sich anders überlegen. Wie zu erwarten ist, gibt es nur sehr wenige Renditen. Der Vorschlag hat nur ein Ziel: Verringerung der Angst, die Menschen daran hindert, Entscheidungen zu treffen. Schlagen Sie Ihrem Team vor, dass Sie es für eine festgelegte Zeitspanne versuchen, nachdem Sie die Wirkung bewertet haben.

In Bezug auf Ihre zweite Frage empfehle ich Ihnen dringend, jeweils eine Sache mitzubringen.

Ihr Dokumentationsproblem verdient einen eigenen Beitrag hier auf P.SE und ich sehe kein Problem damit, dass Sie sich in zwei verschiedenen Gebäuden befinden, wenn beide bereit sind, sich regelmäßig zu treffen. Es gibt Situationen, in denen sich eine Seite überhaupt nicht treffen will;)

Agile ist nicht jedermanns Sache. Es hört sich so an, als würde Ihr Unternehmen nur gerne Agile sagen, weil es das heißeste Schlagwort ist. Zuallererst wäre es wahrscheinlich eine gute Idee gewesen, auf ein brandneues Projekt oder kleinere Wartungsprojekte zu drängen, um ihren Prozess mehr wie echte agile Methoden zu gestalten. Der Versuch, eine Methodik mithilfe eines bereits laufenden Projekts neu zu gestalten, ist wie der Versuch, einen Reifen mitten auf einer achtspurigen Autobahn zu wechseln. Sie benötigen eine Möglichkeit, um zu zeigen, dass Ihr Unternehmen agil funktionieren kann, aber Sie benötigen eine Umgebung, in der es eine Chance hat zu arbeiten, aber basierend auf dem, was Sie gesagt haben, ist es unwahrscheinlich, dass agil mit der etablierten Kultur gut funktioniert.

Je nachdem, was sie für die Dokumentation benötigen, können Sie ihnen möglicherweise zeigen, dass dies automatisch von einem von Ihnen verwendeten Tool generiert wird oder redundant ist und Dokument B das Informationsdokument enthält, das angezeigt werden soll. Sie müssen auch Ihre Dokumentationspläne anpassen, sie wissen lassen, warum sich Ihre Schätzungen ändern, und sie bitten, die Menge der angeforderten Dokumentation zu reduzieren oder Ressourcen wie ein Geschäftsanalyst für die Erstellung der Dokumentation bereitzustellen.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Das ist dein Problem. Sie verstehen es nicht. Jemand kann Sie nicht bitten, agiler zu sein und nicht bereit zu sein, mitzufahren. Sie haben die falschen Erwartungen. Die Dinge sind vorne kaputt, bevor Sie überhaupt anfangen. Korrigieren Sie die Erwartungen, sonst scheitern Sie. Es ist so, als würde ich Sie bitten, 150 MPH zu fahren, und ich gebe Ihnen eine Chevette, mit der Sie das tun können.

Bauen Sie die Zeit / Ressource / Kosten der gewünschten Dokumentation ein und lassen Sie sie sehen, wie weit der Zeitplan verschoben wird.

Dies kann ihnen helfen, zu zeigen, wie viel Arbeit sie in das Projektteam stecken und wie dies reduziert werden könnte, wenn sie das nicht tun würden.