Auf der diesjährigen TeamLead sprach Sergey darüber, wie sich Agile in einem großen Unternehmen verändert und wie sich Ihre Umgebung (Teamleiter und Teams) entsprechend verändert und welche neuen Anforderungen an Sie als Führungskräfte gestellt werden. Und er zeigte den gesamten agilen Prozess mit Fotos.
Erste Schritte mit Agile
Wenn Sie bereits Agile haben, wie haben Sie sich entschieden? Haben Sie selbst und bewusst entschieden, dass dieser Prozess (Scrum oder Kanban) genau das ist, was Sie brauchen und was genau dazu beiträgt, Ihre Probleme zu lösen? War Ihre erste Bekanntschaft mit Agile so?
... oder ist das passiert?
In großen Organisationen ist die übliche Geschichte, wenn ein Manager hereinkommt: „Das war's, morgen sind alle Scrum! Es ist keine Zeit, es herauszufinden - Sie sind ein Scrum Master oder ein Product Owner. " Darüber hinaus zeigen die Zahlen aus der Studie "Agile in Russia": Je größer der Maßstab, desto häufiger kommt diese Geschichte vor. Unabhängig davon, wie Sie es geschafft haben, sich auf Agile einzulassen, lassen Sie uns herausfinden, wo Sie sich befinden, was diese Umgebung ist und welche Anforderungen sie an Sie und Ihre Teams stellt. Wenn dies nicht behandelt wird, wird die Implementierung von Agile sehr oft zu einer Fabrik von Funktionen.
In der Vergangenheit haben Entwickler Tickets von Jira genommen. Jetzt machen sie dasselbe, aber sie nehmen aus dem, was jetzt als Rückstand bezeichnet wird: Ein Rückstand wird zu Ihnen aufgerollt, Sie nehmen daraus - und der Förderer fährt fort. Gleichzeitig führen Ihre Produkte den Benutzer irgendwo in das ein, was am Ende passiert ist: Benutzer und Produkt, Kuss!
Ist es wirklich agil? Dafür haben wir es nicht gemacht.
Was ist agil und warum?
Sie wissen, dass Agile ein Ansatz ist, um Projekte trotz großer Unsicherheit auszuführen. Dies ist Stacys Verwirrungsmatrix:
Agile funktioniert gut in einer Situation, in der Sie zwei große Unsicherheiten haben:
- Was müssen Sie für Ihre Verbraucher tun, damit sie mit Geld für Ihr Unternehmen und Ihr Produkt stimmen?
oder
- Sie wissen nicht, mit welchen Technologien dies umgesetzt werden soll.
dann befinden Sie sich in einer komplexen Umgebung, in der Ihnen angeboten wird:
- Geben Sie die Meinung auf, dass Sie wissen, was Ihre Benutzer benötigen.
- Hypothesen aufstellen;
- eine Reihe von Experimenten durchführen;
- Erhalten Sie Feedback vom Endbenutzer (zunächst unzufrieden, und wir hoffen, in Zukunft einen Weg zu finden, um sein Problem zu lösen).
Infolgedessen haben Ihre Teams und im Allgemeinen Ihre gesamte Organisation zwei Schwerpunkte:
- Was ist Kundennutzen? Sie müssen lernen, wie man es misst, indem Sie systematisch mit dem Wert des Kunden arbeiten.
- Mach es schnell. Es wird manchmal gesagt, dass die Zähigkeit eines Teams an der Anzahl der pro Zeiteinheit getesteten Hypothesen gemessen wird.
Wie kann man das alles auf unserer Realität landen?
Was ist die Aufgabe des Führers?
Es gibt zwei Akteure im System: Sie als Leads und Ihre Teams. Stellen Sie sich ein einfaches Beispiel vor: Ein Team stellt ein Produkt her, aber der Kunde ist unglücklich. Was sollen wir als Leads tun, was ist unsere Aufgabe in dieser Geschichte? Finden Sie natürlich heraus, wo das Problem liegt: Sie als Experte gehen und finden es heraus. Nehmen wir an, das Entwicklungsteam reicht es am letzten Tag zum Testen ein, sodass eine große Anzahl von Problemen den Benutzer erreicht. Was machen wir als nächstes?
Wir wissen bereits, wo das Problem liegt, wir haben es identifiziert. Am einfachsten ist es jetzt, zum Team zu kommen und zu sagen: "Hören Sie, Leute, Sie machen das jetzt - machen wir das nicht! Lass es uns richtig machen. " Dies geschieht normalerweise mit Kindern. Ich sage meinem siebenjährigen Sohn: "Vladik, tu das bitte nicht!" Und das funktioniert übrigens wirklich - er hört damit auf. Richtig, später sagt mir meine Frau, dass er das nur nicht vor mir tut. Und wenn ich bei der Arbeit bin, geht alles weiter wie bisher.
Also funktioniert es nicht. Was machen wir dann? Wir ändern den Prozess, stellen dem Team Fragen, was getan werden könnte, um nicht schlecht zu werden. Grundsätzlich können wir als Führungskräfte nur die Umgebung anpassen, die das Verhalten unserer Teams bestimmt. Wir schaffen ein Umfeld, das negatives Verhalten unmöglich macht und Menschen dazu motiviert, sich anders zu verhalten:
Zum Beispiel implementieren Sie Scrum. Von nun an ist es unmöglich, das Ergebnis nicht mindestens alle 2 Wochen zu liefern. Nein, ein Entwickler kann das, aber er erhält motivierendes und anregendes Feedback, wenn Sie als Führungskraft Leute einladen, den Sprint zu überprüfen, der alles sagt, was er über das Produkt denkt, ohne zu zögern. Aus irgendeinem Grund schämt er sich ein wenig, jeden Tag die gleiche Aufgabe zu übernehmen - jeden Tag muss er dem Daily Scrum antworten, was er gestern getan hat, was er heute tun wird und sogar mit dem bösen Zusatz „innerhalb des Sprintziels“.
Das heißt, Sie schaffen eine Umgebung, die das Denken der Menschen allmählich verändert und sie beginnen, sich anders zu verhalten. Unsere Aufgabe ist es, ständig darüber nachzudenken, wie die Umgebung eingerichtet werden soll. In diesem Sinne werden wir nicht zu Menschenführern, sondern zu Mechanikern für die Einrichtung des Systems. Stellen Sie sich ein System vor - die Zahnräder drehen sich von selbst (dies sind unsere intelligenten Spezialisten), und es gibt Reibung zwischen ihnen. Sie laufen mit einer Ölkanne herum und fügen hinzu, wo etwas zu knacken beginnt - Sie richten ein System ein, das von selbst funktioniert.
Und die coolsten von uns machen es so, dass sich das System aus irgendeinem Grund von selbst entwickelt. Sie schaffen beispielsweise eine Umgebung, in der das Team die Ergebnisse seiner Arbeit betrachten und sich selbst coachen kann: Was kann man noch tun, um noch cooler zu werden? Wenn Sie ein solches System eingerichtet haben, ist es zwar ein Problem für Sie, Traurigkeit (oder Freude) - Sie brauchen dieses System nicht mehr (zumindest nicht mehr im Alltag), das System beginnt sich selbst zu entwickeln. Dies nennt man ein selbstorganisiertes Team.
Aber wie kann dies erreicht werden?
Wofür ist das Scrum-Team verantwortlich?
Lassen Sie uns von unten nach oben gehen - nehmen Sie einfach ein Scrum-Team, noch keine Skala. Eine Frage an Sie: Wofür sind die Teams am Ende des Sprints verantwortlich? Wofür schaltest du sie, wenn der Sprint vorbei ist?
Die übliche Antwort ist für Funktionen. Wenn ein Team eine Feature-Factory ist, wie hängen dann Features miteinander zusammen? Warum machen wir diese Funktionen und nicht andere? Auf diese Fragen gibt es keine Antwort - eine solche Umgebung wurde noch nicht erstellt. Ein klassisches Beispiel ist der Vorstand des Teams von Avito vor etwa 2,5 Jahren. Es ist zu sehen, dass am Ende des Sprints viele Aufgaben noch nicht erledigt sind - nur etwa 40% sind fertig:
Lassen Sie uns herausfinden, wo das Problem liegt. Eines der häufigsten Probleme am Anfang ist, dass die Teams nicht wissen, wie sie bewerten sollen. Wir müssen ihnen beibringen, was ein Story Point ist, wie man ihn richtig angeht, wenn es im Team Backing, Front usw. gibt. Zeigen Sie ihnen anhand eines Beispiels, wie das geht.
Es gibt noch ein anderes Problem - sie können alles, aber sie haben keinen Fokus. Dann bringen wir das Team zu einer Retrospektive und fragen: "Was war der Zweck Ihrer Arbeit?" Als Antwort darauf schaut eine Ziege auf das Knopfakkordeon und die Frage: "Was sind die Sprintziele?" OK, lassen Sie uns in eine große Schachtel legen, was Sie in den letzten zwei Wochen getan haben. Sie klingen, du schreibst. Danach bewertet jeder anonym den Aufkleber mit einer Bewertung: "Wie weit haben Sie als Team diese Sprintziele erreicht?" Das heißt, das Team muss die Frage beantworten und alles überprüfen, was getan wurde: Schauen
wir uns Beispiele an.
Sprintziele - 8
Im Wesentlichen sind dies häufige Aufgaben. Außerdem habe ich eine Umgebung geschaffen, die zeigt, dass jeder Mitarbeiter sein eigenes Ziel (Aufgabe) hat. Und als eine andere Person antwortete, nahm ich einen Marker in einer anderen Farbe:
Es ist zu sehen, dass jeder seine eigene Arbeit hatte. Und das Verständnis des Teams, wie wir das Ziel erreicht haben, ist völlig anders. Danach wird normalerweise die Frage gestellt: "Wie viel sind wir ein Team?" Denn es sieht so aus, als hätte jeder nur seine eigene Arbeit gesägt. Wahrscheinlich hat der Typ, der eine Zwei gegeben hat, wirklich eine schwierige Aufgabe ausgeführt, und anscheinend hat ihm niemand geholfen. Der Kamerad mit den Neun half nicht besonders - er reduzierte seine Aufgabe und war wahrscheinlich am Ende des Sprints mit der Selbstentwicklung beschäftigt, obwohl sie im anderen Teil des Teams bombardierten und Hilfe brauchten.
Sprintziele - 6 Stück
Dies ist ein anderes Team, aber die Situation ist dieselbe. Das Verständnis der Realität ist bereits nahe 8-9, aber es gibt eine Sechs. Dies ist genau der Teamleiter - er verstand besser als jeder andere, wie nah sie am Ziel waren:
Sprintziele - 5 Stück
Ziele komprimieren. Es ist lustig, aber es gibt bereits eine Normalverteilung. 3-4-5 und 7-8-9 sind zwei Subteams von drei Personen innerhalb des Teams, die zusammen einen Job gezogen haben und mehr oder weniger erfolgreich waren. Die Jungs von 3-4-5 hatten ein schwieriges Feature, sie kamen nicht zurecht. Aber sie verstehen ungefähr gleich, dass sie gemurrt haben. Die drei Sechser sind die Senioren, die am besten verstehen, was los ist, weil sie den Juns in beiden Teilen geholfen haben:
Sprintziele - 2-3 Teile
Was ist, wenn Sie überhaupt kneifen? Je weniger Sprintziele, desto mehr Verständnis für die Realität - was wir tatsächlich getan haben und wie viel wir erreicht haben - fällt in den Köpfen der Menschen zusammen:
Warum habe ich das alles gezeigt? Warum ist es cool, wenn das Team ein Ziel hat?
Die Bedeutung des Zwecks in Agile
Weil sich Agile von den Klassikern darin unterscheidet:
In den Klassikern versprechen wir eine Reihe von Funktionen, und wir können weiter spielen: entweder mehr Ressourcen in die Entwicklung investieren oder die Fristen verkaufen. Es gibt nur diese beiden Parameter, da Sie das gesamte Volume ausführen müssen.
In Agile verstehen wir im Voraus, dass wir uns in einem Bereich der Unsicherheit befinden und nicht wissen, welche Funktionen unsere Verbraucher wirklich benötigen: Wir haben nur Hypothesen. Manchmal sagen sie Halluzinationen, und der größte Experte in ihnen ist unser Product Owner. Er halluziniert innerhalb zweier Einschränkungen: Ressourcen werden gebunden (Vollzeit-Team, alle zu 100% zugewiesen) und der Sprint endet genau dann, wenn er endet, nicht früher und nicht später. Beide Parameter sind fest, aber wir möchten, dass der Bereich schwebend ist. Das ist keine schlechte Sache, das ist eine coole Funktion: Wir möchten in der Lage sein, den Umfang zu ändern und Feedback zu erhalten - ob wir es tun oder nicht. Aber du brauchst einen Meter - das ist das Ziel. Wann sonst schießt das Ziel?
Was ist der Zweck des Sprint Review?
Es gibt zwei Möglichkeiten, eine Sprint-Überprüfung durchzuführen.
Das Team zeigt dem Produktbesitzer am Ende des Sprints ein funktionierendes Produkt. Sehen Sie, wie er ihn ansieht. Es stellte die wichtigste Frage: „Product Owner, geben Sie uns Feedback: Wie weit haben wir das Sprintziel erreicht? Und wie müssen wir den weiteren Rückstand ändern? " Der Product Owner hat eine geschlossene Pose: „Was kann ich Ihnen hier sagen? Ja, die Tasten scheinen zu funktionieren. " Es entsteht eine Verwirrung: Wie kann ein Produktbesitzer Feedback zu Arbeitsschaltflächen geben, wenn es keine wirklichen Informationen darüber gibt, wie es in den Feldern
funktioniert, dh es gibt kein Feedback von Endverbrauchern: Die zweite Option ist meine Lieblingsgeschichte eines der Avito-Teams, die auch etwa 2 Jahre. Dieses Team verbindet Verkäufer und Käufer im Messenger. Es hat zwei Schlüsselmetriken:
- , , , ..
- , .
Das Team innerhalb des Sprints hat eine banale Funktion implementiert - ein rundes Stück, das zeigt, dass der Käufer oder Verkäufer am anderen Ende der Linie jetzt online ist: Sie können schnell schreiben und er wird sofort antworten. Bei der Sprint-Überprüfung zeigten sie die Ergebnisse eines A / B-Tests, bei dem das Feature für eine begrenzte Anzahl von Kunden in der Produktion eingeführt wurde und geprüft wurde, ob es wirklich mit diesen beiden Metriken korreliert. Es gab keine offensichtliche Korrelation, und das Team bat um eine weitere Woche, um Daten zu erfassen und zu verstehen: Wenn diese Funktion noch benötigt wird, wie kann sie dann geändert werden?
Dies sind zwei verschiedene Optionen. Ihr Ziel funktioniert, wenn Sie es nicht nur als Slogan festlegen, sondern wenn es in messbaren Metriken formuliert ist. Ansonsten ist es wieder eine Entweihung.
Was können die Ziele eines Sprints sein?
Sie können Ziele basierend auf Meilensteinen festlegen: Veröffentlichung bis zu diesem oder jenem Datum usw. Auch hier gibt es wenig Informationen: Wie messen Sie, dass dies das ist, was Ihre Verbraucher wollen?
OKR bietet einen anderen Ansatz: Wir setzen Ziele basierend auf Metriken und kundenspezifisch. Wie interagiert ein Kunde mit Ihrem Produkt? Wie wirkt sich das auf die Tatsache aus, dass er seine Probleme schneller, besser, besser usw. löst? und bereit, mit Geld für Ihr Geschäft zu stimmen? Daher müssen Sie Meter haben.
Eine der Eigenschaften eines Ziels sollte, wie der OKR sagt, ein Maß an Ehrgeiz sein. Das heißt, wir möchten das Leben des Kunden für einen Sprint nicht nur verbessern, sondern um wie viel - bis zu 80%, 52% usw. Dies ist der Zähler, auf den Sie springen möchten:
Fazit: Welche Art von Umgebung schaffen wir?
Der Product Backlog ist nur eine Reihe von Hypothesen. Wir als Mechaniker dieses Systems müssen auf Teamebene die Einstellung der Menschen gegenüber dem Rückstand mental ändern. Sie haben Halluzinationen in Ihrem Rückstand. Stellen Sie daher immer eine Frage an den Product Owner, das Unternehmen usw. - Warum machen wir das? Warum sind Sie sicher, dass dies das ist, was unsere Kunden brauchen? Wenn wir uns nicht sicher sind, wie können wir messen, dass dies wirklich das ist, was sie wollen? Ändern Sie die Mentalität sowohl des Teams als auch Ihrer Geschäftskunden, um gemeinsam das Gefühl aufzugeben, dass Sie alles im Voraus wissen.
Das Team ist dem Ziel des Sprints verpflichtet. Bitte übernehmen Sie keine Verpflichtung von Teams für das Scoping. So schieben Sie sie im Wesentlichen in den Wasserfall, obwohl Sie es Scrum nennen. Es geht nicht darum, alle Funktionen im Sprint zu nutzen. Nein, Ihr Team im Sprint des Scrum-Prozesses kann sogar Ihren Produktstau ändern, wenn es plötzlich feststellt, dass das, was Sie vor einer Woche halluziniert haben, Sie Ihrem Ziel nicht näher bringt. Natürlich sind zwei Wochen eine kurze Zeitspanne, und am Ende wird sich für Sie vielleicht nicht viel ändern. Trotzdem geistig verändern - im Maßstab kommt dieses Problem in seiner ganzen Pracht zum Vorschein.
Der Produkt- und Sprint-Rückstand ist nur ein Plan zur Erreichung eines Ziels. Der Plan sollte regelmäßig anhand des Ergebnisses überprüft und im Falle einer Ablehnung geändert werden. Ich habe bereits gesagt, dass Sie im Daily Scrum jeden Tag die Frage stellen müssen: "Was machen wir mit dem Ziel im Allgemeinen?" Allmählich werden Sie die Menschen darin schulen, mehr über das Ziel als über den Umfang nachzudenken. Aber zuerst müssen Sie dies mehrmals wiederholen, damit die Leute endlich verstehen, warum wir das tun.
Der Fokus liegt mehr auf dem Endergebnis als auf der Vorhersehbarkeit der Lieferzeiten. Wir konzentrieren uns mehr darauf, einige Metriken zu ändern, als nur Funktionen einzubeziehen. Es ist sogar möglich, einige Funktionen nicht fertigzustellen: Wenn Sie möglicherweise 2/3 Ihres Sprint-Backlogs abschließen, erzielen Sie eine Verbesserung der wichtigsten Messdaten für den Client, und es spielt keine Rolle mehr, dass zwei Funktionen nicht abgeschlossen wurden. Das Ziel ist etwas anderes.
Sprint Review - Bewerten Sie Ihren Fortschritt in Richtung eines Ziels anhand des Kundenfeedbacks. Darüber hinaus von echten Kunden. Dies ist eine Herausforderung für alle Mitarbeiter im Zusammenhang mit der Engineering-Praxis, die Ihr Team verwendet: Kontinuierliche Integration, Kontinuierliche Bereitstellung usw. Dies ist es, was jetzt in anderen Branchen stürmt, in denen Agile versucht, sich zu bewerben.
Zum Beispiel hat die sibirische Gurman-Firma in Nowosibirsk, die Knödel herstellt, beschlossen, mit dem Bereich der Unsicherheit zu experimentieren: Was wirkt sich auf die Kaufkraft des Produkts aus, wenn Sie die Geschmacksfüllung von Knödeln oder der Verpackung ändern? Cool! - Jetzt werden wir Experimente durchführen und Feedback erhalten. Aber was bedeutet Experimentieren? Sie kommen mit einem neuen Knödelformat zum Einzelhändler, aber der Einzelhändler möchte keine kleinen Einkäufe tätigen und bietet sechs Monate lang ein großes Angebot an - so dauert das Experiment ein Jahr. Infolgedessen hat Sibirskiy Gurman ein eigenes Geschäft eröffnet, in dem Sie schnell Feedback erhalten können. Das Geschäft ist jedoch ein völlig kostspieliger Teil des Projekts.
Wie Sie sehen, ist in der IT alles einfacher. Alles wurde bereits erfunden. In anderen Branchen sind die Menschen kreativ, um so schnell wie möglich Feedback zu erhalten. Aber es passiert für alle.
Was passiert auf der Waage?
Irgendwo hier auf dem Bild ist dein Team. Und es beginnt: Jedes Team hat seinen eigenen Rückstand, sein eigenes Ziel, Sie verstehen, wer Ihr Kunde ist, aber aus irgendeinem Grund kommen viele Leute (Auftragnehmer, Stakeholder usw.) zu Ihnen gerannt, die etwas anderes von Ihnen wollen ( Stecken Sie zum Beispiel Ihre Halluzinationen in Ihren Rückstand), und aus irgendeinem Grund müssen Sie sie auch tun:
Auf der Ebene der endgültigen Symptome haben wir Folgendes:
- Eine Vielzahl von Abhängigkeiten.
- Wir wissen oft nicht im Voraus, von wem wir abhängig sind - dies ist die geringe Transparenz dessen, mit wem ich einverstanden sein muss, um eine Funktion einzuführen. Sie beginnen es im Sprint und in diesem Moment werden Sie herausfinden: Es stellt sich heraus, dass wir die API nicht selbst ändern können, wir müssen zu dieser laufen; Hier müssen Sie sich jedoch auf Vorschriften, Informationssicherheit usw. einigen. Das heißt, es ist nicht im Voraus bekannt, zu wem man laufen soll.
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
Woher kommt das alles auf einer Skala und warum entsteht es? Betrachten wir das Beispiel eines klassischen Beispiels für die Gewährung eines Kredits, bei dem all diese Abhängigkeiten in der Bank entstehen.
Das erste, was eine Bank tun sollte, ist den Leuten zu sagen, dass sie hervorragende Kreditbedingungen hat: qualitativ hochwertig, schnell usw. Tatsächlich beginnt die Arbeit mit einem Kunden mit Marketing. Dann erfolgt eine Bewertung, Registrierung usw. bis zum vollständigen Abschluss des Darlehens. Das Unternehmen verfügt über operative Services, die den Kunden direkt bedienen und mit ihm kommunizieren:
Darüber hinaus scheinen IT-Systeme zu unterstützen, zu beschleunigen und zu automatisieren - im Allgemeinen stellen sie sicher, dass der Kunde einen Kredit kühl und schnell erhält. Hier erscheinen unsere Mitarbeiter und unsere Organisationsstruktur. Hier ein Beispiel: Es gibt 310 Entwickler in der IT-Abteilung von Moskau, 30 Mitarbeiter in Estland und einen weiteren Anbieter in Amerika (150 Mitarbeiter):
Ein echtes Beispiel für mich. Als ich meine dritte Hypothek von meiner Lieblingsbank erhielt, wurde ich in Phase 2 (schnelle Prüfung der Anträge) abgelehnt. Am Abend desselben Tages ruft mich mein VIP-Manager mit der klassischen Frage an: „Sergey, ist bei unserer Bank alles in Ordnung mit Ihnen? Vielleicht kann ich dir bei etwas helfen? " Natürlich treffe ich ihn: „Alter, was ist passiert? Ich bin dein VIP-Kunde. Warum wurde meine Hypothek abgelehnt, wenn alles in Ordnung mit mir war? " Er bat um eine Auszeit und rief mich am Abend zurück - er konnte die Frage nicht sofort beantworten, weil er in das CRM schaute und dort überhaupt keine Informationen sah, dass ich überhaupt einen Antrag gestellt hatte.
Der Grund war, dass diese Bank in diesen Jahren den ersten Teil ihrer operativen Dienstleistungen an ihren Partner auslagerte. Das heißt, es gab eine Mutterbank und eine Partnerbank, die Kunden am Eingang bedienten - grob gesagt war es nicht die Mutterbank, die mich liebt, sondern ihr Partner, der mich ablehnte. Da die Verantwortung einer Bank an der Kreuzung mit der Verantwortung einer anderen Bank endete, brach die Integration zusammen. Ein kleiner Fehler machte der Mutterbank nicht bewusst, dass sein geliebter Kunde von der Partnerbank nicht sehr gut behandelt wurde. An solchen Kreuzungen verliert ein Unternehmen sehr oft seine Kunden und damit Geld.
Warum mache ich das? Stellen Sie sich vor, Ihr Scrum-Team - funktionsübergreifend in Bezug auf Backing, Front usw. - befindet sich irgendwo innerhalb dieser Struktur. Die Schlüsselfrage lautet: Wie funktionsübergreifend sind Ihre Teams bei der Lösung von Kundenproblemen? Im Idealfall sollte die funktionsübergreifende Funktion so sein, dass Sie dem Kunden in jeder Phase seines Kommunikationslebenszyklus mit dem Unternehmen helfen können. Können Sie sich vorstellen, wie viele Kompetenzen Sie benötigen, um beispielsweise für 11 Personen in ein Scrum-Team zu passen?
Leider ist dies im großen Maßstab das Hauptproblem: Das Team ist in Bezug auf den Kunden nicht mehr funktionsübergreifend. Die Lösung lautet: Stellen wir ein großes Team von Teams zusammen, die so funktionsübergreifend wie möglich sind.
Hier ist ein Beispiel (zwei rote Aufkleber). Ein Aufkleber mit der Aufschrift "Hypothek" bedeutet, dass wir die Organisationsstruktur so ändern, dass eine Hypothekenteilung erscheint (Strom, Stamm, Zug usw., in verschiedenen Unternehmen wird sie unterschiedlich genannt). Wir kombinieren Unternehmen (verantwortlich für Finanzkennzahlen für die Ausgabe von Hypotheken) und Teams (in Moskau und Estland), um im ersten Teil dieses Streams Systeme zu entwickeln, Integrationsfehler zu beheben usw.:
In meiner Geschichte konnte der Anbieter nicht in dieses Thema hineingezogen werden. Sie sagten: "Schreiben Sie uns die TOR, wir werden alles tun." In jedem Fall bilden Sie jedoch eine Abteilung, die den Kunden so umfassend wie möglich betrachtet. Es gibt oft einen Toast: „Konzentrieren Sie sich auf den Kunden, den Wert“, aber zählen Sie die Anzahl der Schritte, die dieses Gerät schließt. Je mehr es schließt, desto kühler wird es, genauer gesagt, es wird allmählich steiler und kann alle Probleme des Kunden lösen.
Warum erzähle ich das? Die Aufgabe des Leads besteht nicht nur darin, eine Umgebung für die Teamentwicklung zu schaffen. Zuerst müssen Sie verstehen:
- In welchem Kontext bist du?
- Welche Schritte und Kundenprobleme löst Ihr Team oder Ihre Abteilung?
- Wer ist dein Geschäft?
- Was ist der Endkunden-KPI für Ihren Geschäftsbereich? Das heißt, was verbessern Sie und nicht nur Ihr Team, sondern die gesamte Strecke.
Als Beispiel stelle ich drei Optionen für funktionsübergreifende Einheiten vor.
Option 1: pro Kanal mit Plattform
Einer davon ist im Wesentlichen der gesamte Webfeed, in dem sich alle Webentwickler befinden. Für eine Bank liegt die Hauptkennzahl beispielsweise in der Gewinnung, sodass der Kunde versucht, diese mit einem Kreditrechner zu berechnen, und sich in einen Hypothekarkreditnehmer verwandelt.
Mobile App (iOS, Android usw.) bereits mit Messwerten für Aktivierung und Wartung. Es kann auch eine Plattformabteilung geben, dh eine Komponente herstellen, deren Verbraucher andere Abteilungen sind:
Option 2: Nach Produkten mit Plattform
Die zweite Option ist cooler: Sie ändern die Organisationsstruktur so, dass jede Einheit in Bezug auf Kanäle funktionsübergreifend wird. Wir müssen etwas im Guthaben korrigieren - wir tun dies sowohl im Webkanal als auch im Mobiltelefon, genau wie bei Debitkarten. Die Abteilung kann alle Kanäle vollständig ändern. Sie müssen jedoch sicherstellen, dass die Abteilungen Änderungen an derselben Codebasis vornehmen können.
Dies ist eine schwierigere, aber coolere Option. Das Geschäft mag es wirklich, weil der Debit-Stream verdient: Sie können verstehen, wie viel wir verdienen, und es gibt eine Gehaltsabrechnung für die Entwicklungsteams. Infolgedessen kombinieren Sie Umsatz mit Kosten. Ihre Abteilung wird zu einem kleinen Unternehmen innerhalb eines großen Unternehmens, da sie über eine eigene Gewinn- und Verlustrechnung verfügt und Sie sehen können, wie effektiv Sie als Mikroorganisation sind:
Option 3: Schritt für Schritt Wertstrom
Komplexe Fälle haben eine große Anzahl von Abteilungen, und jede ist für eine Reihe von Metriken verantwortlich. In großen Organisationen ist dies die beliebteste Option:
Welche Art von Umgebung schaffen wir im Maßstab?
Im Maßstab schaffen wir die gleiche Umgebung wie auf der Ebene eines Teams. Eigentlich macht es das Gleiche, aber wir erweitern die Funktionalität über die gesamte Kundenreise hinweg. Daher gibt es ein Meer von Schwierigkeiten: Kommunikation mit Unternehmen, anderen Teams, komplexere Zyklen (nicht zwei Wochen, sondern vierteljährlich):
Teilen der vierteljährlichen Zielplanung: OKR-Planung (PI-Planung)
Okay. Ihr Team versteht bereits, dass Sie Ihrem Kunden nicht in allen Phasen helfen können. Sie verstehen jedoch, dass es ein Unternehmen gibt, mit dem Sie planen müssen, Kundenkennzahlen zu ändern. Sie sehen, es gibt immer noch viele Leute: ungefähr 150 andere Spezialisten (10-12 Teams). Und mit wem, so scheint es, kommunizieren muss, weil Sie von ihnen abhängig sind und sie - von Ihnen.
Wie man kommuniziert? In allen Ansätzen gibt Agile ein einfaches Rezept: "Sprechen Sie einfach: Sie haben eine Sucht mit jemandem, gehen Sie und sprechen Sie mit ihm." Entwickler, insbesondere diejenigen, die mehr mit dem Monitor als mit anderen Menschen kommunizieren möchten, sagen: "Nun, das kann ich nicht - wie kann ich nur sprechen?" Daher bieten alle Frameworks Kommunikationszwang: „Okay, Sie können nicht kommunizieren. Jetzt werden Sie kommunizieren, aber nach dem folgenden Algorithmus. "
Die kollaborative OKR-Planung (in einem anderen Ansatz namens PI Planning) gewinnt zunehmend an Beliebtheit. Die Idee ist, dass wir über einen langen Zeitraum (ein Viertel) zusammen mit der gesamten Menge, um zu verstehen, wer unser Geschäft ist und welche Abhängigkeiten darin bestehen, gemeinsame Ziele planen. Dies ist eine zweitägige Veranstaltung, aber einige Leute schaffen es, sie an einem Tag abzuhalten, wenn die Teams bereits gelernt haben, miteinander zu kommunizieren. Grob gesagt handelt es sich um eine zweitägige Frage-und-Antwort-Veranstaltung, die Folgendes ermöglicht:
- Von wem hängen wir ab?
- Was machen wir in diesem Quartal?
- Welche Finanzkennzahlen möchten wir erhalten? Geschäft, bitte antworten.
Das heißt, wir stellen sicher, dass sich alle mit allen einigen und herausfinden, wo wir bis zum Ende des Quartals laufen wollen. Dies sind echte Fotos, als die Sberbank vor drei Jahren zum ersten Mal versuchte, solche Veranstaltungen zu starten: Die
gemeinsame OKR-Planung oder PI-Planung wird schrittweise durchgeführt.
Einweisung
Zu Beginn ist eine Einweisung erforderlich. Die Unternehmen sollten sagen: „Das würde mir bis zum Ende des Quartals gefallen ...“ Und hier oben ist beispielsweise die Sberbank vor etwa drei Jahren und unten die GameDev-Firma Xsolla aus Los Angeles. Die Amerikaner erzählten übrigens eine einfache Geschichte, dass sie keine Probleme haben, neue Kunden zu aktivieren: Mit den Messwerten für die Aktivierung ist alles cool. Bei Wiederholungskäufen gibt es jedoch ein Problem: Aus irgendeinem Grund ist der Prozentsatz der Wiederholungskäufe sehr gering. Und das zweite Problem ist, dass aus irgendeinem Grund keine zusätzlichen Dienstleistungen gekauft werden und der durchschnittliche Scheck niedrig ist. Und das Unternehmen fragte: "Bitte, alle Funktionen in diesem Quartal zielen auf Wiederholungskäufe und eine Erhöhung des durchschnittlichen Schecks (zusätzliche Dienstleistungen) ab."
Dies ist eine der Möglichkeiten, wie eine gute Vision aussehen kann: Wenn wir über den Geschäftskontext und Finanzkennzahlen sprechen. Wir wissen jedoch nicht im Voraus, was im Quartal geschehen wird. Was passiert als nächstes?
Rede des Architekten
In IT-Unternehmen hören wir definitiv dem Architekten zu. Eine interessante Geschichte für ihn! - Auch die Umwelt verändert sich. In solchen Sitzungen verstehen die Architekten endlich, wer ihr Kunde ist (die meisten Unternehmensarchitekten glauben, dass dies ein Geschäft ist):
Dieser Architekt wollte schnell über die „schreckliche“ Landschaft der Sberbank berichten und weglaufen: „Ich habe Ihnen alles erzählt! Darüber hinaus gab er eine konzeptionelle Architektur von 50-100 Seiten. Was kann ich hier noch tun? Immer noch verständlich, aber wenn überhaupt - anrufen. " Nach der Präsentation stellte ihm einer der Teamleiter eine Frage:
- Lieber Architekt! Der dritte aus dem oberen rechten Würfel - wussten Sie, dass dieses System noch nicht in Betrieb ist?
- Natürlich weiß ich das. Ich selbst habe diese Würfel gezeichnet.
- Wissen Sie, dass es in sechs Monaten in Betrieb genommen wird?
- Ja bitte.
- Denken Sie jetzt daran, dass wir uns in der Planungssitzung für die vierteljährlichen Ziele befinden und das Unternehmen von uns Funktionen wünscht, die theoretisch dieses System durchlaufen sollten.
Hier versteht der Architekt, was die Frage ist. Und das Team bat ihn, bei ihnen zu bleiben, damit sie bei der Planung ihrer Funktionen gemeinsam überlegen, wie sie eine unangemessene Entscheidung treffen können.
Schwärmen (Zielgenerierung)
Dann machten sich die Teams auf den Weg zum Freischwimmen. Sie haben drei Stunden Zeit und müssen vierteljährlich Ziele festlegen, für die sie bereit sind, Verantwortung zu übernehmen. Dies nennt man Schwärmen (Schwärmen, Summen). Dies ist eine Art Vernetzung, aber im Rahmen der Arbeit:
Natürlich ist nicht alles so einfach. Die Kinder erhalten einen Algorithmus, mit dem sie erreichen können, welche angemessenen Ziele sie für das Quartal erreichen können. Sie erstellen Flipchart-Blätter, die die geschätzten Sprint-Rückstände um ein Viertel vor uns anzeigen. Dies ist notwendig, damit sie nach Berücksichtigung ihrer Verfügbarkeit ihre Rückstände grob ausfüllen und mit anderen Abhängigkeitsteams sprechen (wer, mit wem, was wird / wird was nicht tun) und ihnen die Frage stellen: „Wenn Sie all diese Arbeiten ziehen, was Ziele, die Sie erreichen werden, und mit welchem Maß (Metrik) können Sie den Grad der Erreichung messen? "
Das heißt, wir planen Arbeitsrückstände, formulieren dann darauf basierende Ziele und lehnen diese Rückstände ab. Es ist nur eine Technik, um zu einer angemessenen Zielsetzung zu gelangen. Denken Sie unter keinen Umständen, dass die Jungs alle Teams für diese Arbeiten für das Quartal verpflichten:
- Team, kommen Sie mit einem Ziel!
- ... Das ist es!
- Bist du sicher, dass du es erreichen wirst?
- Nein, Sie haben nur darum gebeten.
Nein, wir erleichtern, das heißt, wir helfen, mehr oder weniger angemessene Ziele zu erreichen.
Auf dem Foto sind Vertreter der Teams zu sehen, die zur Kommunikation gezwungen wurden. Sie kommen manchmal mit dem Gefühl zu dieser Sitzung: "Ja, wir verstehen, was wir tun werden, und es scheint, dass wir sogar die Abhängigkeiten von anderen Teams kennen, weil wir letzte Woche mit ihnen gesprochen haben." Wenn Sie mich jedoch direkt bitten, zu sagen, was die Teams in diesem Quartal tun werden, werden die Abhängigkeiten endlich aufgedeckt:
Wir geben ihnen ein Werkzeug, damit sie, nachdem sie über ihre Sucht gesprochen haben, sie anzeigen und sehen können, wer von wem abhängt. Vertikale Sprünge sind Sprints innerhalb des Blocks, horizontale Sprünge sind Teams. An der Kreuzung legt das Team fest, welche Funktion es ausführen wird, und zeichnet sie mit einem roten Pfeil auf: "Aber sie haben uns versprochen, einen Sprint vor der API durchzuführen, dann werden wir vorne einen Knopf drücken." Dies ist ein Protokoll der Vereinbarung, das wir mit Ihnen vereinbart haben, wer, mit wem, wann und was:
Präsentation der Produktbesitzer
Im weiteren Verlauf der Präsentation zeigen die Produktbesitzer die Ergebnisse ihrer Teams:
Der einzige, der derzeit versucht, die Funktionsweise des End-to-End-Szenarios im Gehirn festzuhalten, ist das Geschäft. Fragen an den Product Owner zu Beginn des Typs: „Welches End-to-End-Szenario funktioniert?“ - bleiben häufig unbeantwortet: „Warten Sie, wir sind für diese Komponente verantwortlich. Es wird für uns funktionieren, Ihre Frage ist nicht für uns. Kugeln flogen von unserer Seite, suchen Sie in anderen Teams nach der Antwort auf Ihre Frage. " Zu Beginn versteht das Unternehmen nichts, aber es versucht, dieses Bild in seinem Kopf zusammenzukleben.
Externe Abhängigkeiten
Xsolla hat die vorletzte Linie von Tech Ops. Die Jungs verstehen bereits, dass es notwendig ist, sich an DevOps zu beteiligen, um die Unterstützung der Umgebungen innerhalb der Teams zu bringen. Aber zu dieser Zeit (vor sechs Monaten) war es eine externe Einheit. Der Betriebsleiter stellte ebenfalls vor - er ging über die roten Aufkleber und bestätigte: „Ja, Sie haben mich hierher geschubst, dass wir solche und solche Umgebungen bereitstellen müssen. Ich übernehme Verantwortung, wir werden es tun ":
Es ist interessant, dass sein Team korrigierte, als er auf einem Aufkleber sagte, was sie tun würden:
- Warte, Alter, wir haben dich das nicht gefragt, sondern etwas anderes. Ich habs?
- Ich habs.
- Wirst Du es machen?
- Ich werde es tun.
- IN ORDNUNG.
Sie hatten ein Problem mit Anwälten, Marketing und Designern - diese Leute waren in Amerika (in Los Angeles) und kamen nicht zu diesem Treffen. Daher wurden die Abhängigkeiten von ihnen aufgehängt, aber es gab Angst: Vielleicht werden sie es tun, aber Sie müssen separat anrufen, kommunizieren usw. Die Schlussfolgerung für dieses Unternehmen war, dass sie sie auch zur nächsten vierteljährlichen Planung einladen.
Risikobehandlung
Es gibt einen bestimmten Algorithmus für den Umgang mit Risiken. Schlüsselidee: Wir schaffen eine Umgebung, in der das Top-Management Aufgaben festlegen kann. Und es ist nicht einmal beängstigend, sie sind bereit, sie zu nehmen. Sie sehen so aus: „Wenn ich hier den Vertrag mit unseren Outsourcern abschließe, stellt sich heraus, dass wir mehr von dem tun können, was ich will.“ Und so engagieren sie sich.
Dies sind Beispiele für Problemlösungen, die akzeptiert werden können, wenn Sie alles in dieser Besprechung haben:
Fingerabstimmung
Der letzte Schritt besteht darin, zu überprüfen, ob die Teams wirklich bereit sind, Verantwortung für die von ihnen entwickelten Ziele zu übernehmen. Wir bitten Sie, Ihre Finger zu heben:
- 5 Finger - gerade, sehr zuversichtlich in ihren Zielen;
- 1 Finger - mit Zielen im Allgemeinen ist es eine Katastrophe, sie müssen erneuert werden.
Sie sehen das Gesamtbild und wenn Sie ein geringes Vertrauen in das Unternehmen sehen, bitten Sie sie, sich umzuschauen: „Schauen Sie, es scheint, dass Sie selbst nicht an Ihre Ziele glauben. Mach es noch einmal, mach es so, dass du selbst an deine Pläne glaubst. Niemand drückt sie in dich hinein (zumindest versuchen sie es) ":
Gemeinsame retrospektive Quartalsende: OKR-Überprüfung (Inspect & Adapt)
Am Ende des Quartals bringen wir alle wieder zusammen. Tatsächlich ist dies eine große Retrospektive (in OKR OKR Review genannt):
Ich werde Ihnen anhand eines realen Beispiels zeigen, was dort passiert. Die Ziele, die das Team für dieses Quartal erreicht hat, sind ausgeschrieben. Sie haben eine geplante Bewertung der Auswirkungen auf Metriken, dh auf die Ziele, die das Unternehmen vom Team und vom Unternehmen wollte. Die tatsächliche Leistung wird bewertet:
Hier noch einmal: Wissen Sie, wie Sie die Plan-Tatsache nicht nur als "Es scheint uns, dass diese Funktion wahrscheinlich beeinflusst hat" bewerten, sondern auch, ob die Produkte mit dem Geschäft echte Metriken aus A / B-Tests aus einigen Optionen gesammelt haben Kunden erreichen.
Eine weitere Option: Wenn das Team den Ingenieur noch nicht eingerichtet hat und nicht weiß, wie es den Kunden schnell erreichen kann, bewertet es wie bei Planning Poker nur mit den Fingern: "Es scheint uns, dass wir dieses Ziel für so viel erreicht haben":
Sie setzen sich im Wesentlichen einen Prozentsatz der Leistung: Sie können sehen, dass das Team im Quartal 88% erreicht hat. Die Idee ist, dass eine solche Metrik zeigt:
- Wie ehrgeizige Ziele setzen Sie sich mit dem Geschäft?
- Wie reibungslos Sie sie tragen können:
Am Ende gibt es eine regelmäßige Retrospektive und jedes Team arbeitet separat. Entscheidender Punkt: Häufige Probleme werden gelöst: nicht für jedes Team einzeln, sondern für diejenigen, die mehrere gleichzeitig schießen. Normalerweise haben wir das Kriterium 3+ Teams gemacht. Wenn sie ein gemeinsames Problem haben, muss es auf der Ebene der gesamten Einheit gelöst werden:
Zusammenfassung. Was ist das Problem des Führers?
Was ist die Herausforderung für uns in dieser ganzen Geschichte? Es scheint klar zu sein, was zu tun ist. Sie befinden sich jedoch im Kontext einer größeren Umgebung: andere Teams, das Unternehmen, die verstehen, für welche Teile der Customer Journey Sie sich entscheiden und für welche Kunden. Tatsächlich gibt es viele von uns, solche Leads und Team-Leads:
Was ist die Anforderung an uns auf der Skala? Was ist das Problem des Führers? Die Tatsache, dass Größe wichtig ist ... :)
Cheburashka mutierte zu einem Krokodil, um in den rauen Umgebungen großer Unternehmen besser überleben zu können. Mit anderen Worten, Sie müssen sich weiterentwickeln. Dies ist ein schmerzliches Sprichwort, aber wenn Sie sich nicht weiterentwickeln, tun es die Menschen unter Ihnen auch nicht. Und in einem riesigen Unternehmen sind die Anforderungen an die Art von Führungskraft, die Sie sein sollten, unbarmherzig. Sie müssen in der Lage sein, die Umgebung für eine große Anzahl von Teams einzurichten, dh sich um ein Vielfaches aktiver zu entwickeln.
Welche Führer überleben in Agile
Grundsätzlich müssen Sie aufhören, Personen zu verwalten. Bilden Sie Umgebungen, in denen sich Menschen selbst regieren. Hör auf, Experte zu sein, werde Verhandlungsführer.
Hier erfahren Sie, wie cool Sie sich in all diesen Bereichen entwickelt haben:
In diesem Jahr veranstalten wir die zweite TeamLead Conf in Moskau anstelle der Saint TeamLead Conf in St. Petersburg. Bereits am 16. und 17. November werden wir uns live treffen und diskutieren, was sich in dieser Zeit geändert hat. Wir sehnen uns bereits nach echten persönlichen Konferenzen. Damit Sie das Charisma des Sprechers auf der Bühne sehen und ihn dann um eine weitere Stunde im Saal bitten können. Trinken Sie eine monatliche Norm Kaffee und sehen Sie alle Team-Leads, die Sie kennen, auf einmal. Und für einen weiteren Monat danach sortieren Sie Datensätze mit Kontakten, Büchern und Schlüsselwörtern.
, , , , . : , , -, , .
. . . 2019 .