Ideen, um Begeisterung zu wecken und die Teilnahme am Scrum-Meeting zu fördern

Mir ist aufgefallen, dass es bei diesen Pflegesitzungen durchaus üblich ist, nur ein oder zwei Personen aktiv einzubeziehen. Im Allgemeinen gibt es ein paar Leute, die gerne über Anforderungen sprechen, und ein paar, die einfach nur wissen wollen, was sie bauen sollen.

Ihr Vorgesetzter ist etwas auf der Spur, indem er sagt, dass es nicht effizient ist, wenn alle anwesend sind. Nicht jeder muss an einer Pflegesitzung teilnehmen; solange es allen ungefähr klar ist, was zu tun ist, wenn es an der Zeit ist, die eigentliche Planungssitzung durchzuführen. Es ist eine Teamleistung, also wer sich gut auskennt, kann es den anderen immer erklären.

In der Vergangenheit haben wir die Person/Personen, die an der Pflege teilnehmen, rotieren lassen. Es ist fast nie produktiv, das ganze Team hinzuzuziehen; ein oder zwei Personen werden die gleichen Fragen stellen, auf die gleichen Dinge hinweisen, die mehr Informationen benötigen usw. Und in dieser Woche wird sowieso nichts besprochenes gebaut.

Fragen Sie Ihr Team, wer gerne zum Meeting geht und über Anforderungen spricht und wer nicht. Beginnen Sie dann damit, die Personen, denen das Meeting gefällt, alleine daran teilzunehmen, und geben Sie ihnen am Ende des Meetings ein paar Minuten (oder mehr, falls nötig) Zeit, um das Gelernte mit dem Team zu teilen. Höchstwahrscheinlich erhalten Sie das gleiche Maß an Verständnis und Klarheit, zu einem Bruchteil der Kosten.

Sie verwenden nicht die Scrum-Begriffe, also nehme ich an, dass Sie Scrum nicht wirklich machen. Mein erster Rat wäre, sich ein gutes Buch oder noch besser einen Trainer zu besorgen.

Ihr Produktteam ist das, was Stakeholder genannt wird . Und in der Tat ist es nicht die Aufgabe des Entwicklungsteams , mit den Stakeholdern zu sprechen, die Anforderungen finden . Der Product Owner spricht mit den Stakeholdern.

Der Product Owner spricht dann in einem Grooming mit dem Entwicklungsteam , um die Geschichten zu verfeinern und sie entweder SMART (spezifisch, messbar, erreichbar, relevant, terminiert) oder INVEST (unabhängig, verhandelbar, wertvoll, schätzbar, klein/skalierbar, testbar) zu machen ) oder welches Akronym auch immer aktuell ist.

Sie sollten einen Scrum Master haben , den Sie nicht erwähnen. Und es gibt keinen Teamleiter in Scrum. Er scheint das zu tun, was der Product Owner tun sollte , also ist das vielleicht nur eine falsche Bezeichnung?

Also ja, Ihr Manager hat recht. Ihr Product Owner sollte an diesem Meeting teilnehmen, für das Entwicklerteam ist es nur Zeitverschwendung (wie sich an der Nichttätigkeit zeigt). Sie sollten regelmäßig ein weiteres Meeting haben (normalerweise „Grooming“ genannt), in dem der Product Owner seine Erkenntnisse aus dem ersten Meeting mit dem Team teilt und wo das Team Fragen stellen und die technischen Details besprechen sowie eine Schätzung abgeben kann.

Bei den Antworten wird ein wichtiger Punkt übersehen - das Unternehmen befindet sich in Asien. Es gibt eine kulturelle Komponente, die herausgestellt und separat betrachtet werden muss. Vielen Asiaten ist es unangenehm, in einer Gruppe eine individuelle Meinung zu äußern.

Als Praxisleiter / Scrum-Coach / agiler Evangelist müssen Sie sicherstellen, dass das Entwicklungsteam weiß, dass es eine sichere Umgebung ist, um dem „Produktteam“ Kommentare und Kommentare abzugeben. Dass sie nicht „das Gesicht verlieren“ oder das Produktteam kritisieren.

