Ich habe ein kleines Problem in meiner jetzigen Firma. Wir implementieren Atlassian JIRA als unser Projektmanagement-Tool sowohl für Geschäftsprobleme als auch für die Softwareentwicklung, und obwohl die Softwareentwicklungsteams begeistert sind und ziemlich gut wissen, wie Agilität funktioniert und wie Projekte verwaltet werden sollten, haben wir ein Problem damit, die Idee an Unternehmen zu verkaufen Führungskräfte - die ebenfalls in den Prozess eingebunden sind.
Die Funktionsweise in JIRA und die Art und Weise, wie wir sie eingerichtet haben, ist wie folgt:
Jedes Projekt ist ein separates Projekt, das von separaten Projektmanagern und Softwareentwicklern gepflegt wird. Intern hat es Versionsnummern für Probleme und jedes Problem hat Unteraufgaben, die verschiedene Zustände des Problems regeln, z. B. wenn das Problem eine technische Analyse, Entwicklung oder zusätzliche Tests erfordert. Sobald die Probleme mit ihren Unteraufgaben erledigt sind, wird das Problem auf „behoben“ gesetzt und sobald es live gepusht wurde, wird der Status auf „Live“ geändert und das Problem wird vollständig geschlossen.
Das funktioniert.
Aber wir haben ein Problem mit Geschäftsführern. Ihr Arbeitsablauf der alten Schule ist wie folgt:
Dieser Ansatz ist problematisch, da es schrecklich ist, Berichte, Schätzungen und jede Art von Struktur aus einem solchen Baum herauszuholen.
Ich habe versucht deutlich zu machen, dass es nicht möglich ist, auf diese Weise effektiv zu denken, und dass sie zunächst einfach das erste Problem zur Analyse schicken sollten, um zu sehen, wie viele „tatsächliche Probleme“ erstellt werden sollten und diese Probleme dann sein sollten an die entsprechenden Abteilungen zur Entwicklung gesendet und bei Bedarf mit dem ursprünglichen Problem verknüpft, um Statusaktualisierungen auf ihrer Seite zu erhalten.
Aber es bekommt nicht genug Halt, es ist ein klassisches „Wir haben die Dinge auf diese Weise gemacht und wir sind damit einverstanden“ und es gibt Probleme, das althergebrachte Denken des „endlosen Baums“ im Projektmanagement aus dem Kopf zu bekommen .
Irgendwelche Ideen, wie man die Idee des projekt- und warteschlangensprintbasierten Projektmanagements „verkaufen“ kann? Eines der Probleme scheint zu sein, dass die Benutzer Schwierigkeiten haben zu wissen, was sie mit einem Problem tun sollen, ob das Problem so groß ist, dass es ein ganz neues Projekt oder nur ein separates Problem sein sollte und wohin es als nächstes gehen soll.
Ich knirsche hier mit den Zähnen :) Alle Ideen sind willkommen!
Ich stimme dem Kommentar von @salsolatragus zu ... Ihr Problem ist, dass die Geschäftsseite Agile überhaupt nicht verwendet. Aus meiner Erfahrung ist dies ein klassischer Wachstumsschmerz, der passiert ... Also zwingen Sie die Geschäftsseite, die Art und Weise zu ändern, wie ihre Interaktionen stattfinden.
Sperren Sie sie aus. (Aber finden Sie heraus, wie Sie es besser verkaufen können ...) Machen Sie es als "Prozessänderung", die von einer Art Bedürfnis unterstützt wird. Vielleicht nur eine kleine Umstellung im Zusammenhang mit dem neuen Kalenderjahr, das ansteht.
Mit dieser leichten Reorganisation würde ich sagen, dass Sie ihnen beibringen müssen, wie Ihr Prozess aussehen sollte. Es wird ihnen egal sein. Sag es ihnen trotzdem. Hier sind die Schritte, die ich unternehmen würde:
Zäune es ein. (Dein Prozess). Basierend auf der agilen Methodik, mit der Sie arbeiten können, wie sollten Ihre Entwicklungsprozesse aussehen? Wie lang sind deine Sprints? Wie oft vervollständigst du Geschichten? Wann gehen Ihnen die neuen Anforderungen aus? Wie erleichtert Ihre Technologie die grundlegenden Aufgaben hinter dem Sammeln, Priorisieren und Ausführen von Projektaufgaben?
Finden Sie heraus, wie Sie sie eingrenzen können. Der Geschäftsseite muss mitgeteilt werden, wie sie diesen Prozess nutzen kann. Niemand hat es ihnen bisher gesagt ... niemand weiß, wie sie es verwenden sollen, also ist es wie ein weitläufiger, außer Kontrolle geratener Baum gewachsen. Es ist Ihre Aufgabe, herauszufinden, wie sie mit diesem Prozess interagieren dürfen. Wie oft müssen sie Sie wirklich mit neuen Anforderungen versorgen? Wie oft müssen sie fertige Funktionsupdates erhalten? Definieren Sie ihre Verwendung, damit sie so handeln können. [ABER ÄNDERN SIE ES NICHT, BEVOR SIE ES IHM ERKLÄRT HABEN]
Kommunizieren Sie ... Wenn Sie nicht über die individuelle Schlagkraft innerhalb der Organisation verfügen, um diese Änderung herbeizuführen, finden Sie jemanden, der dies tut und Ihre Probleme versteht. Machen Sie den Business Case in Bezug auf verlorene Zeit aufgrund von Verwirrung oder Fehlern oder so etwas sehr klar. Und dann machen Sie sich an die Einrichtung der Präsentation oder des Benutzerhandbuchs oder der Prozessanweisungen, die Ihre „neue“ Art und Weise, dies zu tun, unterstützen.
Kommunizieren Sie dann sehr klar mit den Geschäftsbeteiligten, dass Sie alle X ... (Monat? Quartal?) Neue Anforderungen von ihnen erhalten und dass sie in ihren Anforderungen so viel herumspielen können, wie sie möchten. Sammeln Sandkasten außerhalb dieser Zeit.
Konzentrieren Sie sich besonders darauf, wie dies ihre Arbeit erleichtert und wie es ihnen ermöglicht wird, Schritt für Schritt voranzukommen.
Wenn sie beim Einrichten von Miniaufgaben feststecken, weil sie so ihre neuen Funktionsanforderungen am bequemsten ausdrücken können, lassen Sie sie. Sie müssen nicht mit ihnen kämpfen, um zu versuchen, sie dazu zu zwingen, das, was sie tun, vollständig zu ändern ... Aber machen Sie deutlich, dass die Aufgaben als Vorschlag genommen werden, da sie die geschäftliche Seite sind, und dass die Entwicklungsseite behält sich das Recht vor, zusätzliche Aufgaben hinzuzufügen, die eingefügt werden müssen.
Dann sperren Sie sie tatsächlich ein ... Wenn Sie die richtige Schnittstelle für die Übergabe von Anforderungsanfragen finden, dann sperren Sie die Geschäftsanwender aus Ihrer „Aufgabenentwicklungs“-Schnittstelle aus. Das ist nicht ihre Aufgabe. Und vor allem, wenn sie nicht mit Ihnen Agile spielen, dann sind sie nicht willkommen.
Seien Sie fleißig und diszipliniert bei der tatsächlichen Lieferung. Wenn Sie sie aussperren, stellen Sie sicher, dass Sie tun, was Sie versprochen haben. Einmal im Monat oder Quartal … triffst du dich individuell mit den Business Interfaces, erzählst ihnen von den absolvierten Sprint-Erfolgen … sagst ihnen, was deine Gruppe als nächstes plant … und fragst dann, ob es noch weitere neue Anforderungen gibt. ..
Verlassen Sie dieses Meeting mit klaren Anweisungen für die nächste Zeit in Bezug auf zu erledigende Aufgaben und Prioritäten. Und dann spülen und wiederholen.
Jedes Projektmanagementsystem neigt dazu, die sonst übersehenen Kommunikationsprozesse zu formalisieren. Sie müssen hier nur eine bessere Kommunikation durchsetzen.
In meinem vorherigen Unternehmen haben wir im Team der Softwareentwicklung auf den agilen Entwicklungsprozess umgestellt. Im Laufe der Zeit wurden die folgenden Vorteile für die größere Organisation sichtbar:
Teilweise davon inspiriert, begann eines der Geschäftsteams, den agilen Entwicklungsprozess für Nicht-Software-Entwicklungsarbeiten zu verfolgen. Alles, was wir taten, war, diesen Scrum Master zu einer gelegentlichen Brown-Bag-Lunch-Session einzuladen, um Best Practices auszutauschen.
Vielleicht möchten Sie einen ähnlichen Ansatz ausprobieren. Seien Sie jedoch darauf vorbereitet, dass dies ein sehr langsamer Prozess sein wird. Wenn Sie nach schnelleren Ergebnissen suchen, versuchen Sie, einen guten Agile-Berater einzustellen.
Sven Amann