Im ersten Teil haben wir uns mit alarmierenden Symptomen und möglichen Möglichkeiten befasst, Product Owner in einem „mechanischen“ Scrum zu „behandeln“. Wir setzen die Rollenanalyse fort und der nächste in der Reihe ist das Team.
Trotzdem kennen sie das Mantra, dass das Team selbstorganisiert und funktionsübergreifend sein muss. Es sieht nach dem einfachsten Teil von Scrum aus: Wir nehmen Leute mit den richtigen Kompetenzen, sagen ihnen: „Sie sind ein Team“ und fliegen! In Wirklichkeit ist alles etwas komplizierter.
Selbstorganisation
Symptom : Es gibt eine explizite Hierarchie (Richtlinienübermittlung) außerhalb oder noch schlimmer innerhalb eines Teams. Das heißt, Tatsächlich kann ein Produktentwickler eine Aufgabe haben, die nicht direkt mit den Aktivitäten des Teams zusammenhängt. Oder innerhalb des Teams können die Mitarbeiter nicht frei einen Job wählen, um das Sprintziel zu erreichen, sondern Aufgaben vom „Leiter“ erhalten.
Was ist schlecht :
Beliebige Grenzen - limit @ CEP
Wenn eine Person durch Stellenbeschreibung, Hierarchie der Unterwerfung usw. gequetscht wird, verhindert dies, dass sie aufgedeckt wird. Die Stärke des Scrum-Teams besteht darin, Möglichkeiten für Menschen zu eröffnen. Es gibt eine Aufgabe, Mut zu fassen und für deren Umsetzung verantwortlich zu sein. Ein Mensch muss selbst entscheiden, was er tun wird, um das Ziel des Sprints zu erreichen. Wenn sie ihm sagen, was er tun soll, dann ist dies keine Selbstorganisation und kein Gedränge.
Wie zu behandeln : Für die Mitarbeiter im Team werden alle Stellenbeschreibungen und Hierarchien gelöscht, die Struktur ist in der Regel flach.
Alle Mitglieder des Teams sind
Entwickler des Produkts (im
Scrum-Handbuch sind keine anderen Rollen zulässig ). Es gibt nur situative Führung, und die Menschen entscheiden, wie angenehm sie arbeiten, um effektiv zu sein. Natürlich gibt es im Unternehmen allgemeine Spielregeln, das Team verletzt sie in keiner Weise (
obwohl dies die Änderung auf Unternehmensebene beeinflussen kann ), aber es ist für alle internen Dinge verantwortlich. Wenn es ernsthafte Hindernisse für die Aufhebung von Beschränkungen für Entwickler gibt, lohnt es sich, das Problem auf diejenigen auszudehnen, die sich für die Implementierung von Scrum und agiler Transformation entschieden haben. Sie können versuchen, eine flache Struktur wie ein Experiment für mehrere Sprints auszuführen und dann eine umfassende Retrospektive durchzuführen, in der alle interessierten Parteien die Ergebnisse des Experiments diskutieren.
Symptom : Menschen müssen nicht nur als Team arbeiten, sondern auch andere funktionale Aufgaben im Unternehmen erfüllen. Zum Beispiel: 50% der Zeit führen die Aufgaben des Teams aus, 50% die Aufgaben der Abteilung (Entwicklung, Test usw.).
Als schlecht : Einer der Werte in Scrum ist der Fokus. Das Team konzentriert sich auf das Sprintziel und bewegt sich darauf zu. Wenn eine Person zusätzlich zur Arbeit in einem Team etwas anderes tun muss, geht der Fokus verloren. Infolgedessen wird das Ergebnis schlechter sein. Unter solchen Bedingungen ist es schwierig, den Teamgeist aufrechtzuerhalten.
Behandlung : Wir müssen sicherstellen, dass die Mitarbeiter des Teams NUR in diesem Team arbeiten. Um dies zu erreichen, lohnt es sich, die Art der Arbeit zu verstehen, die von außen auf die Entwickler des Teams fiel, und Wege zu finden, dies zu tun, ohne das Gedränge zu brechen. Sicherlich ist diese Arbeit für das Unternehmen notwendig, daher können Sie abhängig von den Besonderheiten der Arbeit:
- Stellen Sie die Arbeit entweder in den Rückstand des Teams, und dann wird sie nach einem einzigen Workflow ausgeführt.
- oder übertragen Sie es an andere Mitarbeiter außerhalb des Teams. Beispiel: Nicht alle Unternehmen arbeiten mit Scrum, und Sie müssen zu einem bestimmten Zeitpunkt regelmäßig arbeiten. Dann ist diese Arbeit nicht mehr für Scrum-Mitarbeiter geeignet.
- oder es kann ein spezielles Team erstellt und ein Produkt ausgewählt werden, das alle Arbeiten dieses Typs sammelt.
- oder wenn es sich um eine einzigartige Funktion handelt, die von einer Person für mehrere Teams aufgrund eines Mangels an Spezialisten ausgeführt wird. Dann lohnt es sich, die Person aus allen Teams herauszunehmen und einen weiteren Prozess für sie zu erstellen, der den Rest des Scrums nicht unterbricht ( z. B. eine priorisierte Aufgabenwarteschlange ), bis Spezialisten in diesen Scrum-Teams gefunden sind.
Cross-Funktionalität
Symptom : Leute im Team machen nur einen bestimmten Job, es gibt eine klare Spezialisierung. Schlimmer noch, wenn es noch durch offizielle Pflichten, Vorschriften und andere Bürokratie abgedeckt ist. Die Abwesenheit (Urlaub, Krankheitstage usw.) eines Teammitglieds verringert die Funktionalität des Teams. Hallo, Busfaktor .
Was ist schlecht : Wenn ein Team von den Kompetenzen eines seiner Mitglieder abhängt, ist es ein Team, das gegenüber Änderungen instabil ist. Es ist schwierig, eine Kommunikation mit ihr aufzubauen, weil Sie müssen die aktuelle Funktionalität verstehen und sich an die mit dieser Fehlertoleranz verbundenen Risiken erinnern. Die enge Spezialisierung der Entwickler erschwert die organisatorische Arbeit des Teams erheblich: Bei der Planung müssen Sie viel darüber nachdenken, wer was tun wird. Nicht jede Aufgabe erfordert vorgegebene Anteile an Teamkompetenzen, daher ist es schwierig, einen ausgeglichenen Sprint zusammenzustellen. In einem solchen Schema entsteht notwendigerweise ein "schmaler Hals", der die Gesamtgeschwindigkeit des Teams verringert.
Was zu tun ist : Es ist notwendig, t-förmige Fähigkeiten zu fördern und zu unterstützen. Um das Team flexibel zu halten, ist es wichtig, dass eine bestimmte Funktion oder ein bestimmtes Wissen nicht auf eine Person konzentriert ist. Es ist notwendig, die kontinuierliche Entwicklung anzuregen und zu fördern. Es ist wichtig sicherzustellen, dass sich das Team verbessert und nach Möglichkeiten sucht, Prozesse zu verbessern. Als t-förmige Entwicklungsoptionen: Durchführung interner Seminare, bei denen Teammitglieder Wissen miteinander teilen; Übernehmen Sie die Regel der Ausführung von Aufgaben außerhalb des Kerns bei jedem Sprint jedes Teammitglieds. Paar arbeiten an Aufgaben usw. Sie können ein Team künstlich stimulieren, indem Sie seine Mitglieder für eine Weile „ausschalten“: Feiertage, Seminare, Schulungen, Geschäftsreisen usw.
Symptom : In der Wertschöpfungskette ist das Team nur für einen kleinen Teil davon verantwortlich (beeinflusst), und daher kann das Team keine eigenen Inkremente ausgeben.
Als schlecht : Wenn das Team wenig Einfluss auf die Lieferung von Inkrementen ( Produktfreigabe ) hat, verliert auch Scrum seine Essenz: Veröffentlichungen erfolgen mit einer Verzögerung, Feedback erfolgt mit einer noch größeren Verzögerung. Im Allgemeinen gibt es keinen Rhythmus und daher Geschwindigkeit. Keine Geschwindigkeit - keine Flexibilität. Ein solches Team fühlt sich nicht besessen, es ist nur eine funktionale Schraube in einem großen Auto. Die Funktionalität des Teams sollte ausreichen, um den größten Teil der Wertschöpfungskette zu schließen. Andernfalls liefert das Team einfach keinen Wert, sondern verarbeitet einfach einen „Werkstücktyp“ in einen anderen und überträgt ihn weiter.
Wir veranschaulichen dies anhand eines Beispiels aus dem Internet. Wenn vereinfacht, umfasst die Erstellung einer neuen Funktion die folgenden Schritte:
- Entwicklung von UI / UX-Prototypen
- Designentwicklung
- Erstellen einer RESTful-API
- SPA- Erstellung
- Integrationstests schreiben
- Montage und Gießen auf die Kampfumgebung
Für diese Arbeiten sind verschiedene Kompetenzen erforderlich. Ein Beispiel für eine erfolglose Aufteilung in Teams: Um
Team A von UI / UX, Designern und Frontend-Entwicklung zu trennen, bereiten sie ihr Inkrement in Form eines SPA vor. Sie hängen jedoch davon ab, wann das Backend die API vorbereitet, damit die neue Funktionalität funktioniert. Warten Sie, bis die Qualitätssicherung alles vollständig überprüft und Tests geschrieben hat. und dann erwarten sie immer noch, dass DevOps alles in die Schlacht rollen wird. Für ein solches
Team A ist es schwierig, für die Freigabe und Bereitstellung von Wert verantwortlich zu sein. Es schneidet nur die "Lücke" - SPA.
Wie zu behandeln : Wir bestimmen, welche Kompetenzen dem Team fehlen, um das Inkrement zu liefern. Wir verleihen dem Team diese Kompetenzen, indem wir vorhandene Teammitglieder schulen oder neue Spieler zum Team hinzufügen. Weil Das Finden / Unterrichten von Personen ist nicht die einfachste und schnellste Aufgabe. Dann können Sie die Kommunikation mit benachbarten Teams / Abteilungen herstellen, ihnen Scrum-Werte erklären und mit ihnen spezielle Regeln / Interaktionsregeln vereinbaren, nach denen sie Scrum für Ihr Team nicht brechen. Es lohnt sich, den Prozess der Erweiterung der Funktionalität des Teams hervorzuheben: Nach der ersten Retrospektive und der Identifizierung der fehlenden Kompetenzen können Sie diese ausdrucken und vor das Team stellen. Wenn ein Team mit mangelnder Kompetenz fertig wird (
gelernt; ein neues Mitglied des Teams; eine effektive Kommunikation mit einem anderen Team einrichten usw. ), hängen wir eine Lösung über die zuvor fehlende Kompetenz. Im Laufe der Zeit sollte sich das Team bemühen, seine Funktionalität zu erweitern, um die Wertschöpfungskette vollständig abzudecken.
Team und Produkt
Symptom : Es gibt ein Team, aber kein Produkt. Keine Bestellung, kein Rückstand. Es ist nur so, dass Menschen Aufgaben erledigen, die aus verschiedenen Richtungen kommen.
Als schlecht : Dies ist kein Gedränge. Wenn ein Produkt keinem Team zugeordnet ist, ist es unwahrscheinlich, dass das Team bei der Arbeit „brennt“. Wenn es ein globales Ziel gibt ( Vision / Strategie / Roadmap der Produktentwicklung ), möchten Sie es erreichen. Sie erledigen die Arbeit, erhalten Feedback, reflektieren und machen den nächsten Schritt. Ohne ein Gefühl der Eigenverantwortung laufen Sie Gefahr, in einer Routine zu sein: Sie brauchen kein Feedback, das Team wird nur zu einem Werkzeug für die Verarbeitung von TK zu Funktionen.
Wie zu behandeln : Das Team sollte ein eigenes Produkt mit Rückstand und Bestellung haben, das das Team mit dem Produkt entzünden und mit sich führen kann - das ist die Essenz. Müssen Sie verstehen, warum Sie Scrum brauchen? Verstehen Sie, woher das Team kommt? Verstehen Sie, ob sich in diesem Stream ein „Produkt“ befindet? Wählen Sie eines der "Kunden" -Teams aus und machen Sie es zum Eigentümer des Produkts , sodass es das alleinige Recht hat, für den Rückstand zu antworten. Es kann erforderlich sein, das Team in ein Scrum-Team aufzuteilen, das mit einer Bestellung ( dies kann ein "Pilot" -Scrum-Team sein ) und ein zweites Team arbeitet, während es auf die gleiche Weise mit den übrigen "Kunden" zusammenarbeitet. Durch maximale Transparenz der Prozesse und Ergebnisse im neuen Scrum-Team können Sie den Grundstein für die weitere Verteilung von Scrum und Agile in der Organisation legen.
Symptom : Das Team hat keinen Einfluss auf die Produktkomponente: Es entscheidet nicht, wie es zu tun ist. Das Team sagt nur, was zu tun ist. TK kommt zum Input und das Team wird als funktionale Einheit betrachtet.
Als schlecht : Dies ist eine sehr gefährliche Option, wenn das Unternehmen die Werte Agilität und Scrum wirklich verkündet. Normalerweise bedeutet dies, dass alle Mitarbeiter coole Profis sind, die alle Probleme lösen können, die keine Angst haben, Entscheidungen zu treffen und Verantwortung zu übernehmen. Wenn sie jedoch keine Produktentscheidungen treffen dürfen, erstreckt sich die gesamte kreative Freiheit des Teams normalerweise vom Produkt auf die Technologie. Da das Team nicht entscheiden darf, wie das Leben des Benutzers erleichtert werden soll, ist die Welt besser und das Produkt nützlicher. Dann beginnt das Team, eine Codebasis zu entwickeln, neue Technologien / Tools / Frameworks usw. auszuprobieren. Es besteht ein Interessenkonflikt zwischen der PO und dem Team. Das Team beginnt mit dem Verkauf von "Refactoring", "Optimierungen", "Silberkugeln" in Form eines neuen Stapels usw. Dies wird in erster Linie vom Benutzer und vom Produkt beeinflusst. Beim Übergang von Richtlinienmanagementmodellen zu agilen Modellen besteht die Gefahr, dass das Team nicht als funktionale Einheit verstanden wird (das Team hatte zuvor noch keine Entscheidung getroffen ). Dies ist mit der Tatsache behaftet, dass wir entweder die Initiative des Teams töten oder zu einer Situation kommen, in der das Team mehr an Technologie als an dem Produkt interessiert ist.
Wie zu behandeln : Sie müssen die Ursache für Misstrauen gegenüber dem Team oder dessen Unentschlossenheit identifizieren: Warum sucht das Team nicht nach einer Lösung, sondern arbeitet nur mit einer detaillierten technischen Aufgabe? Nachdem Sie die Ursache gefunden haben, können Sie sie schrittweise beseitigen. Zum Beispiel:
- Dem Team fehlen Kompetenzen oder Erfahrungen. : Jemand arbeitet an Lösungen und schreibt TK. Sie können diese Person entweder zum Team hinzufügen oder sie zusammen mit dem Team an einigen Aufgaben arbeiten lassen, um einen Teil seiner Fähigkeiten und Erfahrungen auf das Team zu übertragen. So wird das Team nach und nach lernen und sich daran gewöhnen, Produktprobleme zu lösen.
- Das Management befürchtet, dass das Team einen Fehler macht. : Dies ist der Grundstein für den Übergang zum Agilen, aber ohne ihn zu überwinden, können Sie nicht die volle Stärke des Scrum-Teams erreichen. Das Team muss einen Fehler machen, weil sich jeder irrt. Aber ein Fehler ist eine Quelle der Erfahrung und des Könnens. Es ist nützlicher, wenn ein Team einen Fehler macht, weil es dies entschieden hat und nicht wegen einer falschen externen TK. Scrum ist Rhythmus: schnell eine Entscheidung getroffen, eine Hypothese zu testen; Feedback erhalten erkannte, dass sie den falschen Weg gingen; warf die Entscheidung aus. Die Kosten eines Fehlers werden stark reduziert (Sie haben einen Sprint ausgegeben, nicht ein Viertel / Jahr / Ihre Veröffentlichungsperiode ), wodurch Sie die Angst vor Fehlern überwinden können.
Symptom : Teammitglieder haben keinen freien Zugriff auf Teamartefakte. Beispielsweise sieht nicht jeder einen Sprint oder einen allgemeinen Rückstand, oder es gibt Schwierigkeiten mit der Möglichkeit, seinen Status zu aktualisieren.
Was schlecht ist : Scrum basiert auf Transparenz. Artefakte tragen zur Erhöhung der Transparenz bei. Wenn Teammitglieder Schwierigkeiten haben, mit diesen Artefakten zu arbeiten, haben die Teammitglieder selbst keine Transparenz in der Teamarbeit, und für andere interessierte Parteien wird die Situation noch schlimmer: Es ist nicht klar, wer was und warum tut. Es ist nicht klar, wo sich die Mannschaft auf dem Weg zum Ziel befindet.
Wie zu behandeln : Es ist notwendig, die Formate von Scrum-Artefakten in einem Team zu bestimmen und sie zu erstellen ( Sie können diese Retrospektive verwenden ) und sie dann so zu platzieren, dass das Team mit ihnen problemlos arbeiten kann. Es ist großartig, wenn Sie einen separaten Bereich für das Team erstellen können, in dem das Team gleichzeitig Seite an Seite (Schulter an Schulter) arbeitet. Dies reduziert den Kommunikationsaufwand. Und im Gemeinschaftsraum ist es einfach, alles zu visualisieren ( Flipcharts, Aufkleber, Marker sind die beliebtesten Werkzeuge von Agile ). Hauptsache, es ist praktisch und nicht stressig für das Team. Artefakte sollten helfen und die Arbeit des Teams nicht beeinträchtigen, nicht bürokratisieren. Verbale Interaktion ist gut für die Teamarbeit. Wenn es Schwierigkeiten bei der Organisation der lokalen Arbeit des Teams gibt ( z. B. verteilt oder remote ), müssen Sie den Effekt von Teamarbeit und Einheit maximieren. Zum Beispiel Kanäle für Videopräsenz, interaktive Scrum-Boards in direkter Sicht auf jedes Mitglied des Teams usw.
Fazit
Im nächsten Teil werden wir weiterhin die Rollen von Scrum betrachten und schließlich zum Scrum Master gelangen. Erinnern Sie sich kurz daran, was Sie mit den Symptomen tun sollen:
- Wählen Sie die Symptome aus, die für Ihre Situation gelten.
- Wählen Sie aus diesen die schärfste.
- Werde dir dieses Schmerzes bewusst.
- Sie entwickeln eine Teamlösung ( Sie können Fälle aus dem Artikel als Ausgangspunkt nehmen ).
- Implementieren Sie Ihre Entscheidung.
- Fahren Sie mit Schritt 1 fort.
Vielen Dank fürs Lesen. Ich würde gerne die Ihnen bekannten „Symptome“ in den Kommentaren sehen.
Vielen Dank an Sai Kin für die Illustration.
Der nächste Teil über den Scrum-Assistenten