SCRUM ist so populär geworden, dass sie jetzt versuchen, es fast überall umzusetzen. In großen Unternehmen stellt sich manchmal heraus, dass SCRUM zum Zwecke der Berichterstattung oder um „progressiv“ und „modisch“ zu sein, implementiert wird. Infolgedessen setzte die Situation, die wie ein verantwortungsbewusster Manager zu sein scheint, das nächste Häkchen, sie sagten, es sei notwendig, die Methodik zu implementieren - implementiert, gut gemacht, aber anstelle einiger qualitativer Verbesserungen erscheint das sogenannte „Zombie SCRUM“ auf der Ausgabe. Dies ist der Zeitpunkt, an dem das Framework formal implementiert wird, aber niemand normal daran arbeitet. Daher der Name.
Mein Name ist Oleg Egorkin, ich bin ein agiler Coach in Rostelecom, und in diesem Beitrag werde ich erklären, warum „Zombie-Scrum“ im Allgemeinen auftritt, wie man dies vermeidet und wie man sicherstellt, dass alles bereit ist, damit das Unternehmen ein Scrum-Team gründen kann.
Bestehende Ansätze zum Ausführen von Befehlen
Manchmal versuchen sie, ein Scrum-Team in der IT zu gründen, dh von unten nach oben. Dann verstehen die Entwickler selbst und die Abteilungsleiter, dass es Zeit ist, für dieses Produkt brauchen wir eine Narbe. Das Plus ist, dass die Initiative von den Personen in dem Thema kommt. Minus - bei diesem Ansatz ist das Geschäft nicht beteiligt. Und wenn das Unternehmen nicht involviert ist, ändert sich die Organisationsstruktur selbst bei diesem Ansatz entweder geringfügig oder (häufiger) überhaupt nicht. Infolgedessen ist die Wahrscheinlichkeit, dass aus einem solchen Scrum ein „Zombie-Scrum“ wird, sehr hoch. Natürlich wird es nicht so sein, dass am ersten Tag alles schief geht, wie man es gerne hätte. Aber nach ungefähr sechs Monaten werden die Leute feststellen, dass alle Minuspunkte, die beim Start waren, nirgendwo hingegangen sind. Daher die Frustration, die das Produkt immer traurig betrifft.
Es gibt eine umgekehrte Geschichte - von oben nach unten. Auch nicht das, wonach man streben sollte. Denken Sie beispielsweise daran, dass vor einigen Jahren, zu Beginn von Agile, 50 neue Teams in einer grünen Bank auf Anweisung der hohen Behörden „bis zum Sommer“ und bis Ende des Jahres - 5000 - gestartet wurden. Dies ist genau der Ansatz, um Scrum zu betreiben. Was passiert in diesem Fall? Die Leute beeilen sich, Besorgungen zu machen. Unter dem Bildschirm beginnt alles, was nicht verschraubt ist, zu rudern. Scrum in dieser Geschichte ist niemals eine Verbesserung der Entwicklung und neue Methoden, sondern nur ein Häkchen im KPI des Managers. Das Ergebnis ist ein "Zombie-Scrum".
Und es gibt einen dritten Ansatz: Die Initiative ist oben und unten codirektional. Wir hatten Glück und gerade in Rostelecom. Eine Sache in was. Auf der obersten Führungsebene werden alle Transformationsansätze in Teams ständig unterstützt. Gleichzeitig stellt niemand „ehrgeizige“ Pläne auf.
Für große und sehr große Unternehmen ist dies nicht ganz bekannt. Es funktioniert ungefähr so: Einmal im Monat gebe ich eine eintägige Grundausbildung in Agile. Sowohl IT-Mitarbeiter als auch Geschäftsleute kommen zu den Schulungen, 25 Personen in der Gruppe. Ich versuche so weit wie möglich und weit darüber zu sprechen. Nach einiger Zeit (es kann von einer Woche bis zu mehreren Monaten dauern) kommen Kollegen, die das gewonnene Wissen verdauen, mit der klaren Bitte zurück, ein Scrum-Team zu bilden.
Über die Checkliste
Es gibt zwei Arten von Anfragen für mich - entweder ein Team im Rahmen der Transformation eines vorhandenen Produkts zu gründen oder ein Team für ein neues Produkt. Um diese Anfragen zu bearbeiten, habe ich eine spezielle Checkliste geschrieben, mit deren Hilfe ich alle für die Ausführung erforderlichen Bedingungen überprüfe. Wenn die Bewerbung keinen Punkt durchläuft und die vorläufigen Anforderungen nicht erfüllt, führen wir das Team nicht. Dies ist eine anerkannte Notwendigkeit. Wenn Sie offen gesagt mindestens einen der Punkte erzielen und das Team ohne diesen Punkt führen, bringt dies immer noch keine Ergebnisse. Nun, abgesehen von der Tatsache, dass nicht schwach alle Teilnehmer demotiviert.
Wenn jemand aus der IT mit einer Bewerbung zu mir kommt, bitte ich ihn, mit dem Unternehmen zu sprechen und wieder zusammenzukommen. Weil das Geschäft bei Agile eine Schlüsselkomponente ist. Von hier aus haben wir den ersten Checklistenpunkt:
1. Ein agiles Team sollte ein Unternehmen gründen wollen
Hier, wie bei Vampiren - sie können das Haus nicht einfach nehmen und betreten, sie müssen eingeladen werden. Bei agilen Trainern dasselbe in dem Sinne, dass eine Änderung angefordert werden muss.
Menschen aus der Wirtschaft und der IT bemerken, dass einige Produkte unter schwierigen Marktbedingungen funktionieren. Sie setzen sich selbst mit mir in Verbindung und sagen: Der Ansatz muss geändert werden. Und hier, wenn Sie sehr viel Glück haben, kommt die Anfrage überhaupt am Anfang an, wenn es noch kein Team gibt, aber es gibt eine Idee, unter der sich Menschen versammeln können. Gleichzeitig versteht jeder, dass keine eindeutige Spezifikation für das Produkt erstellt werden kann, die sich je nach Geschäftsmodell ändert und nicht klar ist, welches Modell funktioniert und welches nicht.
Im Allgemeinen ist es sehr wichtig, dass das Unternehmen beteiligt ist.
Es ist auch wichtig, dass der Treiber dieses Engagements etwas Greifbares ist und nicht nur ein Hype. Daher überprüfe ich, ob die Motive des Geschäfts grob in die folgenden fallen:
- Verkürzung der Markteinführungszeit, wenn dieser Indikator zu groß ist;
- Steigerung der Effizienz der Teamarbeit;
- Verbesserung der Verwaltbarkeit angesichts sich ändernder Prioritäten.
Wenn einer dieser drei Punkte stimmt, ist alles in Ordnung. Dies ist ein sicheres Zeichen dafür, dass das Team mit angemessenen Erwartungen beginnt.
2. Zum Start muss ein Produkt vorhanden sein
Erstens ist dies logisch. Es ist albern, ein Produktteam für ein Produkt zu leiten, wenn Sie kein Produkt haben. Und es spielt keine Rolle, was wir alle damit anfangen - um ein Produkt oder eine Dienstleistung herum.
3. Der Eigentümer des Produkts muss eine Vision und einen Fahrplan für die Entwicklung haben
Darüber hinaus ist die Roadmap für ein Jahr im Voraus ein Minimum in Form eines Verständnisses auf höchster Ebene darüber, was im Allgemeinen getan werden muss. Selbst wenn eine Person 3-5 Hypothesen darüber hat, welche Geschäftsmodelle sie anwenden wird, was sie untersuchen möchte. Wenn ich sehe, dass es eine Roadmap gibt, fahren Sie fort.
4. Unternehmen müssen Geld haben
Das Budget für ein funktionsübergreifendes Team. Weil ein Produkt für ein Vollzeitprodukt gemietet werden muss und das Unternehmen bereit sein sollte, es etwa ein Jahr im Voraus am Horizont zu bezahlen. Ich stelle sicher, dass dies alles erledigt ist. Ich schaue mir an, welches Finanzverantwortungszentrum daran beteiligt ist, damit es nicht klappt, dass es eine Idee gibt, dass der Wunsch besteht, ein Team zu gründen, aber es gibt kein Geld.
5. Muss der Product Owner im Geschäft sein
Der Besitzer. Nicht die Besitzer. Ein Besitzer.
Eine Person, die sich zu 100% diesem bestimmten Produkt widmet. Es gab einen Fall, in dem zwei Manager kamen und sagten: Wir wollen ein Motivations- und Bildungsprodukt schaffen (so etwas Internes für die Mitarbeiter). Ich sage es ihnen - großartig, aber haben Sie einen Produktbesitzer? Sie antworten - ja, natürlich ist ein Besitzer des Produkts für die Schulung und der andere für die Motivation. Das Produkt ist motivierend und lehrreich.
Zu dieser Zeit bat ich darum zu überlegen, wer für das gesamte Produkt verantwortlich sein wird. Dies stellte sich als sehr schwierige Angelegenheit heraus und das Team konnte nur sechs Monate später gestartet werden.
Ein Produkt - ein Produktbesitzer. Es ist wichtig.
6. Alle Teilnehmer des Entwicklungsteams sollten ebenfalls zu 100% dem Produkt zugeordnet sein.
Wenn jemand aus dem Entwicklungsteam zu 50%, 30%, 10% arbeitet, ist dies nicht sofort der Fall. Man muss komplett im Produkt sein. Gleichzeitig benötige ich jedoch keine Anwesenheit von Teams am selben Ort. Unter unseren Bedingungen ist es eine Seltenheit, Rostelecom ist sehr groß, wir haben viele Tochtergesellschaften und verbundene Unternehmen (Tochterunternehmen), in denen die in die Teams einbezogenen Entwickler arbeiten. Und sie können über Moskau, Peter, Krasnodar und andere Städte unserer riesigen Heimat verteilt sein. Es ist manchmal schwierig und zeitaufwändig, schnell ein Team in Moskau zusammenzustellen, aber oft funktioniert es überhaupt nicht.
Daher gehe ich weiter, aber es gibt eine Gegenanforderung: Das Team muss sich für die ersten zwei Tage während des Trainings zusammenfinden und dann alle sechs Monate, um persönliche Kontakte zu pflegen und aktuelle Themen zu besprechen.
7. Produktzahlungsmethode
Dies ist auch eine wichtige Sache, sowie eine Menge, die mit Geld verbunden ist. Wenn der Eigentümer des Produkts ein Budget hat, wird es auf Anfrage ausgegeben. Das heißt, TK wird auf den Auftrag geschrieben, eine Bewertung für seine Umsetzung durchgeführt und dann werden Mittel im Budget für diesen Fall zugewiesen. Das klingt einfach. Aber es gibt Nuancen.
Wenn Sie zu Sonderanfertigungen wechseln, sollten am Ende der Ausführung von Aufträgen Verfahren für die Annahme und Übergabe des Produkts an den Betrieb vorhanden sein. Und da TK bereits genehmigt wurde, ist es äußerst schwierig, Änderungen daran vorzunehmen. Änderungen müssen neu ausgehandelt und genehmigt werden. Dies ist ein sehr komplexer und langsamer Prozess, der nicht mit einer schnellen Reaktion auf Änderungen vereinbar ist.
Was haben wir getan, um uns nicht darin zu vergraben und nicht verrückt zu werden?
Sie können an Time & Materials arbeiten, wenn ein Vertrag abgeschlossen und die Zeit des gesamten Teams bezahlt ist. Das heißt, es gibt ein Team, das für den Eigentümer des Produkts arbeitet. Ihre Leistungen werden monatlich oder vierteljährlich bezahlt. In unserem Land kann dies jedoch nicht in seiner reinen Form geschehen, da es bürokratische Beschränkungen gibt.
Aus diesem Grund haben wir begonnen, im Rahmen der kundenspezifischen Entwicklung auf der Ebene vierteljährlicher Bestellungen mit der Festlegung von Roadmaps (nicht TK) zu arbeiten, während in der Bestellung nicht detailliert beschrieben wird, wie die Roadmap implementiert wird. Der Product Owner hat die Flexibilität, Rückstände zu generieren. Und wenn das Quartal endet, entladen wir eine Liste der erledigten Aufgaben von der Diät und bilden auf dieser Grundlage Gesetze, die unterzeichnet und bezahlt werden. Es stellt sich heraus, die gleiche Zeit & Material.
Und hier ist es nicht notwendig, TK eindeutig einzuhalten, da es keine TK gibt. Anforderungen, die nach dem Testen von Hypothesen nicht mehr sinnvoll sind, können einfach nicht gestellt werden.
8. Das Team sollte keinen KPI haben, außer den mit dem Produkt verbundenen
Dies ist gerade deshalb wichtig, weil die Entwickler von Tochterunternehmen eingestellt werden, bei denen KPIs für die Einrichtung des Recyclings verwendet werden (in diesem Fall muss der Entwickler ständig mit etwas beschäftigt sein). Tatsächlich arbeiten fast alle Integratoren so - unter den Bedingungen eines Mangels an einem Projekt (oder konkurrierenden Projekten) desselben Entwicklers malen sie mehrere Projekte. Und damit das Unternehmen schwarze Zahlen schreibt, setzen sie den Entwickler in den KPI, dass er immer zu mindestens 85% beschäftigt sein sollte. Das heißt, er hat tatsächlich einen bestimmten KPI, der ihn motiviert, in die maximale Anzahl von Projekten zu passen, um seine Entsorgung auf die erforderlichen Zahlen abzustimmen.
Glücklicherweise hat das Scrum-Team keinen solchen Bedarf (de facto sind es 100%). Ich stelle sicher, dass die Teams außer dem Lebensmittelgeschäft keine anderen KPIs haben.
Insgesamt
Das ist meine Checkliste. Demnach überprüfe ich alle Teams, bevor ich anfange, und da wir einen Co-Directional-Ansatz verfolgen, kann ich eine Änderung der Bedingungen verlangen, wenn das Team nicht mindestens einen dieser Punkte durchläuft. Daher sind die Ergebnisse nur diejenigen Teams, die bereit sind, die Werte des agilen Ansatzes umzusetzen.
Wenn die Bewerbung für das Team alle diese Punkte durchläuft, beginnt die nächste Phase - Training und Start des Teams.
Worüber ich im nächsten Beitrag sprechen werde =)