Die agile Agentur: Teil 3

by | 20. Jun 2018

Bei Fewclicks arbeiten wir nach Scrum. In unserer Artikelserie “Die agile Agentur” beleuchten wir unsere Erfahrungen mit agilen Methoden und wie wir Scrum als Prozess in unserem Team eingeführt und angepasst haben. Die vierteilige Serie behandelt Themen wie das agile Manifest, Retrospektiven, Scrum und agile Angebotsstellung & Abrechnung.

Weitere Informationen zu Scrum:
Das agile Manifest | Was ist Scrum?

Deine Agentur wird agiler – Introducing Scrum

Was passiert, wenn man sich wirklich entscheidet nach einer agilen Methode zu arbeiten? Wie entscheidet man, welche die richtige für sein Team ist und welche zum aktuellen Alltag passt? Wir wollen in diesem Artikel versuchen, etwas Licht ins Dunkle zu bringen.

Es gibt verschiedene agile Methoden. Die beiden wichtigsten und am Weitesten verbreiteten sind wohl Scrum und Kanban. Der Hauptunterschied von beiden liegt darin, dass Scrum in festen Iterationen abläuft – sogenannte Sprint – und Kanban eher eine Art evolutionäres Fließbandprinzip mit diversen Einschränkungen darstellt. Was beide Methoden gemeinsam haben sind die Basics. Artefakte wie Backlogs und Boards zur Ticketverwaltung, Meetings wie Reviews, Dailies und Retrospektiven und ein Team, das eine gemeinsame Vision verfolgt.

Unsere agile Agentur

Wir haben uns bei Fewclicks für Scrum entschieden. Mit kurzen Sprints und einem breit aufgestellten Team können wir so flexibel und schnell auf wechselnde Anforderungen unserer Kunden reagieren, haben aber auch genug Struktur, um uns nicht in Chaos zu verlieren. Durch die iterative Vorgehensweise bei Scrum haben wir feste Termine, an denen wir unseren Kunden fertige Features und nächste mögliche Release-Kandidaten zeigen können. Dank der genauen Rollenverteilung können sich unsere Entwickler auf das Erreichen des Sprint-Forecasts konzentrieren, während das Projekt-Management, das bei uns die Rolle des Product Owners auf Projektbasis inne hat, sich auf den Kontakt mit dem Kunden fokussieren und Anforderungen analysieren kann. Unser Scrum Master passt bei allem auf, dass wir uns an die Vorgaben des Scrum Frameworks halten, aber auch genug Flexibilität in den Prozess bringen, um den Agenturalltag abzuhandeln. Gemeinsam kümmern wir uns um die Ausformulierung von User Stories und schätzen diese auf Story-Point-Basis. Wie das genau funktioniert, zeigen wir im nächsten Beitrag.

Im besten Fall ist ein Scrum-Team breit genug aufgestellt, um alle Anforderungen eines Projektes bzw. Produktes entwickeln zu können. Derzeit besitzt unser Team die folgenden Rollen:

  • PO
  • Frontend-Entwicklung
  • Backend-Entwicklung
  • Web-Design
  • Qualitätssicherung
  • Scrum Master

Wir beschränken uns bei Scrum hauptsächlich auf unsere Software-Entwicklung. Unser Designer hat zum Beispiel zusätzlich Kunden, die nur Leistungen im Grafikbereich benötigen – unabhängig von einem kompletten Projektmanagement oder einer Produktvision. Aus diesem Grund arbeitet er unabhängig von Scrum und steht als Stakeholder für die Umsetzung seiner Designvorgaben.

Wieso machen wir sowas?

Die Antwort heißt Transparenz und Konsistenz. Natürlich ist es toll, wenn sofort gesprungen wird, sobald das Telefon klingelt. Langfristig bedeutet das aber oftmals Frust für das Team und ständiges hin und her springen zwischen Projekten. Hier hilft uns die Rolle des Product Owners immens weiter, da dieser für das Team entscheidet, welche Anforderungen als nächstes mit welcher Priorität umgesetzt werden. Der PO entscheidet das anhand eines projektübergreifenden Backlogs zusammen mit den einzelnen Kunden. Ein Kunde weiß somit recht genau, wann er mit der Umsetzung einer Anforderung rechnen kann und ist auf der sicheren Seite, dass das Entwicklerteam ohne stressige Einflüsse von außen die Möglichkeit hatte, diese auch qualitativ hochwertig umzusetzen. Da wir uns auch die Zeit nehmen Retrospektiven am Ende jedes Sprints abzuhalten, können wir schnellstmöglich Probleme innerhalb des Teams oder des Entwicklungsprozesses identifizieren, darauf reagieren und schon im nächsten Sprint ein noch besseres Ergebnis abliefern.

