Wir werden an einem spannenden neuen Projekt arbeiten, das die Grenze zwischen PM und Beratung leicht verwischt. Diese Organisation ist bestrebt, Agilität zur Unterstützung ihrer bestehenden Anwendungen einzuführen, hat jedoch nicht die geeigneten agilen Prozesse gefunden, um sie zu unterstützen.
In der ersten Phase dieses Projekts tragen wir den Hut eines Beraters, der das Senior Management zu geeigneten agilen Prozessen berät und später der eigentliche PM im Projekt ist.
Wir haben einen unterschiedlichen agilen Hintergrund, einige von uns haben etwas mit Scrum zu tun, und einige von uns haben mit XP zu tun. Wir sind uns alle einig – und Sie sind offen für Diskussionen darüber, dass der Kern der Einführung von Agilität eine Vorstellung ist, die lautet: „Jede Organisation hat ihre eigenen spezifischen Prozesse, die zum Engpass in ihrer Softwareentwicklungsgruppe werden. Wir nehmen zur Kenntnis, dass die Flasche Hals kann auch außerhalb der Software-Entwicklungsgruppe existieren, aber stattdessen im Client"
Wir entschieden, dass wir als Erstes diese Engpässe identifizieren und die entsprechenden agilen Prozesse einführen, alle über unseren Plan aufklären, ihre Zustimmung einholen und das Projekt starten sollten.
In der ersten Phase besteht unser Ansatz darin, Fokusgruppen oder Einzelgespräche zwischen Managern und Softwareentwicklern durchzuführen, um die Engpässe zu ermitteln. Hat jemand schon mal ähnliche Übungen gemacht? Hat jemand gute Techniken, um diese Engpässe zu erkennen?
Ich denke, bevor Sie einen Engpass identifizieren, sollten Sie eine "Flasche" identifizieren - was genau Sie erreichen werden. „Agil“ ist eine sehr breite und vage Definition. Anstatt Ihrem Kunden zu versprechen „seine Organisation total agil zu machen“, versuchen Sie ihm Antworten zu geben:
Ich beneide Sie um Ihren Auftrag!
Ich würde damit beginnen, herauszufinden, wie der Arbeitsfluss von der ersten Idee bis zu einem vollständig veröffentlichten und unterstützten Produkt aussieht. Verbringen Sie einige Zeit damit, sich mit jedem der Teams entlang dieser Pipeline zu treffen und zu sitzen , und identifizieren Sie, was ihre Eingaben sind (welche Materialien/Informationen sie von vorgelagerten Teams benötigen) und was ihre Ergebnisse sind (was sie an nachgelagerte Bereiche weitergeben).
Versuchen Sie herauszufinden, wie oft die Leute auf Eingaben warten und/oder wie groß ihre Warteschlange an Eingaben ist. Wenn sie dies bereits messen, besorgen Sie sich die Daten, wenn nicht, prüfen Sie, ob sie bereit wären, mit der Messung von Warteschlangen zu beginnen .
Es ist wichtig, die Leute tatsächlich zu besuchen und mit ihnen zusammenzusitzen . Es baut Vertrauen auf, und wenn Sie später Vorschläge haben, die einen Bereich betreffen, werden sie weniger wahrscheinlich widerstehen. Am wichtigsten ist, dass Sie sehen können, wie die Arbeit tatsächlich abläuft, anstatt sich darauf zu verlassen, dass die Leute Ihnen sagen, wie die Arbeit ablaufen soll , wenn alle Prozesse befolgt werden (was Sie normalerweise erhalten, wenn Sie nur E-Mails senden/mit Personen in einem Meeting sprechen).
Sie haben jetzt eine ziemlich gute Karte, wie die Arbeit durch das System fließt, und hoffentlich einige Daten darüber, wo die größten Warteschlangen sind. Ich würde damit beginnen, mir die größten Warteschlangen anzusehen und zu sehen, welche Auswirkungen diese Warteschlange auf das Team an der Warteschlange und in den Upstream- und Downstream-Bereichen hat.
Einige großartige Bücher, die sich näher mit diesen Konzepten befassen:
zfranziskus
jegor256