Scrum für Spezialistenteams

Scrum eignet sich am besten für Teams mit Generalistenmitgliedern, dh Teams, in denen mindestens 2 Personen die gleichen Aufgaben ausführen können. Mein Hauptanliegen ist es, gute Lösungen zu finden , um Scrum (was zu behalten, was zu entfernen, was zu verbessern) für Teams aus Spezialisten anzupassen?

Angenommen, Sie haben ein Team von 5 Entwicklern (nicht real, nur für das Beispiel):

1. Ein Mathematiker mit starken Fähigkeiten in C;
2. Ein DB-Entwickler;
3. Ein Webentwickler;
4. Ein UX / GUI-Entwickler;
5. Ein Software-Architekt;

Hier sind alle Spezialisten und niemand kann jemand anderen ersetzen (die Risiken beim Aufbau eines solchen Teams sind mir egal, ich möchte mich auf Scrum konzentrieren). In einem Scrum-Kontext sind hier meine Gedanken:

1. Nutzlose Frühlingsplanungen: Wenn der Mathematiker sagt, dass eine bestimmte Aufgabe 2 Punkte wert ist, kann niemand gegen ihn stimmen.
2. Nutzlose Teamgeschwindigkeitsmetrik: Da jeder seinen eigenen Aufgaben eine beliebige Anzahl von Punkten zuweisen kann, ist die Berechnung der Geschwindigkeit nicht sinnvoll.
3. Ersetzen Sie tägliche Scrum-Meetings durch wöchentliche (längere) Scrum-Meetings: Da jedes Mitglied des Teams an seinen eigenen Aufgaben arbeitet, sollten tägliche Scrum-Meetings wirklich wichtig sein, um einen "Teamgeist" zu bewahren. Tägliche Scrum-Meetings sollen jedoch etwa 15 Minuten dauern. Dies reicht eindeutig nicht aus, um zu verstehen, was die anderen tun und tun werden. Darüber hinaus wird der Mathematiker die meiste Zeit die gleichen Fragen beantworten: "Ich mache immer noch % & Lo (+? $$ + &)" ... Wöchentliche Treffen würden mehr Zeit geben. Um die gleiche Besprechungszeit zwischen "anfänglichen" Scrum-Besprechungen und "wöchentlichen" Scrum-Besprechungen einzuhalten, sollte jede wöchentliche Scrum-Besprechung dauern (5 Tage die Woche, mit 4-wöchigen Sprints, mit 4-stündigen Sprint-Besprechungen und 15-minütigen täglichen Besprechungen): (4 * 60 + 20 * 15) / 4 =>

Oder ist Scrum noch verwendbar? Vielleicht sollte eine andere agile Technik verwendet werden?

Scrum ist keine Silberkugel. Nicht jedes Projekt muss Scrum verwenden, um erfolgreich zu sein. Die Situation, die Sie beschreiben, scheint jedoch gut zu Lean / Kanban zu passen. Vielleicht möchten Sie es ausprobieren.

Kanban fordert Sie grundsätzlich auf, nur ein paar Dinge zu tun, von denen keines im Widerspruch zu der Art von Team steht, die Sie beschreiben:

• Visualisieren Sie den Wertefluss, dh das Kanban-Board. Das Scrum-Board ist eine spezielle Anwendung eines Kanban-Boards. Es ist möglich, es anzupassen, um eine Spezialisierung zu ermöglichen.
• Begrenzen Sie den Work in Progress (WIP) so, dass der dem Team zugewiesene Arbeitsaufwand gerade ausreicht, um den Arbeitsfluss konstant zu halten - dh keine "Blockierung" am Anfang des Streams (Design) oder am Ende (Bereitstellung) .

Vielleicht möchten Sie einige Referenzen über Kanban lesen:

• Eines Tages im Kanban Land
• Priming Kanban (kostenloses E-Book)

