Wie sollte ein Entwickler in einer agilen Umgebung Teammitglieder und Manager auf dem Laufenden halten, wenn es keinen „sichtbaren“ Fortschritt gibt?

Um eine wertvolle Forschung zu haben, muss man normalerweise ihren Zweck und ihr Ziel definieren. Mit anderen Worten, der Entwickler weiß, was er tun möchte, wie er vorankommt und mit welchen Problemen er derzeit konfrontiert ist. Die Frage ist, wie dieses Wissen sinnvoll weitergegeben werden kann.

Handelt es sich bei dem Meeting nur um einen Statusbericht, geht es lediglich darum, diesen kompakt und dennoch werthaltig zu beschreiben.

ZB habe ich bereits fünf von zwölf bekannten Kompatibilitätskriterien der API überprüft. Bisher gibt es keine Hinweise auf eine mögliche Inkompatibilität, aber gestern wurde ich auf zwei neue Kriterien aufmerksam.

Wenn es in dem Meeting auch um Teamarbeit geht und Risiken und Gesamtauswirkungen der eigenen Arbeit offengelegt werden, dann ergeben sich viele neue Themen. Hat man Blocker? Braucht man Hilfe? Sollte sie jemanden über wichtige Entdeckungen informieren?

Einer der Hauptgründe, warum wir Forschung betreiben, ist die Verringerung von Unsicherheit. Während wir es reduzieren, müssen wir oft die Richtung ändern, in die wir gehen. Jedes Mal , wenn Ihre Forschung einen Fortschritt erzielt, steigt die Wahrscheinlichkeit, dass der Status eines anderen ebenfalls beeinflusst werden muss . Es vorwegzunehmen und ein Update zu geben, ist wahrscheinlich einer der Gründe, warum es solche Treffen gibt.

TL;DR

• Es kann hilfreich sein, Statusmeetings mit Stakeholdern von Statusmeetings mit Entwicklern zu trennen.
• Besprechungsintervalle sollten der Stapelgröße Ihrer Arbeitselemente entsprechen.
• Methodik und Erwartungen müssen in der gesamten Organisation explizit kommuniziert werden.

Mögliche Henne-und-Schwein-Probleme mit Ihrer aktuellen Methodik

Da viele agile Methoden tägliche oder häufige Team-Updates beinhalten ... wie sollten Entwickler sowohl technische als auch nicht-technische Stakeholder auf den neuesten Stand bringen, ohne dass es so klingt, als hätte er oder sie nichts erreicht?

Wenn Sie Scrum folgen, möchte ich darauf hinweisen, dass die täglichen Stand-Ups für das Team und nicht für die Stakeholder sind. Iterationsergebnisse werden den Stakeholdern im Allgemeinen während des Sprint Reviews am Ende jeder zeitgesteuerten Iteration zur Verfügung gestellt.

Selbst wenn Sie Scrum nicht folgen, behaupte ich, dass es sehr nach „Entwickler zur Rechenschaft ziehen“ riecht, wenn Sie Entwickler bitten, Stakeholder-zentrierte Updates zu häufig bereitzustellen, und zu CYA-Berichten durch die Entwickler führen und schließlich die Transparenz innerhalb des Projekts verringern wird.

Potentielle Lösungen

Betrachten Sie die Fabel von Huhn und Schwein . Auf der verlinkten Seite heißt es:

Bei Agile-Projekten ist der Begriff Schwein dazu gekommen, alle Entwickler, Designer und Tester zu beschreiben, die sich der eigentlichen Arbeit widmen. Der Begriff Huhn wird auf alle anderen angewendet, die intellektuelle Beiträge leisten, sich aber keiner Arbeit verpflichten.

Möglicherweise möchten Sie hier einige Optionen in Betracht ziehen, abhängig von Ihrer Unternehmenskultur und Ihrem Umfeld.

1. Erwägen Sie, häufige Meetings auf Schweine (z. B. das Entwicklungsteam) zu beschränken, anstatt Stakeholder in Meetings einzubeziehen, die verfahrenstechnisch sind.

2. Bieten Sie Stakeholdern Transparenz über ein Dashboard oder eine andere wichtige Leistungsmetrik, die keine „persönliche Verantwortung“ durch die einzelnen Entwickler beinhaltet.

