Scrum? Welches SCRUM?
Zum ersten Mal wurde der SCRUM-Ansatz (englischer
Scrum „Kampf um den Ball“) von Hirotaka Takeuchi und Ikujiro Nonaka beschrieben, die bemerkten, dass kleine Teams (5 bis 9 Personen) mit verschiedenen Spezialisten bessere Ergebnisse erzielen. Die vollständigste Beschreibung von SCRUM wurde erstmals in seinem Buch von Jeff Sutherland vorgestellt. Das Buch heißt SCRUM. Jeff begann seine Karriere als Militärpilot und absolvierte während des Vietnamkrieges mehr als hundert Einsätze. Dann beschäftigte sich Jeff mit Wissenschaft, aber die Welt wird sich an ihn als einen der Gründer von SCRUM erinnern. Das Buch beginnt mit einer echten Geschichte aus dem Leben des FBI, das Millionen von Dollar für die Entwicklung eines automatisierten Systems zur Suche und Verfolgung von Kriminellen ausgegeben hat. Das Problem war, dass die Auftragnehmer dem FBI nach Ablauf des Projekts ein völlig nicht funktionierendes Produkt zeigten. Dies bedeutete nur eines: Die amerikanischen Steuerzahler haben Millionen verschwendet. Die Situation schien hoffnungslos, bis sich die FBI-Führung der damals aufkommenden SCRUM-Projektmanagementmethode zuwandte. Diese Methode wird in der oben genannten Sprache in zugänglicher Sprache beschrieben, die übrigens ins Russische übersetzt wurde. Darüber hinaus werden in dem Artikel die wichtigsten Missverständnisse und Mythen erörtert, die Top-Manager abschrecken können, die sich entschieden haben, SCRUM in ihren Projekten zu implementieren.
1. Totale Kontrolle, die Kreativität tötet
Bei SCRUM entscheidet das Projektteam und nicht das Management, wie das Geschäftsziel erreicht werden soll. Diese Methode motiviert und stimuliert einen kreativen Ansatz im Gegensatz zum klassischen Management, bei dem den Mitarbeitern die Umsetzung spezifischer Maßnahmen auf niedriger Ebene übertragen wird und diese wiederum oft nicht einmal verstehen, warum dies so ist und wie sich dies auf das gesamte Projekt auswirkt. Daher kontrolliert das Management in SCRUM nicht die Aktionen des Projektteams und berichtet wiederum nur über die Ergebnisse am Ende jedes Sprints (ein voreingestellter Zeitraum, z. B. 2 Wochen). Transparenz besteht nur unter Mitgliedern des Projektteams. Worin manifestiert es sich? Zuallererst tägliche Stand-up-Rallyes, bei denen jedes Mitglied des Projektteams erzählt, was er gestern getan hat, was er heute tun wird, welche Probleme er hatte. Diese Vorgehensweise soll nicht den Arbeitsaufwand jedes Mitarbeiters kontrollieren. Stand-up-Rallyes sollen jedem Mitglied des Teams helfen, Hindernisse in seiner Arbeit zu beseitigen und Kollegen ihren Plänen zu widmen, damit jeder versteht, wohin sich das Projekt heute bewegt, und sich seiner Rolle bei der Produktentwicklung bewusst ist. Für den gleichen Zweck dient übrigens ein gemeinsames SCRUM-Board mit Aufklebern, die jeder sehen kann, und Freiflächen, die die Hindernisse für die freie Kommunikation zwischen Teammitgliedern beseitigen.
2. SCRUM entzieht den erfahrensten Ingenieuren die Rechte, weil sie der Entscheidung des Teams gehorchen
SCRUM schafft ein Umfeld, in dem Autorität nicht durch Titel und Positionen, sondern durch Fähigkeiten und Erfahrungen erlangt wird. Ein eindrucksvolles Beispiel für die umgekehrte Situation ist die Hierarchie des Militärs, in der die Macht auf Position und Rang basiert. Ein Kapitän kann viel talentierter und gelehrter sein als ein Oberst. Trotzdem muss der Kapitän strikt gehorchen. Eine solch starre Struktur ist ideal für extreme Bedingungen wie Feindseligkeiten, bei denen Entscheidungen schnell getroffen werden müssen und ihre Diskussion zu Verzögerungen führt, die zum Tod von Menschen führen. SCRUM storniert keine Titel. Jeder Mitarbeiter hat seine eigene Position entsprechend seiner Erfahrung und Kompetenzmatrix. Bei der Erörterung einer bestimmten Entscheidung ist jedoch eine klare und vernünftige Position der dominierende Faktor, die durch die persönlichen Erfahrungen des Mitarbeiters in dem betreffenden Bereich und nicht durch seinen Titel gestützt wird. Im Gegensatz zum Mythos gibt SCRUM genau jenen Teammitgliedern Macht, die fundierte Ideen klar artikulieren. Und wie Sie wissen - wer klar denkt, formuliert klar.
3. SCRUM zielt auf kurzfristige Geschäftswerte ab und nicht auf die langfristige Entwicklung des Projekts
Dieses Problem ist in der Tat relevant. Zum Glück die Frage "Was tun?" Es gibt Antworten. Es sollte mit der Tatsache beginnen, dass dieses Problem höchstwahrscheinlich nicht auftritt, wenn das Projekt nicht langwierig ist und nicht länger als sechs Monate dauert. Eine andere Sache ist, wenn Software 2-3 Jahre oder länger entwickelt. Es gibt viele Artikel, in denen Autoren ihren Schmerz in Bezug auf solche Projekte ausschütten. Die Armee von Juni und Mitte (Synergien sind, wie Sie wissen, teuer und nur wenige von ihnen) setzt alles daran, ihre Arbeit zu meistern, und der Kundensprint erzielt Sprint für Sprint brillante Ergebnisse. Das Problem ist jedoch, dass das Hinzufügen neuer Funktionen nach 5 bis 10 Sprints problematisch wird und je weiter, desto schwieriger. Daher ist SCRUM gut, aber Sie müssen über Strategie und Architektur nachdenken. Eine ähnliche Situation kann verhindert werden. Erstens werden
mindestens 1-2 so viele erfahrene Ingenieure wie möglich an dem Projekt arbeiten, die während der Codeüberprüfung alle Commits an das Repository weiterleiten. Zweitens, um viel Zeit für die Schulung (mindestens 3 Stunden pro Woche) von Nachwuchs- und Mittelingenieuren in Softwarearchitektur, Entwurfsmustern und deren Anwendung auf ein bestehendes Projekt aufzuwenden. Solche Klassen sollten von Übung und minimalen Hausaufgaben zum besseren Lernen begleitet werden. Praktische Aufgaben können in den Rückstand von Projektsprints eingebettet werden. Dies wird die Rentabilität des Projekts nicht wesentlich beeinträchtigen, aber den Prozess des Mitarbeiterwachstums beschleunigen und potenzielle Probleme mit der Softwarearchitektur verhindern. Durch regelmäßige Meetups können Projektteams voneinander lernen, was die Qualität der produzierten Software nicht beeinträchtigt.
4. SCRUM verhindert, dass sich Ingenieure entwickeln
SCRUM geht davon aus, dass alle Entscheidungen zur Erreichung der Geschäftsziele an das Team delegiert werden. Der Product Owner entscheidet, was zu tun ist, und das Team entscheidet, wie. Daraus folgt, dass das Team kompetent genug sein muss, um effektive Entscheidungen zu treffen. Daher ist das Training der Eckpfeiler der SCRUM-Methodik. Deshalb wird in allen größten Banken und IT-Outsourcern der Entwicklung so viel Aufmerksamkeit geschenkt: Schulungen, Seminare, Kurse. Das berufliche Wachstum der Mitarbeiter ist ein wesentlicher Bestandteil von SCRUM. Aufgrund der Tatsache, dass SCRUM-Teams relativ klein sind, müssen die Teammitglieder den gesamten Technologie-Stack innerhalb des Projekts beherrschen, an dem sie arbeiten. Am Ende des Projekts erhält der Ingenieur neue Fähigkeiten, was seinen Wert auf dem Arbeitsmarkt erhöht.
Zwischensumme
SCRUM hat wie jede andere Projektmanagementmethode seine eigenen Eigenschaften und Rauheiten, die bekannt sein und berücksichtigt werden müssen. Trotzdem liefert es das beste Ergebnis unter den heute bekannten Methoden.
1. Jeff Sutherland // SCRUM 2017.