Sie konzentrieren sich ein bisschen zu sehr auf die Mechanik von Scrum / Agile, ohne zu sehen, was Agile liefern soll. Sie sagen, wenn der Mathematiker 2 Punkte schätzt, kann niemand sagen, dass er falsch liegt. Das ist nicht das Ziel. Ziel ist es, eine erreichbare Reihe von Zielen für den bevorstehenden Sprint zu vereinbaren. Als Experte für diese Aufgabe weiß er am besten, wie lange es dauern wird.

"Und wenn er lügt oder es einfach falsch macht?" du sagst. Nach meiner Erfahrung schätzen die Leute mehr, weil sie befürchten, erschossen zu werden, weil sie eine genaue Vermutung abgeben. Andere, die geschätzt werden, fügen dann eine Sicherheitsmarge hinzu, die alles ausgleicht, und die eine oder andere faule Person wird die Schätzung überschätzen, damit sie sich nicht beeilen muss. Von den dreien wird der erste auf der Geschwindigkeitsverfolgung erfasst, der zweite klingt falsch und der dritte ist etwas, mit dem Sie sich außerhalb des Gedränge befassen müssen.

Das tägliche Treffen bietet weiterhin Vorteile. Es gibt Abhängigkeiten zwischen Teammitgliedern, auch wenn sie jeweils Spezialisten sind. Der Benutzer der Benutzeroberfläche wartet möglicherweise auf den Server, um einen Benachrichtigungsfehler zu beheben. Der Server-Typ wartet möglicherweise auf den Mathematiker, um herauszufinden, warum eine Berechnung falsch ist. Es geht auch nicht nur darum, wie sich ihre Arbeit auf Sie auswirkt. Wenn ein Teammitglied aufgrund von "Grund X" ständig verzögert wird, sich aber keine Zeit genommen hat, um zukünftige "Grund X" -Ereignisse zu mildern, kann dies in Frage gestellt werden.

Wenn Sie einen Spezialisten mit Qualifikationen wie den von Ihnen beschriebenen haben, ist Ihre Annahme, dass jeder an seiner eigenen Aufgabe arbeitet und selten mit den anderen kommunizieren muss, meiner Meinung nach falsch. Um eine neue Funktion (eine "User Story") zu realisieren, müssen Sie dies häufig tun

• Ändern Sie Ihre Datenbank
• Hinzufügen oder Ändern der GUI oder der Weboberfläche
• Kombinieren Sie dies mit der richtigen Geschäftslogik (wo vielleicht Ihr "Mathematiker" hereinkommt)
• Stellen Sie sicher, dass all diese Änderungen gut zusammenarbeiten

Ich denke, sie müssen viel mehr kommunizieren als in einem Team von Generalisten, in dem jeder an einer anderen Anwendung / User Story arbeiten und alle notwendigen Änderungen an allen Anwendungsebenen selbst vornehmen kann. Daher sind alle oben aufgeführten Teamaktivitäten von Scrum für ein solches Team sehr sinnvoll.

Scrum ist sicherlich immer noch für Ihre Situation geeignet, aber auch andere Frameworks.

Um neue Funktionen bereitzustellen, benötigen Sie wahrscheinlich alle oder viele dieser Fähigkeiten. Damit das Team Entscheidungen treffen kann, die sich gegenseitig beeinflussen und zusammenarbeiten, muss es kommunizieren. Je länger die Zeit zwischen den Scrum-Meetings ist, desto länger kann ein negativer Plan das Team verirren. Durch tägliche Treffen kann das Team diese Situationen schnell angehen und einen neuen Plan erstellen.

Ich möchte einige spezifische Themen ansprechen, die Sie ebenfalls ansprechen:

Funktionsübergreifende Teams Ein Team wird als funktionsübergreifend angesehen, wenn es über alle erforderlichen Fähigkeiten verfügt, um ein Sprintziel und / oder einen Produktrückstand zu erreichen. Dies bedeutet nicht , dass es für jeden Job 2 Personen gibt.

