Heute war die Sprint 5 Demo und Sprint 5 Planning Meeting. Zum ersten Mal wurde die Planung vom Team mit Target Process durchgeführt. Der Product Owner hatte zuvor User Stories, die eigentlich keine User Stories sind, erfasst - sehr viele sogar.
Das Team hat sehr verhalten reagiert. Der Product Owner wusste teilweise nicht, was die Stories beinhalten. Nach vielen Fragen wurde das Problem eingegrenzt:
Das Team hatte zur Einführung von Target Process beim Kunden einen Workshop durchgeführt, wo erklärt wurde, wie das Tool funktioniert und wie man sich die Zusammerarbeit damit vorstellt.
Der Product Owner bekam einen Accout und jedes Teammitglied. Der Product Owner hatte seinen Account im Unternehmen des Auftraggebers "allen" zur Verfügung gestellt.
Der Effekt war, dass man das Requirement Engineering und Requirement Management mit Target Process abgedeckt hat. Der Kunde war im Glauben, dass Tool sei dafür da. Falsch! Target Process ist ein Projekt Management Tool für agile Software Entwicklung. Nicht mehr und nicht weniger.
Als das Team dem Product Owner beigebracht hatte, das dies so nicht funktioniert kam die Frage: "Wo machen wir das dann? Können Sie uns wieder einen Zugang zum Testdirector freischalten?"
Hintergrund der Frage: Das Team hatte fälschlicher Weise in der Vergangenheit dem Kunden einen speziellen Tag im Test Director eingerichtet: Optimisation. Der Kunde hatte neben Bugs auch neue Features und Change Request im Test Director erfasst. Als das Team das erkannt hatte, wurde mit Absprache des Kunden der Account stillgelegt.
Wie auch immer, die Antwort des Teams war deutlich: "Nein, natürlich nicht! Für Requirement Engineering und Requirement Management müssen Sie ein anderen Weg finden."
Das Team hat beschlossen, jede neu erfasste User Story vom Product Owner zu monitoren und zu prüfen. Wenn die Story keine User Story im Sinne von Agile ist, wird der Kunde kontaktiert und es wird umformuliert. Visionen und Requirement Engineering werden gelöscht.
Keine Kommentare:
Kommentar veröffentlichen