Wir haben einige Probleme in unserem Team, die ich hier beschreiben möchte:
Der Test wird fast nur noch durch einen Test im agilen Team repräsentiert. Er ist mit allen Eventualitäten betraut. Von der Planung, Strukturierung bis Abnahmetest, exploratives Testen. Der Tester bemängelt diese massive Arbeitsüberlastung, und das monatelang im Nachhinein. Aber es gibt keine Lösung, oder es wird keine Lösung angeboten. Somit ist der Sinn hinter dem Retro hier nicht gegeben.
Wir haben auch einen großen Unterschied zwischen dem Projektinhaber und dem UX-Entwicklungsteam. Ja, es stimmt, dass der PO alleine entscheiden muss, was im nächsten Sprint gemacht wird, ob technische Ausrichtung oder UX. Aber hat das UX-Team keine Rechte in einem agilen Team? Wie lässt sich dieses Thema sinnvoll lösen, derzeit driftet fast jede Retro ab.
Wo haben Sie das Rollenverständnis innerhalb einer agilen Entwicklung? Wenn Probleme in einer Retro nicht gelöst werden (zu wenig Zeit / zu wenig Geld / zu wenig Entwickler), wie geht man damit um?
Wenn ein PO das Problem nicht lösen kann. Denn ihm wird vom Management keine Lösung angeboten. Wie kann er dann die Rolle des Verstehens bei Entscheidungen entsprechend lösen?
Hier stoßen wir aus meiner Sicht an die Grenze des Machbaren. Ob agil oder Wasserfall.
Kann sich die PO aber nach einer „Du schaffst es sofort“-Mentalität durchsetzen?
Auch wenn er dem Team tatsächlich schadet, weil die eigentlichen Probleme (auch wenn nicht sein Problem) nicht gelöst werden?
Hier sind mehrere Probleme:
Kein Führungsverständnis für agile Entwicklung
Ein PO, der dem Management nicht beibringt, dass Sie mehr Personal und Kapazität benötigen
Eine zweideutige Sicht auf die PO, aber auch die agilen Abteilungen.
Hat der PO wirklich immer Recht?
Kann der PO auch entscheiden, dem Team zu schaden?
Das Retro funktioniert nicht, weil es keine Lösungen gibt. Die anderen großen Probleme können nicht gelöst werden.
Wie Sie sehen können, läuft es nicht gut. Und bisher ist jeder Versuch, diese Situation zu ändern, gescheitert.
Wir haben als Team versucht, mit der PO und dem Management zu sprechen.
Wir haben Lösungsvorschläge gemacht.
In Einzelgesprächen haben wir auch abseits der Retro die Möglichkeit, mit Menschen auf Augenhöhe zu sprechen.
Vielleicht haben Sie einen Ansatz, an den wir noch nicht gedacht haben?
Solange der PO verantwortungsbewusst genug ist, um die Schuld zu übernehmen, wenn das Produkt versagt, sollte dies kein Problem sein. Das Projektteam wird besorgt sein, wenn der PO die Entwicklungs- und Designteams für einen Produktfehler verantwortlich macht. Es wird Meinungsverschiedenheiten geben. Wenn die PO verlangt, dass etwas auf eine bestimmte Weise getan wird, besteht die einzige Möglichkeit, dies zu verhindern, darin, zu kommunizieren, was sein kann und was ist, und die Unterschiede so weit wie möglich zu erklären und die Vor-und Nachteile. Jedes agile Team benötigt Zeit, um sich zu stabilisieren und eine gute Geschwindigkeit zu erreichen.
Die Aufgabe des Testens in einem agilen Projekt fällt allen Teammitgliedern zu. Es ist sinnvoll, einen eigenen Testingenieur im Team zu haben. Aber wenn sie anfangen, mit der Arbeit überfordert zu werden, werden andere Teammitglieder, insbesondere Entwickler. Es sollte Teil des Codeüberprüfungsprozesses sein, die Änderungen tatsächlich auszuchecken, zu erstellen und zu testen. Dies mag etwas aufwändiger sein, führt aber zu einer höheren Qualität und weniger Test-/Fix-/Testschleifen mit den dedizierten QA-Leuten.
Die Aufgabe des Projektverantwortlichen besteht darin, dem Team zu sagen, was die Software tun soll, nicht wie. Besonders bei den Externalisierungen ist es nicht ungewöhnlich, dass der PO einige Vorschläge machen kann, wie bestimmte Dinge sein sollten. Aber die Teamexperten sollten das letzte Wort darüber haben, wie etwas funktioniert. Wenn der PO zum Beispiel vorschlägt, 1 TB an Daten in Excel zu speichern, sollte das Team zurückdrängen und stattdessen eine geeignete Datenbank verwenden.
Bei UX wird das etwas kompliziert. Das Look-and-Feel einer Anwendung ist ein bisschen das Was und ein bisschen das Wie. Oft geht es eher um Geschmack und erlernte Nutzungsmuster. Hier hilft es, Usability-Tests durchzuführen. Wenn Sie keinen richtigen externen Usability-Test durchführen können, holen Sie sich Leute aus dem Unternehmen, die den erwarteten Benutzern entsprechen, und zeigen Sie ihnen die Anwendung. Die Erkenntnisse aus den Usability-Tests sollten sowohl Entwickler als auch PO außer Kraft setzen.
In Bezug auf das Testen gibt es in einem Scrum-Team keine Testrolle. Menschen mögen eine Affinität zum Testen haben und sich selbst als Tester bezeichnen, aber das macht sie nicht für die Testaktivitäten verantwortlich. Das gesamte Team ist dafür verantwortlich, dass alle erforderlichen Aktivitäten durchgeführt werden, um zu einem potenziell freigabefähigen Produkt zu gelangen.
Die PO soll eine Vision bezüglich des Produkts haben, das das Team herstellt, und darauf basierend Backlog-Elemente erstellen, die Schritte in Richtung dieser Vision darstellen. Diese Vision kann UX-Aspekte enthalten, sodass es zu einem Spagat zwischen der Vision des PO und der fachlichen Meinung der UX-Designer kommen kann. Der PO hat sicherlich nicht immer Recht, aber auch die UX Designer haben nicht immer Recht.
Eine Rolle, die ich in der Frage nicht erwähnt habe, ist die des Scrum Masters (SM). Die Rolle des SM ist zweigeteilt:
Der Test wird fast nur noch durch einen Test im agilen Team repräsentiert. Er ist mit allen Eventualitäten betraut. Von der Planung, Strukturierung bis Abnahmetest, exploratives Testen. Der Tester bemängelt diese massive Arbeitsüberlastung, und das monatelang im Nachhinein. Aber es gibt keine Lösung, oder es wird keine Lösung angeboten. Somit ist der Sinn hinter dem Retro hier nicht gegeben.
Warum gibt es keine Lösung? Die Lösung liegt auf der Hand. Wenn ein Teamkollege so viel zu tun hat, dass er zum Engpass wird, helfen Sie ihm . Das bedeutet, dass das gesamte Entwicklungsteam für das Testen verantwortlich ist, wie es sowieso sein sollte.
Aber hat das UX-Team keine Rechte in einem agilen Team?
Tatsache ist, dass sie es nicht tun. Denn ein „UX-Team“ gibt es bei Scrum nicht. Es gibt den PO mit seiner Vision und es gibt das Entwicklungsteam mit den Fähigkeiten, diese Vision umzusetzen. Angenommen, das Entwicklungsteam besteht aus UX-Experten, dann kann es bei der Verfeinerung der Geschichten zu einer lebhaften Diskussion kommen, ob ein Feature eine bestimmte UX enthalten soll oder nicht, aber am Ende entscheidet der PO, wie das Produkt aussehen soll. Die Aufgabe des Entwicklungsteams ist es, bei dieser Entscheidung zu helfen , indem es die Erfahrungen einbringt und die "Kosten" (oder Entwicklungszeiten) jeder Variante erwähnt. Aber wenn der PO möchte, dass das Produkt rosa blinkt, dann ist das seine Entscheidung.
Ich werde den Rest Ihrer Fragen nicht Zeile für Zeile zitieren, aber lassen Sie mich Sie etwas fragen: Hat das Entwicklungsteam ein Mitspracherecht, wie viel in einen Sprint fließt? Denn das ist das einzige Problem, das ich bei dem sehen konnte, was Sie beschreiben.
Sprint-Planung ist ein kollaborativer Prozess. Der PO kann nichts in den Sprint einbauen, dem das Entwicklungsteam nicht zugestimmt hat. Normalerweise passen sich die Sprints basierend auf der Geschwindigkeit selbst an . Grundsätzlich schaust du dir an, was du in den letzten Sprints geschafft hast und baust deinen aktuellen Sprint darauf auf. Wenn Sie also (sehr vereinfacht) nur 4 von 10 Geschichten schaffen, werden Sie beim nächsten Sprint nur mit 4 beginnen und hoffentlich alle beenden. Und dann können das Entwicklungsteam und PO das anpassen. Aber nur zusammen . Engpässe oder zu wenig Personal sind kein Problem des Entwicklungsteams. Sie werden nach besten Kräften arbeiten. Dass das Produkt nicht so schnell fertig ist, wie der Besteller es braucht? Das sind die POsProblem. Und wenn sie nicht mehr Ressourcen vom Management erhalten können, muss das Management damit leben, dass das Produkt verspätet ist.
Scrum ist nicht einfach richtig zu machen. Es sieht einfach aus, aber es ist mehr als nur die Anleitung. Ich würde vorschlagen, dass Sie sich einen guten Scrum Coach oder einen sehr erfahrenen Scrum Master holen, um Sie durch den Übergang zu bringen. Sie benötigen auch die Genehmigung des Managements. In Taten, nicht in Worten. Wenn Sie das nicht haben (und das haben Sie angedeutet), werden Sie zwangsläufig scheitern. Scrum ist keine Graswurzelbewegung. Sie können Scrum nicht gegen Ihr Management betreiben. Weil es sich um einen kollaborativen Prozess handelt und das Management nicht mitspielt, werden keine qualitativ hochwertigen Ergebnisse erzielt. Und der Kreis schließt sich wieder, wenn das Management die schlechten Ergebnisse sieht und sagt: „Siehst du, es funktioniert nicht“, obwohl sie es tatsächlich waren, die es überhaupt erst zum Scheitern gebracht haben.
Aus irgendeinem Grund neigt das Management eher dazu, einem Berater zuzuhören, für den sie bereits viel Geld bezahlt haben, anstatt zu glauben, dass ihre eigenen Leute tatsächlich auch ein Gehirn haben könnten. Wenn das der Fall ist, holen Sie sich einen Berater. Lassen Sie das Management für dasselbe bezahlen, was Sie ihm sagen könnten, denn für ihn ist Beratung mehr wert, wenn er mehr gekostet hätte.
Transparenz ist ein Schlüsselwert von Scrum. Sie können nicht alle Probleme im Team lösen und Sie können sich auch nicht vom Management aus allen herauskaufen lassen. Vielleicht gibt es einfach kein Budget, um eine andere Person einzustellen. Ihre Aufgabe ist es nicht, für zwei zu arbeiten oder das Management wegen etwas zu nörgeln, das sie nicht ändern können. Ihre Aufgabe ist es, die Konsequenzen dieser Entscheidung transparent zu machen. Vielleicht durch die Bereitstellung von Fortschrittsdiagrammen oder Schätzungen oder einfach durch die Erklärung, dass es wirtschaftlich nicht tragbar ist, ständig einen Entwicklertest durchführen zu lassen, wenn ein Spezialist einen viel besseren Job machen könnte. Aber am Ende endet hier Ihre Verantwortung. Du hast es gemeldet . Sichtbar gemacht. Alles andere ist ihnen überlassen.
Kein Führungsverständnis für agile Entwicklung
Dies kann wahrscheinlich gelöst werden, indem den Managern einige grundlegende Informationen gegeben werden, z. B. Link zum agilen Manifest und einige Blogs zum Thema. Sie müssen auch verstehen, dass kein Prozessmanagementformat eine Wunderwaffe ist. Weder Agilität noch Wasserfall oder was Ihnen sonst noch einfällt, wird automatisch alle Probleme lösen. Darüber entscheidet letztlich die Qualität der beteiligten Personen. Und ich meine Qualität in Bezug auf rollenspezifische Fähigkeiten, aber auch Soft Skills.
Ein PO, der dem Management nicht beibringt, dass Sie mehr Personal und Kapazität benötigen
Das Management kann sich möglicherweise mehr Ressourcen leisten oder auch nicht. Und die Anzahl der Ressourcen sollte nur darüber entscheiden, wie schnell sich ein Projekt bewegen kann, nicht wie gut es funktioniert. Wenn sie also mit der Geschwindigkeit zufrieden sind, sollten keine weiteren Personen hinzugefügt werden müssen.
Eine zweideutige Sicht auf die PO, aber auch die agilen Abteilungen.
Jede Rolle in einem Scrum-Team sollte ein klares Verständnis davon haben, was ihre Verantwortlichkeiten sind und was die Verantwortlichkeiten der anderen Rollen sind. Wenn dies verstanden wird, sollten die Entscheidungen respektiert werden, die jede verantwortliche Person für ihre Rolle trifft. Hier ein kurzer Überblick:
Product Owner: Ist letztendlich für das Produkt verantwortlich. Daher kann sie bestimmen, was entwickelt wird. Aber sie tut das nur, indem sie die Produkt-Backlog-Liste pflegt.
Scrum Team / Scrum Master: Das Team ist dafür verantwortlich, die Themen mit der höchsten Priorität aus dem Product Backlog zu bearbeiten. Sie bestimmen auch die Dauer von Entwicklungsaufgaben und organisieren die Arbeit im Team. Die Teammitglieder sollten alle technisch versiert sein und jeder sollte in der Lage sein, Entwicklungsaufgaben zu erfüllen. Dazu gehören Test- und QA-bezogene Aufgaben. Viele Organisationen stellen „Tester“ als separate Rolle von „Entwickler“ (häufig schlechter bezahlt) ein, und das scheint in Ihrer Organisation der Fall zu sein. Aus der Perspektive eines agilen Teams sollte diese Unterscheidung nicht getroffen werden und ein Entwickler sollte in der Lage sein, Tests für die SW zu schreiben, die sein Team entwickelt. Anreize sollten idealerweise für das gesamte Team und nicht für einzelne Mitglieder gelten.
Das Team ist dafür verantwortlich, seine Produktivität einzuschätzen und sich auf eine Reihe von Produkt-Backlog-Elementen festzulegen, die während des nächsten Sprints entwickelt werden sollen. Das Team sollte sein Bestes geben und wenn es seine Ziele häufig verfehlt, dann ist es schlecht im Schätzen und sollte lernen, sich zu verbessern.
Ein Scrum-Team sollte nicht mehr als 5-10 Personen umfassen. Wenn es größer ist, sollte es in mehrere Teams aufgeteilt werden.
Hat der PO wirklich immer Recht?
Siehe meinen vorherigen Punkt. Er hat immer recht, wenn es darum geht, die Prioritäten für Items im Product Backlog festzulegen. Dies bestimmt, was für die Entwicklung in der nächsten Sprint-Planung ausgewählt wird. Ihm muss in Bezug auf diese Entscheidungen vertraut werden, aber er kann nicht in die Festlegung von Entwicklungszeitplänen oder technischen Implementierungsentscheidungen einbezogen werden. Er kann die Entwicklung nur beeinflussen, indem er die richtigen Backlog-Items mit Beschreibungen für die nächste Sprint-Planung bereitstellt. Er kann die Entwicklung während eines Sprints nicht beeinflussen und muss nicht einmal Teil der Sprint-Planung sein, wenn die User Stories im Backlog gut beschrieben sind.
Kann der PO auch entscheiden, dem Team zu schaden?
Das ist eine absurde Frage und die Antwort sollte offensichtlich sein.
Das Retro funktioniert nicht, weil es keine Lösungen gibt. Die anderen großen Probleme können nicht gelöst werden.
Das retrospektive Feedback sollte hauptsächlich für die interne Organisation des Scrum-Teams sein, aber wenn es Vorschläge an das Management gibt, sollten sie dokumentiert und in schriftlicher Form an die verantwortlichen Manager gesendet werden (mit CC an die oberen Manager, wenn keine Reaktion / Reaktion erfolgt).
Das Team fühlt sich sowohl von der PO als auch vom Management betrogen. Das führt zu wütenden Reaktionen.
Die Behebung der Gefühle des Teams sollte Ihre erste Priorität sein. Denken Sie daran, dass Sie dem PO unbedingt auf seine Backlog-Entscheidungen vertrauen müssen und stellen Sie andererseits sicher, dass er den Entwicklungsschätzungen und -ergebnissen des Teams vertrauen kann. Wenn Sie wegen fehlender zusätzlicher Ressourcen frustriert sind, dann sollten Sie Ihr Scrum-Team anders organisieren. Lassen Sie einige der Entwickler beim Testen von Aufgaben helfen und stellen Sie sicher, dass Sie diese Bemühungen in die Sprint-Planung einbeziehen. Das bedeutet, dass das Team in einem Sprint weniger Funktionen entwickeln kann, aber alle mit den Ergebnissen zufriedener sind.
Bitte beachten Sie, dass es sehr schwierig ist, einen toxischen Arbeitsplatz zu reparieren, und dass dies nur möglich ist, wenn alle dies wünschen. Wenn es aufgrund von toxischen Managern der Fall ist, bleibt Ihnen nichts anderes übrig, als sich einen anderen Job zu suchen.
Neben der eigentlichen Lektüre des agilen Manifests empfehle ich, sich Daves pragmatische „Agile is Dead“ -Rede anzuschauen oder seinen Blogeintrag zu lesen . Damit und mit ein wenig gesundem Menschenverstand braucht es wahrscheinlich keinen Scrum-Trainer oder -Berater.
Erik
Mornon
Erik
Oswin Noetzelmann