Sizing Es ist wichtig , sich daran zu erinnern , dass wir ein geschäftliches Problem oder Notwendigkeit sind Schlichten, nicht eine Lösung oder ein Teil einer Lösung. Zum Beispiel ist die Integration von Social Media / Twitter in unsere E-Commerce-Website ein Problem, das UX, UI-Design, Programmierung, Datenbank und Kenntnisse der Twitter-API erfordert. Ein Team sollte dies als Einheit dimensionieren, da es als Team diese Funktionalität bereitstellen wird. Diese Größe wird nicht 100% genau sein, aber wir stellen fest, dass Prognosen, die auf der relativen Größe basieren, insgesamt genauer sind. Dies bedeutet, dass einige hoch und andere niedrig sind und die berechnete Prognose zusammengenommen genauer ist als die geschätzte Dauer.

Nutzlose Frühlingsplanungen Die Sprintplanung ist eine Zeit, in der Sie als Scrum-Team (Entwicklungsteam + Product Owner + Scrum Master) zusammenarbeiten müssen, um zu bestimmen, was produziert werden soll, und um einen Plan für den Beginn zu erstellen. Einige Teams werden diese ausgewählten Product Backlog-Elemente in Aufgaben aufteilen, während andere ihren eigenen Weg zum Fortschritt finden, z. B. Tests, die bestanden werden müssen (denken Sie an XP).

Dies ist eine wechselseitige Zusammenarbeit. Dem Team eine Reihe von PBIs zuzuweisen und "go" zu sagen, ist die Aufgabe eines Diktators. Das Team verhandelt mit dem Product Owner, um die Zeit im Sprint zu maximieren.

Nutzlose Team-Geschwindigkeitsmetrik Mit Teams, die Probleme und Anforderungen des Unternehmens dimensionieren, die die Architektur / das System durchschneiden, und der Erfahrung aus der Vergangenheit, aus der hervorgeht, wie viele von denen das Team in einem konsistenten Zeitrahmen (Sprint) geliefert wurde, können wir jetzt eine Teamprognose erstellen für den Rest des Rückstands.

Auch hier sind keine zwei Sprints gleich und je kleiner der von Ihnen verwendete Beispielsatz von Product Backlog-Elementen ist, desto weniger verteilt ist der Fehler bei den Schätzungen. Betrachten Sie es wie die Börse; es ist immer gestiegen, aber das bedeutet nicht, dass wir keine Jahre verloren haben. Insgesamt können Sie Geld verdienen, aber in jedem Monat, Quartal oder Jahr werden Sie falsch raten.

Ersetzen Sie tägliche Scrum-Meetings durch wöchentliche (längere) Scrum-Meetings. Das Daily Scrum bietet dem Team einen 24-Stunden-Feedback-Zyklus und die Möglichkeit, die nächsten 24 Stunden zu planen. Nicht mehr, nicht weniger. Die "Drei Fragen" sollen dazu beitragen, diese Bemühungen zu erleichtern.

Wenn Sie 5 Tage lang kein Feedback haben, sind Ihre Aufgaben meiner Meinung nach nicht genau genug. Dies ist einfach meine Meinung, basiert aber auf meiner Erfahrung als Trainer und Teammitglied. Die Teams sollten viel häufiger sprechen, planen und ihre Bemühungen integrieren.

Fazit Scrum soll das Lernen erleichtern und das Lernen mit der Bereitstellung in Einklang bringen (wo echtes Lernen stattfindet). Experimentieren Sie im Laufe der Zeit mit Ihren Prozessen und Werkzeugen und untersuchen Sie die Auswirkungen mit Scrum. Versuchen Sie, von täglichen zu wöchentlichen Scrums zu wechseln, und prüfen Sie, ob dies den Teams hilft oder schadet, die richtigen Funktionen bereitzustellen. Das könnte für Sie funktionieren.