Insgesamt hat sich in den letzten 5 Monaten gezeigt, dass uns die disziplinierte Einhaltung von Scrum an vielen Stellen geholfen hat, gemeinsam Lösungen für Alltagsprobleme zu finden und diese auch umzusetzen. Das Entwicklerteam kann sich jetzt komplett auf die Umsetzung von Features und auf die gemeinsame Weiterentwicklung konzentrieren, während das PM-Team zusammen mit unseren Kunden Anforderungen formuliert und priorisiert. Nachdem wir es geschafft haben in den ersten 3 Monaten den Prozess “Scrum” einigermaßen zu festigen und eine gewisse Routine zu etablieren, konnten wir uns in den letzten Wochen darauf fokussieren, Lösungen für die typischen Agenturprobleme zu finden. Ganz oben stehen hier natürlich Prozesse für wechselnde Anforderungen oder dringende Hotfixes während eines Sprints. Hier darf man sich keinesfalls hinter Scrum verstecken, sondern muss die Freiheiten des Frameworks nutzen, um für sich selbst den besten Weg zu finden. Solange das Scrum-Team einstimmig damit konform ist und eine eigene Regelung nicht nur der Bequemlichkeit, sondern auch der Sinnhaftigkeit dient, den Prozess anzupassen, steht hier auch nichts im Weg. Man muss lernen – das mussten wir auch – den Prozess für uns zu nutzen und uns nicht dahinter zu verstecken. Oftmals liest man von Scrum-Zombies. Diese Epidemie sollte man auf jeden Fall vermeiden.

Wie weiß ich jetzt, welche agile Methode zu mir passt?

Die Antwort ist recht einfach: Wahrscheinlich jede. Nachdem agile Methoden, oder auch die Arbeit nach dem agilen Manifest, meist nur Good Practices vorgeben, kann man theoretisch jede Methode verwenden, um aus schnelllebigem Chaos eine agile Struktur zu machen. Man achte hier auf das “theoretisch.” In der Praxis ist es sinnvoller sich vor allem anfangs für eine Methode zu entscheiden, die ein paar mehr Regeln aufweist. Nicht um sich einzuschränken, aber auf jeden Fall, um schneller Antworten auf Fragen zu finden die sicherlich am Anfang aufkommen werden. Jeder neue Prozess, jede neue Arbeitsweise wird am Anfang Fragen aufwerfen, egal wie gut sie von irgendwem eingeführt wurde. Es wird immer wieder zu Sonderfällen kommen, die noch nicht berücksichtigt wurden, in die man etwas Hirnschmalz stecken muss, um eine gute Lösung zu finden oder die vom jeweiligen Framework gar nicht abgedeckt werden.

Eine gute Entscheidung ist es auf jeden Fall von Anfang an zu erkennen, dass die Rolle des Scrum Masters hier nicht unterschätzt werden darf. Ein erfahrener Scrum Master kann sicherlich den Einführungsprozess einer agilen Methode nebenbei begleiten. Sollte man sich aber dafür entscheiden, dass jemand aus dem Team mit wenig Erfahrung dafür verantwortlich ist, muss man sich darüber bewusst sein, dass diese Person die nötige Zeit dafür freigeschaufelt bekommen muss. Ohne diese Zeit wird die anfängliche Euphorie schnell im Alltag verblassen und die Agilität wieder verschwinden. Die Aufgabe des Scrum Masters ist es hier vor allem ein dickes Fell zu haben und gegen die Angst und Bedenken der Kollegen anzukämpfen. Etwas neues kann zu Beginn natürlich unangenehm sein. Der Alltag wird durchbrochen, plötzlich wird Disziplin gefordert und ein gewisses Maß an Selbstorganisation gefordert. Oftmals wird man hier sehen, dass es nicht jedem leicht fällt, aus der Komfortzone herauszutreten und sich den neuen Ideen hinzugeben. Aber genauso oft zeigt sich dann auch, dass es nach wenigen Sprints schon eine Verbesserung innerhalb des Teams gibt und plötzlich alles viel runder läuft, da Verantwortungen und Herangehensweisen und vielleicht sogar schon die ersten Sonderfälle viel klarer sind.

Wenn man nach einem Jahr feststellt, dass das Team mit Scrum sehr gut funktioniert, kann man auch etwas freiere Methoden betrachten. Kanban bringt hier zum Beispiel ein etwas flexibleres Modell mit, da es den “heiligen” Sprint nicht gibt und das Fließband auf Featurebasis abgearbeitet und reviewed wird. Natürlich sollte man sich dann aber auch Fragen, ob es nötig ist die Methode zu wechseln, obwohl Scrum gut läuft. Wichtig ist einfach, dass man in regelmäßigen Abständen den Komplettprozess zum Thema einer Retrospektive macht und mit dem Team zusammen darüber reflektiert, wie die letzten Monate liefen.

Bei Fewclicks können wir anderen Agenturen helfen, die richtige agile Methode zu wählen und bei der Einführung beratend und auch agierend zur Seite zu stehen. Für Fragen und einen ersten Termin stehen wir gerne unter info@fewclicks.io zur Verfügung.

Weitere Artikel aus dieser Reihe:

Teil 1: Chaos auf Zuruf
Teil 2: Die Retrospektive – Das Herz der agilen Agentur

Teil 4: Agile Angebotsstellung und Abrechnung – Über Projekte und was danach kommt (Support & Co)

Alles was ihr über agile Methoden wissen müsst, um als Team Projekte erfolgreich zu meistern. Wir bieten Workshops und Beratungsleistungen für Unternehmen und Agenturen.

Was können wir für Sie tun?

Nutzen Sie unseren Call-Back-Service. Geben Sie Ihre Daten ein, erzählen Sie uns von Ihrem Projekt und wir werden uns umgehend bei Ihnen melden.

14 + 14 =

Kontakt

+49 951 40 73 53 80

INFO@FEWCLICKS.IO

An der Spinnerei 6, D – 96047 Bamberg