Sie müssen die kulturellen Normen in den Entwicklungsgruppen ändern / daran arbeiten, bevor die agilen Praktiken zur Selbstverständlichkeit werden. Beachten Sie, dass sich nicht nur die Entwicklungsgruppe ändern muss, sondern auch die Produktteams und die Managementteams. Wenn die Entwickler das Agile-Manifest aufgreifen, werden sie Fragen an das Produkt und das Management stellen und Feedback geben, und diese Gruppen müssen auf agile Weise antworten. Wenn die Produkt- und Managementgruppen ihre Erwartungen nicht ändern, wird Scrum nicht funktionieren.

Für mich klingt das nach einer vernünftigen Entscheidung Ihres Vorgesetzten. Das Pflegen des Product Backlogs ist formal eine Aufgabe des Product Owners, obwohl es meiner Erfahrung nach im Allgemeinen hilfreich ist, auch jemanden aus der Technik in die Diskussion einzubeziehen. Zwingen Sie den Rest des Teams nicht um des Meetings willen zu einem Meeting.

Ihr Vorgesetzter hat recht. Wenn Scrum "wie es sein sollte" nicht zur Bürokultur Ihrer Mitarbeiter passt, dann sollten Sie Scrum nicht "wie es sein sollte" machen, sondern die Art und Weise anpassen, wie es gemacht wird. Scrum soll eine agile Methode sein, das heißt, man passt den Prozess dem Kontext an, nicht umgekehrt.

Menschen sind Teil des Kontextes. Sie scheinen kulturell nicht zu diesem Treffen zu passen, so wie es aufgebaut ist. Daher muss dieses Treffen geändert werden.

Hier scheint etwas zu fehlen. Was besprechen Sie in Ihren Scrum-Meetings?

Sie sollten in den Besprechungen Projektschätzungen vornehmen, anstatt Zeitpläne zu verteilen. Die genauesten Schätzungen werden von Personen vorgenommen, die die Arbeit ausführen . Manchmal versuchen diese Meetings, Leute zusammenzubringen, die Experten für das Projekt sind, damit sie auf eine ungenaue Schätzung hinweisen oder jemandem helfen können, der nicht schätzen kann.

Manchmal hat jemand keine Ahnung, wie er etwas tun soll, dem er für diesen Sprint zugewiesen wurde, und jemand anderes im Team sollte in der Lage sein, darauf hinzuweisen.

Manche Menschen kommunizieren besser schriftlich als persönlich. Dann sollten diese Meetings wahrscheinlich online auf einem Teamkommunikationstool wie Slack stattfinden.

Manchmal sind Menschen schüchtern oder haben Angst vor Konflikten. Dann sollte der Großteil der Kommunikation mit dem Teamleiter und dem Rest des Teams in Einzelgesprächen stattfinden . Diese Einzelgespräche können äußerst effektiv sein und viele etablierte Unternehmen bestehen darauf.

Finden Sie heraus, WARUM die Leute nicht sprechen. Haben sie Angst vor Konsequenzen, wenn ein Manager ihnen nicht zustimmt? Gibt es eine Schuldzuweisungskultur und wenn ihre Äußerungen zu Problemen führen, kann dies dazu führen, dass sie bestraft (sogar gefeuert) werden? Ist es einfach eine Tendenz (die mir oft aufgefallen ist), still dazusitzen und darauf zu warten, von Autoritätspersonen gesagt zu werden, was zu tun ist, wohlgemerkt, dass dies teilweise mit den anderen Möglichkeiten zusammenhängt? Fehlt ihnen Domänenwissen oder technisches Wissen über alles andere als einen sehr engen Teil des Systems?

Finden Sie heraus, was Menschen daran hindert, Beiträge zu leisten, und unternehmen Sie dann etwas dagegen. Und das mag für manche schmerzhaft sein, besonders wenn es eine kulturelle Sache im Unternehmen ist und die Machthaber ihre Vorgehensweise ändern müssen.