Allzu oft beginnen Unternehmen mit der Umstellung auf agile Methoden, bevor sie wirklich verstanden haben, was darunter zu verstehen ist. In diesen Fällen wird es allmählich zu Problemen kommen und die Erwartungen bleiben unerfüllt, sodass die Mitarbeiter agile Methoden bald völlig in Frage stellen werden – wodurch es immer unwahrscheinlicher wird, dass das ursprüngliche Ziel jemals erreicht wird.
In der Tat führen agile Methoden zu produktiveren Teams und einem schnelleren Projektabschluss, aber nur, wenn sich alle auf die Spielregeln einigen können. Erfahre von Heather Fleming und Justin Riservato vom E-Commerce-Giganten Gilt, warum das Finden eines gemeinsamen Konsenses zu den agilen Prinzipien wichtiger als deren Implementierung ist.
Heather und Justin beschäftigen sich insbesondere mit den Antworten auf drei entscheidende Fragen, die jedes Team für sich beantworten sollte, bevor es agile Methoden einführt.
- "Aber wann bist du damit fertig?" Warum ist bei der Umstellung auf agile Methoden die Loslösung vom Denken in Deadlines einer der wichtigsten (und schwierigsten) Prozesse?
- "Dies hat für mich oberste Priorität, aber ich kann mich erst nächste Woche mit euch zusammensetzen." Was mache ich, wenn mein Geschäftspartner kein volles Teammitglied sein kann (oder will)?
- "Ich möchte doch einfach nur programmieren. Warum muss ich an all diesen Meetings teilnehmen?" Warum ist die Implementierung von Scrum nicht der erste Schritt bei der Umstellung auf agile Methoden?
Hier kannst du was lernen
Q&A-Runde
Heather und Justin haben ein paar der besten Fragen aus der Q&A-Runde dieser Präsentation zusammengestellt. Tauche mit ihnen tiefer in die Taktiken zur Anwendung von agilen Methoden ein.
F1: Digitale Agile-Boards vs. physische Agile-Boards Was ist eure Meinung hierzu?
A1: Das hängt sehr von eurer Teamzusammenstellung ab. Sind alle Teammitglieder an einem Ort? Wie groß ist dein Team? Habt ihr Platz für ein großes physisches Board? Wir haben bei Gilt beides verwendet, aber es hat sich herausgestellt, dass die agilen Boards in Jira Software praktischer als physische Boards sind, seit wir auf Dutzende Teams angewachsen sind. Sie sind einfacher einzurichten und zu ändern und lassen sich auch besser mit Remote-Teammitgliedern teilen. Der Vorteil von physischen Boards ist, dass man sie schlechter ignorieren kann, da sie einem regelrecht ins Gesicht starren. Sie bieten auch einen guten Ort zum Abhalten von spontanen Diskussionen zu aktuellen Aufgaben oder von Standup-Meetings, falls diese bei euch stattfinden.
F2: Wie arbeitet man mit einem Manager oder Kunden, der agile Prozesse nicht befolgt oder versteht? Ich fühle mich manchmal wie ein erfolgloser Workflow-Berater.
A2: Achte darauf, das Pferd nicht von hinten aufzuzäumen. Wenn du mit Personen in einem agilen Prozess arbeiten möchtest, die nicht davon überzeugt sind, überstürzt du die Dinge etwas. Der wichtigste Schritt bei der Einführung agiler Methoden ist das Erarbeiten einer gemeinsamen Denkweise, bevor ein Prozess in die Tat umgesetzt wird. Wir sind in solchen Fällen so vorgegangen, dass wir uns ein bestimmtes Problem, das das Team mit dem aktuellen Prozess hat, angesehen haben und dieses Problem auf agile Weise gelöst haben. Kannst du mit deinem Manager oder Kunden anhand von echten Problemen durchsprechen, wie du diese in einem agilen Framework angehen würdest? Vielleicht kannst du die Zweifler so Stück für Stück an agile Methoden heranführen, anstatt den ganzen Prozess auf einmal umzustellen? Auf diese Weise hast du reale Ergebnisse vorzuweisen, die sich zusammen mit der Arbeitsweise des Teams weiter verbessern werden. Kurzum, du gehst agil an die Umstellung auf agile Methoden heran. ;)
F3: Wie kann bei einem Festpreisprojekt und/oder einem festen Terminplan mit einer festen Anforderungsliste ein agiler Prozess implementiert werden?
A3: Zunächst einmal ist es nicht möglich, ein Projekt mit einem festen Zeitplan UND einer festen Liste an zu implementierenden Anforderungen erfolgreich abzuschließen. Sind wir uns also einig, dass dies ins Reich der Fantasie gehört? Die meisten Vorgaben rund um Deadlines und Anforderungen sind nicht zwangsläufig unumstößlich: Sie sind Wunschdenken. Besprich, warum du an dieser Aufgabe arbeitest bzw. welches Problem du damit lösen möchtest. Wenn du die Ziele des Projekts und die Gründe für die Vorgaben wirklich verstehst, kannst du dafür sorgen, dass das Team jederzeit an den richtigen Aufgaben arbeitet. Alle Anforderungen mit Datumsangaben niederzuschreiben führt nicht auf magische Weise dazu, dass alles rechtzeitig fertig ist.
F4: Die meisten Projekte haben ein Release-Datum, das normalerweise den Partnern und Kunden mitgeteilt wird. In diesem Szenario ist das Feature-Set der einzige verhandelbare Aspekt (dabei könnte es allerdings zu Qualitätseinbußen kommen). Wie arbeitet man vor dem Hintergrund einer unbeweglichen Deadline?
A4: Du hast dir die Frage im Prinzip selbst beantwortet – du verhandelst den Umfang. Andernfalls leidet die Qualität, wie du ganz richtig erwähnt hast. Dass man denselben Umfang trotzdem unterbringen kann, ist nur im Traum möglich – du musst sicherstellen, dass deine Teams in der Realität bleiben, auch wenn das niemand hören möchte. Heather hat hierzu einen kurzen Blogpost verfasst, den du hier lesen kannst.
F5: Wie sollte eurer Meinung nach die Art und Weise, wie Scrum implementiert wird, geändert werden?
A5: Das größte Problem haben wir mit der Starrheit von Scrum. Es ist anmaßend zu glauben, dass ein einziger Prozess mit starkem Vorschriftscharakter für alle Teams funktionieren wird – egal, woran sie arbeiten und um was für ein Team es sich handelt. Wir kennen Teams, bei denen Scrum funktioniert. Aber Scrum ist nicht die einzige agile Methode und bei vielen Teams scheitert Agile, weil sie denken, dass sie Scrum auf eine bestimmte Weise mit allen vorgeschriebenen Rollen, User Storys, Abnahmekriterien, Meetings und Artefakten implementieren müssen. Heather hat außerdem ein Problem mit dem Titel "Scrum Master". ;)
F6: Wie kann man Stakeholder davon abhalten, Teammitglieder direkt zu beeinflussen?
A6: Nun, ein guter Stakeholder IST ein Mitglied des Teams. Im Idealfall solltest du also die wichtigsten Stakeholder in dein Team einbinden, damit ihr alle zusammenarbeiten könnt! Wenn du es mit der Art Stakeholder zu tun hast, die dem Team nur die Arbeit vor die Füße wirft oder mitten im Projekt hereinplatzt und alles umorganisieren möchte, ist es wichtig, dass das gesamte Team versteht, woran es arbeitet und warum. Auf diese Weise erhält der Stakeholder von allen immer dieselbe Antwort. Genau das macht euch zu einem Team statt einer Ansammlung von Einzelpersonen. Du musst sehr viel kommunizieren und dafür sorgen, dass alle auf demselben Stand sind und sich in dieselbe Richtung bewegen.
F7: Schätzt ihr Storys auf Basis einer groben Zeitschätzung (in Stunden) oder auf Basis von Punkten?
A7: Wir machen beides, wobei manche Teams überhaupt keine Schätzungen abgeben. Story Points sind super, da sie abstrakter und nicht an einen bestimmten Kalendertag gebunden sind. Stunden können als Übergangslösung hilfreich sein, wenn dein Team sich gegen Schätzungen sträubt, da sie greifbarer sind. Der Zweck einer Schätzung ist es, festzustellen, ob der Sprint zu überladen ist oder noch zu wenige Aufgaben enthält, damit er dementsprechend angepasst werden kann. Nach Beginn des Sprints ist die Schätzung bedeutungslos. Wir finden den Schätzungsprozess unnötig, wenn du mit dem Team bereits eine Weile lang zusammengearbeitet hast. In diesem Fall können alle einen Blick auf die Aufgaben werfen und relativ leicht feststellen, ob die Menge für den jeweiligen Sprint passend ist.
F8: Wie viel Wert legt ihr darauf, dass Projektleiter/-manager über umfassende Analyse- und Produktkenntnisse verfügen? Oder reicht die Fähigkeit, Meetings zwischen den Stakeholdern aus den Technik- und Business-Teams zu koordinieren, um die Anforderungen zusammenzustellen?
A8: Das macht sogar den gesamten Wert der Projektleiter/-manager aus :) Die Koordinierung von Meetings, das Verfassen von Protokollen usw. sind keine besonderen Fähigkeiten. Das kann jeder. Natürlich muss all dies gemacht werden, aber es bietet dem Team nicht den größten Mehrwert. Wenn du nur administrative Arbeiten erledigst, dann fragt sich das Team zu Recht, warum du überhaupt Teil des Teams bist. Bei Gilt hat jeder im PMO tiefgreifende Kenntnisse der relevanten Thematik sowie der Tools und Techniken zur Erledigung der Arbeit. All dies bringen sie in jedes Team ein, mit dem sie arbeiten. Viele von uns waren früher Entwickler oder haben bei Gilt in anderen Abteilungen gearbeitet und verfügen über ganz spezielle Fachkenntnisse.
F9: Wie groß sind die Teams im Allgemeinen und welchen Hintergrund haben die Mitarbeiter von Gilt?
A9: Im Idealfall wünschen wir uns schlanke Teams, die aber groß genug sind, um eigenständig zu arbeiten und die Projekte vorantreiben können, ohne von anderen Teams abhängig zu sein. Wir richten uns nach der "Zwei-Pizzas"-Regel: Die Teams sollten mit zwei amerikanischen Pizzas satt werden. Außerdem ist uns enorm wichtig, dass jedes einzelne Teammitglied über einzigartige Kompetenzen verfügt, die es unabhängig von der eigentlichen Positionsbezeichnung auch im Team einbringen können sollte. Wenn also der Product Owner üblicherweise für alle Präsentationen zuständig ist, darin aber nicht gut ist, ein Entwickler des Teams dagegen über herausragende Redefähigkeiten verfügt und sein Publikum in den Bann zieht, sollten wir dieses Talent nutzen. Du bist mehr als nur deine Position!
F10: Wie leitet man ein separates QS-Team, vor allem, wenn die Tests nicht in den Sprints der Entwicklung durchgeführt werden?
A10: Wir nehmen hier eine eher kontroverse Position ein, aber wir haben bei Gilt kein separates QS-Team. Wir halten automatisierte Tests während des Entwicklungs- und Deploymentprozesses für die beste Vorgehensweise. Die Teams tragen die Verantwortung für die Qualität ihres Codes. Wenn du die Zeit und Fähigkeit hast, Code zu schreiben, hast du auch die Zeit und Fähigkeit, Tests dafür zu schreiben. Den Code einfach an ein QS-Team weiterzureichen, war bei uns nie sehr erfolgreich und erfordert jede Menge zusätzlicher Dokumentation und Zeit, um dem QS-Team die nötigen Informationen zukommen zu lassen.
F11: Wenn Teams an mehreren Produkten gleichzeitig arbeiten, kann man dann während der Sprintplanung alle Produktmanager in einem Raum versammeln und sie die relativen Prioritäten der verschiedenen Produkte festlegen lassen? Weitere Ideen?
A11: Stopp! Das wird ganz sicher nicht funktionieren. Das Team sollte einen eigenen Produktmanager haben und nicht an mehreren Produkten für verschiedene Produktmanager, die nicht dem Team angehören, arbeiten. Wer auch immer hier als Teamleiter fungiert, sollte hervortreten und das Priorisierungsverfahren des Teams und in welcher Reihenfolge es die Aufgaben auf dieser Basis bearbeitet klar und deutlich erläutern. Hier kommen wir wieder darauf zurück, dass das Team sich bei seiner Methodologie einig sein muss, bevor ein Prozess eingeführt werden kann.
F12: Ich möchte in einem Werbedienstleistungsteam agile Methoden etablieren. Einige Projekte MÜSSEN an einem bestimmten Datum fertiggestellt sein (Design von Werbeanzeigen für Printmedien). Wie passen solche Projekte in ein agiles Framework?
A12: Solche Vorgaben passen in agile Methoden hinein. Das Team muss festlegen, was bis wann erledigt werden muss, und die Sprints entsprechend planen. Agile Methoden sollten dir dabei helfen, diese Deadlines einzuhalten, da du die Möglichkeit hast, deine Prioritäten und deine geplanten Aufgaben (den Umfang) in jedem Sprint anzupassen. Wenn du eure Velocity verfolgst, wirst du sehr bald in der Lage sein, abzuschätzen, ob du diese Deadlines einhalten kannst. Nun ist es die Aufgabe des Teamleiters Bedingungen zu verhandeln, die das Team erfolgreich arbeiten lassen.
F13: Kommt die Änderung von Zielen nicht einem Scope Creep gleich?
A13: Ja, durchaus. Wir nennen dies jedoch nicht Scope Creep, da wir Änderungen während eines Projekts befördern möchten. Einer der größten Vorteile der agilen Denkweise ist die Möglichkeit zur Anpassung an äußere Gegebenheiten, über die du keine Kontrolle hast. Wenn die Wettbewerbslandschaft oder die Anforderungen deines Unternehmens sich ändern oder eine neue Technologie verfügbar ist, möchtest du dann wirklich an deiner vor Monaten erstellten Anforderungsmatrix festhalten? Wenn du deinen Kunden das beste Produkt bieten möchtest, solltest du Veränderungen begrüßen und sie zu deinem Vorteil nutzen. Scope Creep gibt es bei Agile nicht (hier ist der Einsatz eines Jedi-Geistestricks angebracht).
