Heute wird die agile Softwareentwicklung auf die meisten Projekte angewendet, und falls Ihr Team noch keine agilen Prozessrahmen verwendet hat, seien Sie darauf vorbereitet, dass Ihr Kunde eines Tages mit einem inspirierten Gesichtsausdruck zu Ihnen kommt und sagt: „Wir müssen agil sein!“ Und aus irgendeinem Grund verstehen die meisten Kunden unter „agil“ Scrum. Daher macht es zuerst Sinn, das Agile Manifest und seine 12 Prinzipien zu lesen und dann mit dem Erlernen der Grundlagen von Scrum zu beginnen.
Leider habe ich viele Fälle gesehen, in denen Scrum nicht vollständig angewendet wurde oder ein Scrum-Team nicht alle Rollen oder Artefakte hatte. In den schlimmsten Fällen führte das Scrum-Team einfach tägliche Meetings durch und nahm an, dass es Scrum verwendete. Sicherlich, wie ich oben erwähnt habe, enthält der Scrum Guide keine optionalen Komponenten, und wenn Sie Scrum teilweise anwenden, zusätzliche Rollen hinzufügen oder beispielsweise Artefakte anders beschreiben als im Scrum Guide, wird es nicht als Scrum gelten, und es könnte definitiv Ihre Effektivität beeinträchtigen. Der Scrum Guide gibt Ihnen das absolute Minimum vor, das eingehalten werden sollte. Es liegt an Ihrem Team und Ihrer Umgebung, wie Sie es anwenden, aber die Schlüsselelemente von Scrum sollten nicht verändert werden.
In diesem Artikel werde ich nicht detailliert auf die Scrum-Theorie eingehen, sondern versuchen zu beschreiben, was passieren kann, wenn Sie einige der Scrum Rollen, Artefakte oder Ereignisse ignorieren. Ich werde auch versuchen, Ratschläge für schwierige Situationen zu geben, mit denen die meisten Teams in ihren Scrum-Projekten konfrontiert sind.
Scrum Rollen
Es ist für das Scrum-Team immer wichtig zu verstehen, welche Verantwortlichkeiten und Einschränkungen die Rollen in Scrum haben. Dies führt zu vielen organisatorischen und funktionalen Problemen, wenn entweder die Rollen nur formal definiert sind oder wenn eine Rolle mit mehr Rechten handelt, als im Scrum Guide festgelegt ist.
Was ist ein Scrum Master?
Der Scrum Master sollte dem Entwicklungsteam nicht sagen, was es tun soll, sondern ihnen auf kluge Weise helfen, ihre Arbeit gemäß den Scrum-Konzepten zu skizzieren. Manchmal kommt es vor, dass ein Kunde als Product Owner in einem Projekt agiert und Scrum-Events einschränken oder auslassen möchte. Der Grund, warum viele Kunden so denken, liegt darin, dass, wenn sie die für die Scrum-Events benötigte Zeit berechnen, diese Zahl in Geld umgewandelt wirklich groß erscheint:
d. h. Ein 2-wöchiger Sprint für ein Team von 5 Entwicklern umfasst bis zu 50 Arbeitsstunden für die Kommunikation im Zusammenhang mit den Scrum-Events:
(10 Tage * 15 Minuten des Daily Scrum + 4 Stunden des Sprint-Plannings + 2 Stunden des Sprint-Reviews + 1,5 Stunden der Sprint-Retrospektive) * 5 Entwickler.
Der Scrum Master sollte sorgfältig die Bedeutung aller Scrum-Events und anderer Komponenten erklären, damit jeder ihre Wichtigkeit und Auswirkungen des Ausschlusses einiger verstehen kann. Normalerweise wird das Team umso weniger produktiv, je mehr Scrum-Komponenten ausgeschlossen werden, was zu höheren Kosten führt. Wählen Sie den Scrum Master des Teams sorgfältig aus; es sollte eine proaktive Person mit fundierten Kenntnissen der Scrum-Konzepte sein, damit er schnell auf Hindernisse reagieren kann. Auf der anderen Seite sollte er eine geduldige und taktvolle Person sein, die mit dem Product Owner und anderen Teammitgliedern zusammenarbeitet, um sie zu coachen und ihnen die Scrum-Konzepte zu erklären.
Eine weitere wichtige Rolle im Scrum-Team ist der Product Owner. Da der Product Owner in den meisten Fällen selbst ein Kunde ist oder jemand auf der Seite des Kunden, zeigt es sich oft, dass das Team nicht genug Aufmerksamkeit vom Product Owner bekommt: Kunden sind normalerweise beschäftigt und haben möglicherweise nicht genug Zeit, um Benutzerstorys im Detail zu erklären, an Events teilzunehmen oder das Product Backlog zu pflegen.
Die gravierendste Konsequenz eines solchen Verhaltens ist, dass das Team die Entwicklung nicht effektiv vorantreiben kann und der Wert, den das Team produziert, aufgrund unzureichender Details von Benutzerstorys nicht optimiert ist. Das Team versucht, die Lücken basierend auf Vermutungen zu füllen, die möglicherweise weit von den Geschäftsanforderungen oder den Bedürfnissen der Benutzer entfernt sind. Unvollständige Informationen über Ziele und Anforderungen lenken das Team während des Sprints in die falsche Richtung, was wiederum zu falschen Schätzungen, hohen Kosten und unterschiedlichen Erwartungen führt. Wenn der Product Owner und das Entwicklungsteam nicht auf derselben Seite in Bezug auf die erwarteten Ergebnisse sind, kann dies auch nach Abschluss der Arbeit zu Konflikten führen, insbesondere wenn der Product Owner das Team verantwortlich macht, wenn das Problem entdeckt wird.
Falls der Scrum Master sieht, dass solche Dinge passieren könnten, sollte er dem Product Owner helfen, indem er erklärt, dass die Zeit, die mit dem Team verbracht wird, zu maximiertem Wert bei der Entwicklung führt. Es macht auch Sinn, wenn der Scrum Master etwas Zeit mit dem Product Owner verbringt und ihm dabei hilft, das Product Backlog zu ordnen, einige Benutzerstorys zu schreiben und zu überwachen, wie der Product Owner mit dem Team kommuniziert. Manchmal kann der Product Owner versuchen, jeden Schritt zu kontrollieren, den das Team unternimmt. In diesem Fall sollte der Scrum Master dem Product Owner die Einschränkungen seiner Rolle erklären, und dies kann etwas schwierig sein, wenn der Product Owner Ihr Kunde ist, der die Entwicklung bezahlt.
Der Scrum Master sollte darauf hinweisen, dass diese Einschränkungen berücksichtigt wurden, um sicherzustellen, dass das Team erfahren ist und einige Freiheiten bei technischen Entscheidungen hat. Das Entwicklungsteam ist selbstorganisiert, sodass die Teammitglieder entscheiden, wie sie Product-Backlog-Elemente in einen Inkrement umsetzen, was ihre Arbeit effektiver macht. Natürlich sollte das Entwicklungsteam seinen Plan mit dem Product Owner teilen, damit der Product Owner Ratschläge zu zukünftigen Möglichkeiten geben kann, unter Berücksichtigung seines Geschäftsplans und Budgets. Im schlimmsten Fall, wenn der Product Owner zu beschäftigt ist, um genug Zeit mit dem Team zu verbringen, macht es Sinn, eine zusätzliche Person zuzuweisen, die das gesamte Geschäftswissen über das Produkt hat. Diese Person wird der neue Product Owner, aber es ist wichtig sicherzustellen, dass der Kunde und alle Interessengruppen die Entscheidungen dieser Person respektieren.
Events
Jeder Scrum Sprint beginnt mit der Sprint-Planung, und manchmal möchte das Team Zeit sparen und ignoriert dieses Ereignis in der Annahme, dass sie einfach die ersten N Elemente aus dem Product Backlog basierend auf ihrer Geschwindigkeit auswählen können und der Product Owner sie genehmigen kann. Das mag tatsächlich für bestimmte Teams funktionieren, insbesondere für Teams, die sich in unterschiedlichen Zeitzonen mit ihren Product Ownern befinden. Dies kann funktionieren, bis sie auf das erste Problem mit der Synchronisation stoßen: Wenn das Team diesen Weg wählt, haben sie keine Möglichkeit, das Sprint-Ziel zu diskutieren, zusätzliche Fragen zu den Geschäftsanforderungen zu stellen, um eine geeignete Umsetzung zu wählen, und sicherzustellen, dass sie mit ihrem Product Owner in Bezug auf das erwartete Inkrement auf derselben Seite sind.
Manchmal, wenn der Product Owner eine technische Person ist, kann er sogar für das Entwicklungsteam entscheiden, welche Product Backlog-Elemente während des Sprints erledigt werden sollen. Dies führt oft zu falschen Schätzungen, großem Zeitdruck im Projekt und der Ansammlung von technischem Schulden. Der Scrum Master sollte die Bedeutung der Durchführung der Sprint-Planung erklären, das Team über die Techniken informieren, die es verwenden kann, um sie effektiver durchzuführen (z. B. Planning Poker), und den Teilnehmern helfen, sich auf dieses Ereignis vorzubereiten: Der Product Owner sollte das Product Backlog aktualisieren und seine Elemente priorisieren, das Entwicklungsteam sollte einige Zeit für neue Product Backlog-Elemente aufwenden, überlegen, welche Fragen während der Sprint-Planung gestellt werden könnten, und sich an ihre vorherigen Schätzungen und vergangene Leistungen erinnern. Am Ende der Planung macht es Sinn, zu überprüfen, ob alle in Bezug auf die erwarteten Ergebnisse und das Projektziel auf derselben Seite sind. Es ist gut, wenn Sie das Sprint-Ziel und andere Notizen an einem gemeinsamen Ort wie Confluence speichern, damit Sie später darauf zurückgreifen können.
Daily Scrum
Die nächste wichtige Event ist das berühmte Daily Scrum. Viele Entwickler fragen ihre Scrum Master, warum sie 15 Minuten ihrer Morgenzeit für diese auf den ersten Blick nutzlose Routine aufwenden müssen. Solche Gedanken kommen oft Menschen in den Sinn, die ihr Daily Scrum remote an ihren Arbeitsplätzen durchführen, sodass sie parallel programmieren, Nachrichten lesen oder sogar mit jemand anderem sprechen können. Deshalb macht es Sinn, das Daily Scrum idealerweise in einem Besprechungsraum im Stehen durchzuführen. Das Daily Scrum bietet den Teammitgliedern eine gute Gelegenheit, Probleme zu entdecken und ihren Fortschritt zu überprüfen. Natürlich wird jemand mit einem blockierenden Problem nicht bis zum nächsten Daily Scrum warten, sondern es sofort ansprechen. Wenn jedoch jemand an einem Problem arbeitet und es während des Daily Scrums meldet, kann jemand anders, der dieses Problem zuvor hatte, reagieren und viel Zeit sparen.
Außerdem trägt das Daily Scrum dazu bei, die Anzahl unangenehmer Überraschungen zu reduzieren, wenn ein Team ohne tägliche Meetings arbeitet und nach einer Woche feststellt, dass einige Mitglieder völlig in die falsche Richtung gegangen sind. Auch meiner Meinung nach schaffen tägliche Meetings zur gleichen Zeit morgens eine gewisse Disziplin: Sie müssen pünktlich zum Meeting erscheinen, Ihre Gedanken für einen kurzen Bericht strukturieren und heute einen Beitrag leisten, damit Sie morgen etwas Bedeutendes dem Team mitteilen können, um zu zeigen, dass Ihre Arbeit dazu beiträgt, dem Sprint-Ziel näher zu kommen. Manchmal vergessen die Menschen die 15-minütige Zeitbegrenzung und beginnen, sehr spezifische Fragen zu diskutieren. In diesem Fall sollte der Scrum Master eingreifen und erklären, dass die Teilnehmer nur die Probleme melden und diese dann nach dem Daily Scrum spezifisch mit den erforderlichen Personen besprechen können. Wenn die Leute dies häufig vergessen, können Sie das Daily Meeting auch im Stehen auf einem Bein durchführen.
Sprint Review und Sprint Retrospective
Die nächsten beiden Ereignisse, die Teams häufig auslassen, sind die Sprint Review und die Sprint Retrospective. Sprint Reviews werden normalerweise von den Product Ownern respektiert, da sie gerne die Ergebnisse eines Sprints sehen, aber sie konzentrieren sich oft zu sehr auf die Demo. In solchen Fällen werden solche Meetings normalerweise als Präsentation der Entwickler durchgeführt, die am Frontend gearbeitet haben, während die Backend-Entwickler bescheiden im Hintergrund sitzen, weil ihre Präsentation von refaktoriertem Code für die API möglicherweise nicht wirklich fesselnd aussieht und ihre Rede während solcher Meetings recht begrenzt ist. Aber die Sprint Review geht nicht nur um die Demo. Es ist eine gute Gelegenheit, Feedback zu Ihrer Software von Benutzern zu diskutieren (z. B. sinnvolle Kommentare aus App Stores zu überprüfen), neue Updates der Software von Ihren Wettbewerbern im Vergleich zu Ihrem Fortschritt zu überprüfen, wertvolle Markteinblicke vom Product Owner zu erhalten und einige Ideen zu besprechen, die eine gute Grundlage für einen kommenden Sprint sein könnten. Wenn Sie die Sprint Review verpassen, wird Ihr Team auch die Gelegenheit verpassen zu hören, dass Sie sich in die richtige Richtung bewegen, was so wichtig ist, um das Team motiviert zu halten.
Die Sprint Retrospective findet nach der Sprint Review statt, und einige Product Owner bitten darum, ein Meeting zu machen, das beide Ereignisse kombiniert. Das Scrum-Team sollte den Zweck jedes Ereignisses verstehen, damit sie nacheinander kommen können, aber sich nicht überschneiden sollten. Manchmal wird die Sprint Retrospective während einiger Sprints ausgelassen. Das ist auch keine gute Praxis, weil es ein Ereignis ist, bei dem das Team ehrliches Feedback dazu geben kann, was sie nicht mögen bezüglich des Prozesses, des Projekts oder sogar des Verhaltens einiger Teammitglieder. Manchmal verhalten sich Entwickler wie Introvertierte, sie behalten solche Feedbacks für sich und häufen nur ihre Irritation an. Wenn Sie die Sprint Retrospective einmal alle 6 Monate durchführen, können einige von ihnen nicht auf dieses Ereignis warten und werden einfach gehen. Auch wenn Sie die Sprint Retrospective in jedem Sprint durchführen, dauert es immer weniger Zeit, weil die meisten organisatorischen Probleme nach einiger Zeit behoben werden. Wenn es Ihnen gelingt, Ihre Retrospektiven rechtzeitig durchzuführen, stellen Sie sicher, dass Sie die Ergebnisse speichern, wirklich daran arbeiten, die besprochenen Punkte zu verbessern, und einige Zeit für die erneut auftretenden Probleme aufwenden. Ich empfehle die Verwendung von gängigen Techniken für die Sprint Retrospektiven wie The Mad Sad Glad, The StaStoKee, The Team Radar.
Artefakte
Normalerweise fehlen Artefakte in Bezug auf entsprechend ausgelassene Ereignisse. Manchmal, selbst wenn ein Ereignis stattgefunden hat, vergisst das Team, auf die Artefakte zu achten. Deshalb kann es ewige Elemente geben, die niemals aus dem unteren Bereich Ihres Product Backlogs auftauchen werden. Einige Teams können auch bestimmte Artefakte vollständig übersehen. Wenn das Product Backlog fehlt, arbeitet das Team jeden Sprint an einem Satz von Aufgaben, die vom Product Owner zusammengestellt wurden. In diesem Fall hat nur der Product Owner eine Vorstellung vom Ziel, das Team hat keine Möglichkeit, zukünftige Perspektiven zu verstehen und Planung sowie Schätzungen unter Berücksichtigung neuer Funktionen vorzunehmen. Auch sind die Teammitglieder in Bezug auf Ideen, die von ihrer Seite generiert werden können, sehr eingeschränkt. Der Scrum Master sollte dem Product Owner die Bedeutung der Verfeinerung des Product Backlogs und die Vorteile seiner Aktualisierung erklären. Das sollte auch ein kontinuierlicher Prozess für das Entwicklungsteam sein, da der Product Owner das Team bitten kann, die Product Backlog-Elemente gemeinsam zu überprüfen und Schätzungen hinzuzufügen.
Das Sprint Backlog wird selten ausgelassen, ist jedoch oft auf das beschränkt, was der Product Owner in seiner User Story-Beschreibung geschrieben hat. Das Scrum-Team sollte auch die Benutzerstorys in Aufgaben umwandeln, sie bei Bedarf in Unteraufgaben aufteilen, da Benutzerstorys normalerweise nur einige kurze Geschäftsanforderungen enthalten, die für die effektive Verwendung durch das Entwicklungsteam nicht ausreichen. Es macht auch Sinn, effektive Techniken zur Verfolgung des Abschlusses des Sprint Backlogs nicht zu übersehen, z. B. Burn-down- oder Burn-up-Charts, um den Fortschritt im Scrum Prozess besser zu visualisieren.. Ich bevorzuge die Verwendung von Burn-up-Charts, weil sie eine steigende Trendlinie haben, die für mich mehr mit Fortschritt verbunden ist (aber das ist ziemlich subjektiv).
Es scheint, als ob nichts wichtiger sein könnte als das Inkrement. Daran hat das gesamte Team während des gesamten Sprints gearbeitet. Aber wenn Sie Ihr Sprint Review nicht haben oder es nicht ordnungsgemäß durchführen, könnten Sie sich erst kurz vor dem eigentlichen Release Ihres Produkts um Ihr Inkrement sorgen. Außerdem könnte das Inkrement fehlen, wenn das Team das Sprint-Ziel nicht erreicht hat. Achten Sie darauf, Ihr Inkrement am Ende Ihres Sprints in einem versandfertigen Zustand zu halten, da dies der Indikator dafür ist, dass Ihr Ziel erreicht wurde, das das Team motiviert und Ihnen hilft, es bei Bedarf in die Produktion zu bringen, wenn Sie Ihr Marketing-Nischen beibehalten möchten.
Definition of Done (Definition der Fertigstellung)
Die Definition of Done wird normalerweise vorausgesetzt, aber nicht von Entwicklungsteams definiert. Normalerweise, wenn eine Organisation ihre eigene Definition of Done nicht hat, geht das Team davon aus, dass es aus Entwicklung und einigen Tests besteht. Aber das Scrum-Team ist überrascht, wenn es feststellt, dass der Product Owner auch eine kurze Dokumentation zu neuen Funktionen haben wollte, ein anderes Team, das am Projekt gearbeitet hat, kein Datenbankschema erstellt hat, was für Ihr Team wirklich wichtig ist, und einige Entwickler keine Unit-Tests hinzugefügt haben, weil sie dachten, dass sie nicht benötigt würden. Das Fehlen der Definition of Done führt zu mangelnder Transparenz und unterschiedlichen Erwartungen darüber, was als bereit zur Auslieferung betrachtet werden soll. Wenn Ihr Team bereits eine zuvor definierte Definition of Done hat, stellen Sie sicher, dass Ihr Product Owner und alle anderen Teammitglieder das gleiche Verständnis dafür teilen. Es macht Sinn, die Beschreibung Ihrer Definition of Done an einem gemeinsamen Ort zu speichern. Zum Beispiel verwenden wir Confluence dafür. Wir haben einige grundlegende Regeln der Definition of Done, die auf alle Entwickler anwendbar sind, und zusätzlich haben unsere Mobile-, Web-Frontend- und Backend-Entwickler spezifische Punkte, die für ihre Plattformen relevant sind. Die Definition of Done sollte im Verlauf des Entwicklungsprozesses überprüft und aktualisiert werden, um die Qualität Ihres Produkts zu erhöhen.
Wenn Sie gerade damit begonnen haben, Scrum-Modell für Ihre Projekte zu verwenden, sollten Sie sich vor Schwierigkeiten nicht fürchten. Das könnte am Anfang etwas kompliziert sein, aber nach einer Weile wird Ihr Team damit vertrauter, was zu einer gesteigerten Produktivität führt. Erhöhen Sie die Transparenz, führen Sie kontinuierliche Überprüfungen durch und übernehmen Sie den Prozess, indem Sie aus Ihren Fehlern lernen. Aber denken Sie immer daran, dass der größte Wert Ihrer Organisation die Menschen sind. Alle Prozessframeworks, Methodologien und Tools werden nutzlos, wenn Sie nicht in Ihre Teamkollegen investieren. Scrum setzt voraus, dass Sie ein selbstorganisiertes Team mit einem hohen technischen Niveau und Synchronisation haben. Achten Sie darauf, Beziehungen, Arbeitsatmosphäre, berufliches Wachstum und die Motivation Ihrer Teamkollegen in demselben Maße zu beachten, wie Sie darauf achten, den Scrum Prozess zu verfolgen, und Ihre Projekte werden immer erfolgreich sein.
Interessieren Sie sich für Themen rund um die Softwareentwicklung? Lesen Sie den Artikel von Elinext über Teststrategien für langfristige Projekte.