3. Machen Sie den Projektmanager verantwortlich für routinemäßige Statusaktualisierungen an die Stakeholder und nicht an die Teammitglieder. Dies ermöglicht es dem PM, die Beteiligten darüber aufzuklären, was ein angemessener Fortschritt ist (oder nicht), und kann die CYA-Berichterstattung durch die Entwickler verhindern.

4. Erstellen Sie in definierten Abständen ein separates Meeting für Q&A zwischen den Stakeholdern und dem Team. In Scrum wäre dies ein Sprint Review, aber der Hauptpunkt besteht darin, Ihren Stakeholdern direkten Zugriff auf das Projekt zu geben, ohne den internen Prozess des Teams zu kapern.

5. Treffen Sie sich in Abständen, die Ihrer Chargengröße entsprechen. Zerlegen Sie die Arbeit entweder in Stücke von höchstens einem Tag oder verlängern Sie das Intervall zwischen den Besprechungen. Die Idee hier ist, die Berichterstattung von „Ich bin zu 29,36 % fertig mit foo“ zu einer Statusaktualisierung für erledigt/nicht erledigt zu verschieben. Dies ist entwicklerfreundlicher und auch aus PM-Perspektive einfacher zu verfolgen.

Erwartungen setzen

Wenn die Arbeit ein gewisses Maß an Lernen oder Erwerb von Wissen beinhaltet, wie kann ich als PM diesen Entwicklern raten, ihre Updates zu geben, ohne ihnen das Gefühl zu geben, dass sie keine Fortschritte machen, da es möglicherweise nichts zu zeigen gibt Tage/Wochen?

Projektmanagement beinhaltet oft das Setzen von Erwartungen und deren klare Kommunikation innerhalb des Projektteams und gegenüber verschiedenen Interessengruppen. Unabhängig von Ihrer Methodik oder Ihren Berichtsintervallen müssen Sie Ihre Organisation über den Prozess informieren und ihre Erwartungen angemessen festlegen.

1. Legen Sie die Erwartungen der Stakeholder fest.

   Wenn Ihr Prozess sprunghafte Ergebnisse beinhaltet, stellen Sie sicher, dass Ihre Stakeholder eine angemessene Berichterstattung erwarten. Dies kann eine regelmäßige Berichterstattung sein, die eine variable Anzahl von Ergebnissen umfasst, die während einer Timebox abgeschlossen wurden, oder eine unregelmäßige Berichterstattung, wenn etwas abgeschlossen ist und es wert ist, sie darauf aufmerksam zu machen.

2. Legen Sie die Erwartungen der Entwickler fest.

   Stellen Sie sicher, dass die Entwickler wissen, wie sie innerhalb Ihrer Methodik gemessen werden. Sie erhalten, was Sie messen, und die Leute optimieren für Metriken, die sich direkt auf sie auswirken. Wenn Sie sich entscheiden, die tägliche Berichterstattung beizubehalten, machen Sie sehr deutlich, welche Informationen Sie verfolgen möchten, wie diese Informationen verwendet werden und wie sich diese Informationen sowohl auf das Projekt als auch auf jeden einzelnen Entwickler auswirken werden.

3. Machen Sie Erwartungen deutlich.

   [T]hier ist möglicherweise für Tage/Wochen nichts zu zeigen[.]

   Stellen Sie sicher, dass diese Erwartung explizit ist , und dass Sie jeden in diesem Punkt ständig neu erziehen und beruhigen. Entwickler nach täglichen Statusaktualisierungen zu fragen, wenn die erwartete Antwort „Ich bin noch nicht fertig“ lautet, macht dies sehr schwierig, teilweise aus psychologischen Gründen und teilweise, weil Ihre Messung (tägliche Aktualisierungen) intrinsisch im Widerspruch zu der Erwartung Ihres Projekts steht Ergebnisse. Sie können diese Dissonanz bis zu einem gewissen Grad ausgleichen, indem Sie die wahren Erwartungen im Vordergrund halten.

