Ich arbeite seit mehr als 10 Jahren mit / in / for agile im Bereich Webentwicklung. Die meisten von ihnen mussten sich mit dem beliebtesten agilen Framework befassen - Scrum ( laut VersionOne ). Ich möchte Ihnen die gesammelten Beobachtungen und Schlussfolgerungen mitteilen.
Ich beginne mit einer Metapher, da ich manchmal die Einführung von Scrum in diesem Szenario sehen musste:
- Vor dem Gedränge : „Entwicklung“ als Baby - sie ist zielgerichtet, aber sie weiß nicht, wie man normal läuft, sondern möchte wirklich lernen, um zum Ziel zu gelangen.
- Einführung : Ein Lehrer kommt ( Scrum-Schulungen, Kurse, agiler Coach usw. ) und zeigt, wie man geht. Der Junge ist glücklich, er bewegt sich in Schritten! Top-Top-Top. Wir haben Sprints - wir gehen!
- Nach der Einführung : Patientenakteure sagen: „Okay, wir sind zum Ziel gefahren“, zu dem sie erhalten: „Schieben Sie das Team nicht, wir gehen!“. Die Entwicklung schreibt interessante Wege und genießt den Prozess, aber das Ziel wird vergessen.
- Scrum-no : Die Pille der Wahrheit aus dem Geschäft fördern, Scrum „mutiert“ und ermöglicht es dem Unternehmen, eine Art Produkt aus der Entwicklung zu erhalten. Und leider ist das Häkchen „Wir arbeiten an Scrum“ offiziell angekreuzt, aber das wahre Potenzial des Entwicklungsteams wurde noch nicht offengelegt, und es heißt „Scrum ist nicht real“.
Meiner Meinung nach geschieht dies aufgrund der Tatsache, dass Scrum häufig „mechanisch“ implementiert wird, ohne die Essenz des Frameworks und seiner Elemente zu erkennen. Ich möchte versuchen, die Symptome des "mechanischen Scrums" aufzudecken. zu verstehen, was die Nachteile dieses Ansatzes sind; verstehen, was mit „echtem Scrum mit Agilität“ besser sein könnte; und Wege finden, um Scrum-Symptome zu bekämpfen. Ich werde hier ein paar Artikel dazu widmen und freue mich über Ihre Kommentare und Fragen.
Lassen Sie uns zunächst definieren, was ein „mechanischer Scrum“ ist. Aus meiner Sicht ist dies der Fall, wenn alle Rollen, Ereignisse und Artefakte von Scrum formal vorhanden sind, aber Werte und Ziele vergessen werden. wenn es keine agile Kultur gibt ( d. h. ein hohes Maß an Bewusstsein und Akzeptanz für agile Manifeste und Prinzipien ). Wenn es kein Verständnis oder gar keinen Versuch gibt, herauszufinden, warum dieses oder jenes Artefakt benötigt wird oder was der Zweck der Ereignisse in Scrum ist. Es ist wie mit einem Roboter in einem Video , der weiß, wie man Saltos dreht, aber wer nennt ihn einen Turner? Bei der Implementierung von Scrum ist es wichtig, dem Team seine Ziele und Werte zu vermitteln und nicht nur die Mechanik. Agile Kultur stärkt Scrum und macht es "real". Scrum ist nützlich, um regelmäßig Werte zu liefern und umgehend Feedback zu erhalten. Bei Scrum geht es um Geschwindigkeit und Produktentwicklung. Klingt es theoretisch banal? Versuchen wir herauszufinden, wie man an Scrum arbeitet und dabei nicht die Kultur und die Werte der Wissenschaft verliert.
Wenn Sie Scrum-Elemente in ScrumGuide analysieren, sind die Rollen eine der ersten, die analysiert werden. Wir werden dasselbe tun. Weil Es stellte sich heraus, dass es viel Material gab, um die Gelegenheit zu geben, es zu realisieren. Es ist in drei Teile unterteilt ( Teil 2 , Teil 3 ). Beginnen wir die Analyse mit Product Owner.
Product Owner - Product Owner (PO):
Der Product Owner ist die Person, die für das Produkt verantwortlich ist. Er „besitzt“ den Product Backlog. Das Hauptwerkzeug von PO ist die Vision der Produktentwicklung, und die Hauptaufgabe besteht darin, den Wert des vom Team produzierten Produkts zu maximieren. Alles scheint einfach zu sein: "Wenn Sie mutig, geschickt und geschickt sind ...", aber es gibt Nuancen. Sie unterrichten uns nicht bei PO, aber sie unterrichten bei PM (Projektmanager), und oft werden PM zu PO, weil sie glauben, dass dies nur eine Namensänderung ist und Sie die alten Arbeitsansätze beibehalten können. Aber so funktioniert Agilität nicht. Wie ist es notwendig?
Interaktion zwischen Bestellung und Produkt, Backlog
Symptom : PO ist nicht für die Zusammensetzung des Rückstands verantwortlich, sondern arbeitet nur an Geschichten, die von anderen Teilnehmern des Prozesses erhalten wurden. Oder PO ist nicht für die Priorisierung von Backlog-Elementen verantwortlich. Seine Arbeit besteht darin, den Rückstand auf den vom Team akzeptierten Standard zu bringen, und er bestimmt nicht den Inhalt und die Prioritäten dessen, was das Team tun wird.
Was ist schlecht : Wenn eine Bestellung nicht den Mut oder die Fähigkeit hat, ein Produkt zu erstellen ( Rückstand bilden, Prioritäten setzen, Experimente durchführen usw. ), ist dies keine Bestellung, sondern eine andere Art von Aktivität. Und ohne PO Scrum, nicht Scrum. Ohne Bildung eines Backlogs kann PO nicht für das Produkt verantwortlich sein. Wenn PO nicht für den Rückstand verantwortlich ist, erfordert die Annahme von Produktentscheidungen zusätzliche Kommunikation - dies ist eine zusätzliche Zeit, die sich negativ auf die Geschwindigkeit des Teams auswirkt.
Behandlung : Sie müssen PO das alleinige Recht einräumen, Produktentscheidungen zu treffen, und die Verantwortung für die Zusammensetzung des Rückstands übernehmen. Wenn ein Nichtentscheider eine etablierte Ordnung ist, ist es schwierig, die Situation über Nacht zu ändern. Wenn PO ein Proxy ist, dann
- Oder wir entfernen es aus der Gleichung und machen die Bestellung wirklich zu der Person, die für die Zusammensetzung und Priorisierung des Rückstands verantwortlich ist. Sowohl das Entwicklungsteam als auch das spezielle Product Discovery Team können POs bei der Bearbeitung des Auftragsbestands unterstützen. Die Verantwortung für die Zusammensetzung und Qualität des Auftragsbestands sollte jedoch nur bei einer Person liegen - PO.
- Oder wir lernen / erlauben / zwingen uns allmählich, Verantwortung zu übernehmen und Entscheidungen (die Zusammensetzung der Rückstandselemente, die Priorität der Elemente usw. ) der aktuellen Bestellung zu treffen. Iterationen sind wichtig: Erfolg festigen, Feedback erhalten.
Symptom : PO hat keine Vision für die Produktentwicklung, es gibt keine globale Strategie, es gibt kein Ziel, wohin das Produkt gebracht werden soll und warum.
Was schlecht ist : Die Hauptstärke von PO ist die Vision des Produkts, zu verstehen, warum und für wen es erstellt wurde. Mit dieser Vision kann er Menschen in seiner Umgebung motivieren und „infizieren“. Wenn es keine Vision gibt, ist es unwahrscheinlich, dass sich das Produkt als notwendig und gut herausstellt. Das Team wird mit dem Ergebnis nicht „belastet“.
Wie zu behandeln : PO Es ist wichtig, zuerst eine Vision des Produkts zu formulieren. Er muss in der Lage sein, im Pitch- Format des Aufzugs zu sagen, was für eine coole Sache er tut, für was und für wen. Einer der agilen Werte ist Transparenz. Durch die Visualisierung verschiedener Produktentwicklungsartefakte arbeiten wir an Transparenz. PO kann seine Vision artikulieren und vor dem Team veröffentlichen. Es ist besser, wenn die Arbeit an der Formulierung des Höhenunterschieds und der Sicht des Aufzugs mit einer gewissen Häufigkeit durchgeführt wird - wie bei anderen Scrum-Ereignissen ( geplante neue Iteration - erledigt - gesammeltes Feedback ).
Symptom : PO arbeitet die Backlog-Elemente nicht aus, bringt sie nicht zu den vom Team getroffenen Vereinbarungen, aktualisiert die Backlog-Elemente nicht, bereinigt sie nicht und führt kein Backlog für die Pflege durch .
Was ist schlecht : Wenn der PO dem Rückstand derzeit nicht regelmäßig genug Aufmerksamkeit schenkt, muss er dies noch tun ( Sprints müssen gesammelt werden ), aber es wird stressiger und kostspieliger ( zum Beispiel: kollektives Aufräumen des Rückstands bei der Sprintplanung ). Der Kommunikationsaufwand wird von der für die Entwicklung vorgesehenen Zeit abgezogen. PO wird anfangen, das Vertrauen des Teams zu verlieren: Es investiert nicht in den Rückstand - das Team wird nicht in das Inkrement investieren. Ein schlechter / irrelevanter Rückstand verringert die Transparenz für alle interessierten Parteien. Und Scrum ohne Transparenz ist kein Scrum.
Wie zu behandeln : Vor der Bestellung müssen Sie die Wichtigkeit der Arbeit am Rückstand vermitteln - Artikel, Bücher, Schulungen usw. Wir müssen Regeln / Vorschriften für die Durchführung von Product Backlog Refinement (PBR) entwickeln, damit diese Meetings nützlich und effektiv sind und eine Mini-Retrospektive nach PBR durchführen. In wenigen Iterationen können Sie dieses Ereignis qualitativ verbessern. Das Team muss den Mechanismus für die Durchführung von Züchterrechten verbessern und maximale Synergien zwischen der PO und dem Entwicklungsteam erzielen. Der Rückstand muss regelmäßig gereinigt werden. Wenn Sie die neuesten Informationen erhalten und dem Backlog neue Storys hinzufügen möchten, müssen Sie daran denken, Storys zu bereinigen, die an Relevanz verloren haben. Der Rückstand sollte Elemente enthalten, die für das Team klar sind und ( im Rahmen der Vereinbarungen eines bestimmten Teams ) für 2-3 Sprints ausgearbeitet wurden. Ein tiefer arbeitender Rückstand kann an Relevanz verlieren. Im Allgemeinen sollte der Rückstand die Roadmap mindestens ein Jahr lang enthalten, damit alle Interessenten das Gefühl haben, dass das Produkt eine Zukunft hat. Wenn der Rückstand in ungefähren Schritten unterbrochen wird, kann das Team im Voraus über Sprintziele nachdenken.
Symptom : PO funktioniert mit mehreren unabhängigen Produkten oder mit mehreren Teams. Optional - neben der Hauptbestellung spielt sie auch eine andere Rolle im Scrum-Prozess (entweder Entwickler oder SM).
Was schlecht ist : Ein PO zu sein ist keine leichte Aufgabe und erfordert hohe Renditen. Wenn die Rolle der PO mit anderen Aktivitäten kombiniert wird, wird dies mit hoher Wahrscheinlichkeit die Qualität des Ergebnisses stark beeinträchtigen. Erfahrene und ausgereifte Bestellungen können gleichzeitig mehrere Produkte ausführen und mit mehreren Teams zusammenarbeiten, wenn diese Produkte „verwandt“ sind oder Teil eines großen Produkts sind, dessen Funktionalität eng ist. Höchstwahrscheinlich können nur sehr, sehr einzigartige Personen gleichzeitig beispielsweise einen grafischen Editor für mobile Geräte und einen Armee-Flugsimulator erstellen. Um effektiv zu sein, müssen Sie sich auf ein Ziel konzentrieren, bevor Sie mehrere jonglieren.
Wie zu behandeln : PO sollte seine Produkte kritisch betrachten: Wie gut entwickelt und formuliert Vision? Wie verstehen und akzeptieren Teams diese Vision? Wie gut ist der Rückstand entwickelt? Ist es für alle Beteiligten transparent? Gibt es eine Roadmap für das Produkt, ist es allen klar? Versteht das Team, was die nächsten 2-3 Sprints bewirken werden? Wie bekannt sind der Benutzer und der Markt? Wie ist die Qualität der Interaktion mit dem Entwicklungsteam? Wenn in einigen dieser Probleme Raum für Qualitätsverbesserungen besteht, sollten Sie sich ein Produkt überlassen und sich darauf konzentrieren.
PO und Teaminteraktion
Symptom : Die PO-Direktive steuert das Team und arbeitet tatsächlich am klassischen PM-Schema. PO trifft alle Entscheidungen, auch die kleinsten, das Team läuft zu jedem Thema zu ihm.
Was ist schlecht : Wenn PO innerhalb des Teams Mikromanagement betreibt, sich aktiv an der Entwicklung beteiligt, demotiviert es einerseits das Team und verhindert dessen Entwicklung ( es gibt keine Selbstorganisation, da die Verantwortung für lokale Entscheidungen bei PO bleibt ), andererseits ist es schlecht für das Produkt, weil die Bemühungen von PO innerhalb des Prozesses gerichtet sind und das Produkt ohne seine Aufmerksamkeit gelassen werden kann.
Wie zu behandeln : PO muss PM in sich selbst töten, nicht-richtlinienbezogene Managementansätze ausprobieren und aufhören, Menschen als Ressource wahrzunehmen. Wenn zwischen der PO und dem Entwicklungsteam ein Richtlinienverwaltungsschema erstellt wird, lohnt es sich, einen externen oder internen Moderator hinzuzuziehen, der die Interaktion anpassen kann. Die Verantwortungsgrenzen zwischen der PO und dem Entwicklungsteam müssen klar definiert werden - das ist Transparenz. Es muss eine vertrauensvolle Beziehung zwischen der PO und dem Team bestehen: Das Team vertraut größtenteils der PO und ihren Produktlösungen, und die PO vertraut dem Team und den Entscheidungen, die das Team zur Implementierung der Backlog-Elemente trifft. Jeder hat das Verständnis, dass Arbeit für einen einzigen Zweck geleistet wird. Eines der möglichen Tools für PO kann das Produktteam sein, zu dem auch Analysten gehören. Wenn Hypothesen auf Zahlen und Daten basieren, sind sie glaubwürdiger. Die Hauptsache für PO ist, nicht zu vergessen, diese Daten mit dem Entwicklungsteam zu teilen. Wenn das Team nicht unabhängig ist, muss die PO lernen, wie man delegiert. Dann wird das Team aufgrund von Verantwortung gezwungen sein, Entscheidungen zu treffen, und nach und nach wird es ein Scrum-Team.
Symptom : PO und das Entwicklungsteam streiten sich regelmäßig, es gibt eine ständige Konfrontation, es gibt kein gegenseitiges Verständnis.
Was schlecht ist : PO und Besatzung segeln im selben Boot. Wenn keine effektive Kommunikation zwischen ihnen hergestellt wird, ist es unwahrscheinlich, dass ein solches Boot weit segeln kann. Es wird viel Energie für die Herstellung der Interaktion und nicht für die Produktentwicklung aufgewendet. Das Ziel der PO und des Teams ist dasselbe, was bedeutet, dass es keine regelmäßigen Konflikte geben sollte.
Behandlung : Wir brauchen einen erfahrenen Moderator, der das Wesentliche des Konflikts identifizieren, beseitigen und eine Arbeitsbeziehung aufbauen kann. Wenn nicht alle Bemühungen zu gegenseitigem Verständnis führen, lohnt es sich vielleicht, die Tandems zu ändern.
Symptom : PO kommuniziert fast nicht mit dem Team. Beispielsweise ist es nur im Rahmen von obligatorischen Besprechungen (Planung, Sprint-Überprüfung) verfügbar.
Was schlecht ist : Das Team erstellt ein neues komplexes Produkt ( Scrum ist ein Framework für die Entwicklung, Bereitstellung und Aufrechterhaltung komplexer Produkte. ) Daher funktioniert es unter Bedingungen großer Unsicherheit. Um einen maximalen Wert zu erzielen, benötigen sie Informationen, über die in den meisten Fällen nur PO verfügt ( es ist seine Aufgabe ). Wenn keine Informationen vorliegen, können falsche Annahmen und Entscheidungen getroffen werden, wodurch wertvolle Zeit für deren Korrektur verloren geht.
So entscheiden Sie : PO sollte für das Team verfügbar sein, aber das Team sollte es nicht missbrauchen, da sonst die PO-Zeit nur für Ad-hoc-Fragen verwendet wird. Es sollte ein für alle angenehmes Interaktionsformat ausgearbeitet werden, bei dem das Team rechtzeitig von PO die notwendigen Informationen und Entscheidungen erhält, die das Team wirklich nicht alleine treffen kann. Sie können PO-Retrospektiven mit einer gewissen Regelmäßigkeit aufrufen und dort das Thema Häufigkeit, Tools und Kommunikationsformat diskutieren.
Symptom : PO fördert oder fördert keine Team- Feedback- Kultur. Oder PO bietet einseitiges Feedback, indem Lob oder Kritik herausgefiltert werden.
Warum es schlecht ist : Wenn die PO dem Team kein regelmäßiges ehrliches Feedback gibt, demotiviert dies das Team. Keine Synchronisation von Erwartungen und Ergebnissen. Das Team fühlt sich nicht mitschuldig, sie sind nicht die Schöpfer des Produkts, sie erfüllen einfach ihre Funktion. „Das Team liefert regelmäßig Inkremente. Das Team erhält regelmäßig ehrliches Feedback zu seiner Arbeit “- es scheint ein fairer Deal zu sein.
Vorgehensweise: PO sollte dem Team natürlich nicht alle Informationen in Rechnung stellen, mit denen er selbst arbeitet, sondern alle Informationen, die er von Benutzern und Analysten erhält. Er muss Informationen sammeln und herausgeben, die für das Team bereits wichtig und verständlich sind. Es ist gut, verschiedene Formate für Feedback zu entwickeln, und zwar nicht nur auf der Grundlage trockener Zahlen ( z. B. Live-Tests, Interviews usw. ). Das Team selbst sollte PO an die Notwendigkeit von Feedback erinnern: Fragen stellen, einen regelmäßigen Prozess für den Erhalt von Feedback aufbauen. Wenn Sie PO zum „Eigentümer“ des Sprint-Überprüfungsereignisses machen und es mit der Tatsache rätseln, dass das Team Feedback benötigt, erinnert es PO zumindest an die Arbeit an dem Feedback und kann zu einer kreativeren Herangehensweise an die Organisation führen.
Interaktion zwischen PO und Marktnutzern
Symptom : PO kennt "seinen" Benutzer nicht; Das Produkt sieht eine Reihe von Funktionen. PO ignoriert Benutzeranforderungen und Informationen von vorhandenen Benutzern. Kommuniziert nicht mit Live-Benutzern.
Warum es schlecht ist : Zunächst wird das Produkt für den Benutzer erstellt, der ( möglicherweise weiß er dies noch nicht ) das vom Produkt befriedigte Bedürfnis hat. Und wenn Sie den Benutzer nicht kennen und verstehen, ist es unmöglich, "die Verantwortung für das Erreichen des Maximalwerts des Produkts zu tragen", wie im Scrum-Handbuch gefordert.
Behandlung : Es gibt viele verschiedene Tools für die Durchführung qualitativer Forschung, z. B. eingehende Interviews, ein Porträt eines Benutzers, eine Customer Journey Map , Tools zum Sammeln qualitativer (vs quantitativer) Analysen usw. usw. Sie müssen verschiedene Tools ausprobieren und für Ihr Produkt nützlich / funktionsfähig lassen. Die meisten dieser Tools am Ausgang haben eine Visualisierung des Ergebnisses. Es lohnt sich, sie vor das Team zu stellen, um die Transparenz zu erhöhen. Diese Artefakte sollten von Zeit zu Zeit aktualisiert werden. Sie können ein Produktentdeckungsteam organisieren , das Sie bei der Durchführung von Qualitätsrecherchen unterstützt. Wenn es PO gelingt, eine Interaktion mit dem Benutzer herzustellen, kann er diesen Kontakt beispielsweise für die Sprintüberprüfung verwenden: Geben Sie dem Benutzer ein neues Inkrement, und das Team prüft, wie der Benutzer mit der Aufgabe umgeht, und hilft bei der Lösung, die er im Inkrement festgelegt hat.
Symptom : PO untersucht nicht den Markt / die Wettbewerber.
Was schlecht ist : Das Produkt lebt wie in einem Vakuum und ist von der Realität getrennt. Sie müssen ein Visionär sein, um unter solchen Bedingungen ein wertvolles Produkt zu schaffen.
Wie zu behandeln : Es gibt eine Reihe von Praktiken für Produktbesitzer, wie man Märkte studiert und schafft. Es lohnt sich, verschiedene davon auszuprobieren und nützliche zu hinterlassen. In dieser Aktivität können POs von Analysten oder einem Team unterstützt werden. Es ist nützlich, von Zeit zu Zeit nach „ blauen Ozeanen “ zu suchen. Und natürlich sollten Sie sich von Schulungen, Food-Meetings und Konferenzen inspirieren lassen.
Fazit
Eine Analyse der verbleibenden Rollen wird in den folgenden Teilen angezeigt. Lassen Sie uns nun sehen, wie diese Informationen für Sie nützlich sein können. Wir haben einige der möglichen Symptome untersucht und festgestellt, dass beim Scrum etwas schief geht, sowie Optionen zur Änderung der Situation. Wenn Sie möchten, eine Checkliste am Ende:
- Beim Lesen fast aller Elemente haben Sie sich selbst ( Ihr Team / Ihre Organisation ) erkannt, d. H. Sie haben ein Gedränge mit nicht-kanonischem Verständnis. Dann lohnt es sich, Fragen zu stellen: Brauchen Sie überhaupt Scrum? Warum brauchst du Scrum? Welche Aufgaben stellst du ihm? Ist die Unternehmenskultur bereit für agile Werte und Prinzipien? Wenn Sie Antworten haben und verstehen, warum Scrum benötigt wird, und Sie wirklich darauf wetten, fahren Sie mit der zweiten Option fort. Wenn nicht, dann hör auf, Selbsttäuschung zu üben.
- Beim Lesen einiger Punkte dachten Sie, dass es nicht um Sie ging. Einige Punkte haben Sie zur Vernunft veranlasst und Sie haben sich an Ihre Situation erinnert. Wenn ja, wählen Sie die Elemente aus, die für Ihre Situation relevant sein können. Drucken Sie sie in Form von Karten. Besprechen Sie die Symptome mit dem Team: Sind sie fair zu Ihnen? Besprechen Sie die Risiken, stimmen Sie ihnen zu oder sehen Sie möglicherweise gefährlichere Konsequenzen aus den Symptomen. Nehmen Sie dann die Karte, die das Team am meisten beunruhigt, das derzeit gefährlichste Symptom. Betrachten Sie die vorgeschlagene Lösung, ist es für Sie richtig? Überlegen Sie sich gemeinsam, wie Sie die Situation verbessern und das Symptom lindern können. Und handeln! Nachdem Sie sich mit einem Symptom befasst haben, fahren Sie mit dem nächsten fort und kehren Sie regelmäßig zur allgemeinen Überprüfung zurück, um sicherzustellen, dass die bereits erzielten Ergebnisse nicht nachgelassen haben.
- Wenn Sie in diesen Situationen alles gelesen und Ihre Realität nicht erkannt haben, haben wir alles richtig gemacht. Gibt es wirklich solche Organisationen? Sie sind großartige Leute, teilen Sie in den Kommentaren mit, wie Sie dies erreicht haben!
PS Ich hoffe, dass der Artikel ein funktionierendes Werkzeug für Scrum-Teams zur Selbstverbesserung darstellt.
PPS Vielen Dank für die Illustration. Sai Kin
UPD Teil 2 und Teil 3 .