Eines der guten Dinge einer täglichen Berichterstattung ist, dass Sie die Aufgabe in Stücke zerlegen müssen, jedes einzelne an einem Tag. Ich meine, Sie müssen wissen, woran Sie heute arbeiten. Sicher, Sie müssen die API erforschen, aber erforschen Sie gleichzeitig die gesamte API und schreiben Sie Code, nachdem Sie jede Methode gelernt haben? Oder fangen Sie klein an und fügen neue Funktionen hinzu und überarbeiten natürlich viel, während Sie die API lernen, damit Sie jeden Tag genau wissen, woran Sie arbeiten? Wenn Sie 2 Wochen „Ich forsche noch“ berichten, sagen Sie dem Team nichts und es ist besser, wenn Sie überhaupt nicht an dem Treffen teilnehmen; Wenn Sie jedoch jetzt sagen, dass ich mit diesem [Teil der API] arbeite, oder dass ich gestern den gesamten [Teil der API] neu schreiben musste, haben Sie ein Status-Update. Und wenn du 3 Tage hintereinander sagst "

Eine späte Antwort, die möglicherweise nur relevant ist, wenn Sie Projekte in User Storys oder Äquivalente aufteilen.

Der Entwickler arbeitet daran, ein Produkt auf der Grundlage der neuen APIs zu erstellen.

Lassen Sie mich zunächst mein Verständnis der Situation zusammenfassen. Es gibt ein Projekt. Ich meine, es gibt eine tatsächliche Software, die entwickelt werden muss, der Entwickler muss eine Liste von Funktionen in die Software implementieren, die Funktionen wurden möglicherweise bereits in Geschichten aufgeteilt usw. Das Problem besteht darin, dass die Implementierung dieser Funktionen erfordert, dass der Entwickler lernt a neue Technologie. Folglich ist es ziemlich unmöglich, die Arbeiten zu planen oder die Fertigstellungszeit des Projekts abzuschätzen. Darüber hinaus besteht für die Interessengruppen keine Sichtbarkeit des aktuellen Forschungsteils.

In dieser Situation würde ich die Verwendung von Spikes empfehlen . Spikes sind eine besondere Art von Geschichte, die in XP eingeführt wurde. Sie sollen Risiken und Unsicherheiten in einem Teil des Projekts reduzieren und gleichzeitig selbst kalkulierbar und planbar sein. Sie müssen zeitlich begrenzt sein. Kurz gesagt, es gibt im Allgemeinen zwei Arten von Spikes: funktionelle Spikes und technische Spikes.

Funktionelle Spikes wurden entwickelt, um funktionelle Probleme zu lösen. Zum Beispiel wissen wir nicht, was die beste Benutzerinteraktion für eine Geschichte ist, wir erstellen einen Spike, um mehrere Möglichkeiten zu prototypisieren, bevor wir die eigentliche Geschichte implementieren.

Technische Spikes sind die Art von Spikes, die Sie vielleicht brauchen. Verwenden Sie sie, wenn Sie mehr technischen Input benötigen, bevor Sie eine Geschichte, ein Feature oder ein Projekt implementieren. Dieser Input kann das Erlernen einer neuen Technologie, die Wahl zwischen mehreren Implementierungen, die Wahl zwischen dem Erstellen einer Lösung oder dem Kauf usw. sein.

Wenn ein Produkt auf einer neuen Technologie aufgebaut werden muss, von der wir überhaupt nichts wissen, würde ich empfehlen, drei Ebenen von Geschichten zu verwenden:

1. Eine Forschungsbeginnspitze (vielleicht existiert ein richtiger Name). Wir wissen nicht einmal, wie wir lernen sollen. Wir wissen nicht, ob es Dokumentationen usw. gibt, aber wir wissen, wie lange es dauern wird, zu lernen, wie man lernt. Das Ziel dieser Spitze ist es, genügend Informationen zu sammeln, um die zweite Art von Geschichte aufzubauen.
2. Technische Spikes . Jetzt, da wir wissen, wie man lernt, wissen wir, welche genauen Facetten wir lernen müssen, um die erforderlichen Funktionen zu implementieren. Erstellen Sie für jeden von ihnen eine Spitze. Sie können die Schwierigkeit/Zeit für das Erlernen jeder dieser Facetten basierend auf den Informationen abschätzen, die aus der Forschungsbeginnspitze gesammelt wurden.
3. Benutzergeschichten . Klassische User Stories können nun geschätzt werden.