Lean, Agile und Scrum.
Was versteht man unter „agilem Arbeiten“? Was verstehst du darunter? Wenn wir uns über „Value“, „Selbstorganisation“ oder „Kaizen“ unterhalten, haben wir dann wirklich das gleiche Verständnis davon? Und wie werden die leanen und agilen Prinzipien bei sipgate gelebt? Diese und andere Fragen beschäftigen uns. Nicht nur, als wir damit ganz am Anfang standen, sondern auch heute noch.
Wenn unsere neuen Kolleginnen und Kollegen bei uns starten, dann machen sie direkt mit und lernen von den anderen in ihrem Team. Manches erscheint aber nicht intuitiv, und während der täglichen Arbeit ist vielleicht nicht genug Zeit, um alles zu hinterfragen. Deswegen gibt es bei uns regelmäßig einen Workshop, in dem wir die Grundlagen von Lean, Agile und Scrum vermitteln. Dabei setzen wir uns damit auseinander, was das alles in der Praxis tatsächlich bedeutet.
Der Workshop ist ein Mix aus Theorie und Praxis: von einer Geschichtsstunde über die Familie Toyoda (sic!) bis hin zu Legolympia, einem Spiel, das Einblick in das Scrum-Framework gibt. Der Workshop kommt ohne PowerPoint und lange Monologe aus. Stattdessen gibt es viel Spaß und jede Menge Erkenntnisse.
Wir nehmen uns für alle Fragen viel Zeit. Antworten gibt es nicht nur von den Scrum Mastern, die den Workshop veranstalten, sondern auch von den anderen Teilnehmern. Meist geht es gar nicht um „richtig“ oder „falsch“, sondern darum, welche Erfahrungen andere in konkreten Situationen gemacht haben, die in der Einsteigerliteratur selten thematisiert werden: Wie handhaben andere Teams den Umgang mit Tickets? Stört das nicht den Sprint? Entscheiden alle bei allem mit? Arbeiten die Teams, die nicht direkt an der Produktentwicklung beteiligt sind, eigentlich auch agil?
Teilnehmer sind vor allem unsere „Newbies“, aber immer häufiger auch Interessierte aus anderen Firmen. Das gibt interessante Diskussionen und hilft beim Perspektivwechsel. Sowohl unseren Gästen als auch uns.
Cross-funktionale Teams.
Wir möchten neue Funktionen schnell auf die Straße bringen. Das schaffen wir nicht, indem wir härter arbeiten, sondern indem wir Übergaben vermeiden – durch cross-funktionale Teams. Denn Übergaben führen zu Wartezeiten und Missverständnissen.
Jedes Team ist deshalb für genau ein Produkt verantwortlich. Die Teammitglieder identifizieren sich mit ihrem „Baby“ und bauen Produktwissen auf.
An manchen Produkten arbeitet mehr als ein Team, jeweils mit unterschiedlichem Fokus. Kein Team arbeitet an mehr als einem Produkt.
In cross-funktionalen Teams arbeiten beispielsweise Entwickler, User Experience Designer, Product Owner und Scrum Master zusammen. So ein Team sitzt gemeinsam in einem Raum, arbeitet an gemeinsamen Aufgaben und kann ein komplettes Stück Funktionalität alleine bauen. In vielen Teams sind noch mehr Rollen vertreten, wie Marketing oder Kundenbetreuung. So sind alle Kundenprobleme nur einen Schreibtisch weit entfernt von den Leuten, die Problemursachen beseitigen können.
Im Alltag kann das so ablaufen: Wenn man ein neues Feature baut und dafür ein Design braucht, dann sitzt Peter im Raum, der eines entwirft. Wenn man nicht sicher ist,
den Zweck der Funktion richtig verstanden zu haben, lässt man es sich nochmal von Product Owner Renzo erklären. Wenn man sich den letzten Umsetzungsstand ansehen will, rollt man einfach mit seinem Stuhl zwei Meter weiter neben Laura, die gerade daran codet.
Alle Teams können schnell und selbstständig arbeiten, ohne auf team-externe Entscheidungen oder Dienstleistungen warten zu müssen. Auch Engpässe werden oft innerhalb der Teams gestemmt. Als sich mal bei einem Team die Kundenanfragen stauten, halfen einen Tag lang alle Teammitglieder beim Beantworten, um den Berg abzutragen. Selbstorganisierende, cross-funktionale Teams sind großartig!
Retrospektiven.
Wenn du aus diesem Artikel nur eine Sache mitnimmst und selbst ausprobierst, dann die Retrospektiven! Deren Wichtigkeit für Lernen und kontinuierliche Verbesserung kann man gar nicht überschätzen.
Eine Retrospektive ist geschützte Zeit abseits des täglichen Gewusels, um über die jüngere Vergangenheit und das eigene Verhalten nachzudenken. In seiner einfachsten Form beantwortet man als Team drei Fragen:
- Was hat gut funktioniert?
- Was hat nicht so gut funktioniert?
- Was wollen wir ausprobieren?
Wichtig ist, dass diese Retrospektiven regelmäßig stattfinden und nicht nur am Ende eines Projektes oder „bei Bedarf “. So kann man neue Erkenntnisse und Handlungsoptionen direkt anwenden und das laufende Projekt verbessern.
Die meisten Teams retrospektieren alle zwei Wochen für 60 bis 90 Minuten. Retrospektiven laufen besser, wenn sie moderiert werden. Bei uns machen das sogenannte Scrum Master.
Was wir in Retros nicht machen: Schuldige suchen und Verantwortung von uns weisen. Die Vergangenheit können wir nicht mehr ändern. Bei einer Retro geht’s darum, wie wir es in Zukunft besser machen können.
Das funktioniert nur, wenn alle offen sprechen. Vertrauen und Vertraulichkeit sind sehr wichtig. Es gilt die Vegas-Regel: „What happens in Vegas, stays in Vegas“, also „Was in der Retro passiert, bleibt dort“. Wir tragen das Gesagte nicht nach außen. Nur unsere Action Items (die Änderungen, die wir uns vorgenommen haben) dringen nach außen.
Diese Änderungen können ganz kleine Sachen sein. Wenn man das lange genug durchzieht, bewirken viele kleine Schritte insgesamt gewaltige Verbesserungen.
Kanban.
Als wir 2010 anfingen, agil zu arbeiten, haben wir Scrum als Framework gewählt. Das benutzen heute noch die meisten unserer Teams. Aber nicht alle. Manche machen
Kanban.
Kanban holt einen da ab, wo man sich gerade befindet. Im ersten Schritt visualisiert man einfach nur die eigenen Arbeitsabläufe, normalerweise auf einem Board. Als zweiten Schritt limitiert man die Anzahl gleichzeitiger Projekte. So reduzieren wir Multitasking und erhöhen die Produktivität.
Man beobachtet, wie Aufgaben das Board durchlaufen und geht Stellen gezielt an, an denen sich durch Flaschenhälse viel Arbeit staut. Nach und nach werden dann unausgesprochene Regeln explizit gemacht. Der letzte Schritt ist das regelmäßige Reflektieren und Verbessern der eigenen Arbeitsweise in Retrospektiven.
Kanban ist ursprünglich eine Idee von Toyota für die Steuerung der industriellen Fertigung. Passt aber auch für Wissensarbeit prima. Bei uns sind die Admins die Kanban-Vorreiter. Sie feilen schon seit Jahren an ihrem Flow. Während sie früher genug aufgestaute Arbeit für anderthalb Jahre hatten, warten neue Aufgaben heute kaum noch. Als siebenköpfiges Team haben die Admins zu jedem Zeitpunkt höchstens drei Projekte gleichzeitig in Arbeit. Den meisten Aufgaben widmen sie sich zu zweit oder zu dritt. Das senkt die Fehlerrate enorm.
Inzwischen haben andere Teams nachgezogen. Die Product Owner behalten mit Kanban die Übersicht über unser Produkt-Portfolio. Die Kundenbetreuer unseres Privatkundenprodukts „sipgate basic“ organisieren so ihre langfristigen Aufgaben, genauso wie unser Personalteam.
Kanban funktioniert in all diesen verschiedenen Fällen super.
Lean Startup.
Unser heutiges Flaggschiff „sipgate team” ging 2009 nach drei Jahren Entwicklung online. Drei Jahre! Das muss man sich auf der Zunge zergehen lassen. Drei Jahre Entwicklungszeit sind eine enorme Wette auf eine Produktidee. Wir hatten Glück, „sipgate team“ ist ein Erfolg. Aber was, wenn nicht?
Heute würden wir auf gar keinen Fall mehr drei Jahre ins Blaue hinein entwickeln, ohne zu wissen, ob das Produkt begeisterte Käufer finden wird. Im Gegenteil: Wir versuchen, unsere vielen Ideen so früh wie möglich zu testen und falls nötig zu verwerfen.
Für jede Feature- oder Produktidee füllen wir eine Checkliste aus, damit wir nichts Wichtiges vergessen: Passt die Idee zur Gesamtstrategie? Wieviel Gewinn erwarten wir? Welches Problem wollen wir eigentlich lösen? Für viele schlaue „Lösungen“ gibt es nämlich gar kein passendes Problem. Blöd.
Viele Konzepte haben wir von Lean Startup übernommen, vorneweg das „Minimum Viable Product“. Für jede konkret gewordene Idee überlegen wir uns das kleinstmögliche Experiment, um unsere Annahmen zu überprüfen.
Wenn wir nicht wissen, welche Themen potenzielle Kunden wirklich interessieren − Faxen ohne Faxgerät? Anrufmenüs? Die nahende ISDN-Abschaltung? − dann probieren wir es aus: Wir haben in fünf Tagen fünf rudimentäre Landing Pages aus dem Boden gestampft und Werbung geschaltet. Später schauen wir nach, welche Seiten besucht wurden, und nur in diese Themen investieren wir Zeit.
Willkommen.
Strukturen und Methoden sind wichtig, keine Frage. Aber unser Fundament ist ein anderes. Das sind nämlich wir: die Kolleginnen und Kollegen, die jeden Tag zusammenkommen, um gemeinsam gute Dinge zu erreichen. Bloß wie sieht der Start in so eine Gemeinschaft aus? Eigentlich ganz einfach:
Wir haben jemanden eingestellt, juhuu! Beide Seiten haben unterschrieben und sind sich einig. Toll! Und jetzt?
Jetzt muss unsere neue Kollegin oder der neue Kollege erst mal die Kündigungsfrist beim alten Job einhalten. Und das kann dauern… Früher galt: „aus den Augen, aus dem Sinn“. Inzwischen tun wir einiges, um während des Schwebezustands zwischen Einstellung und Arbeitsanfang verbunden zu bleiben.
Ein liebevolles Detail dabei ist die handgeschriebene Willkommens-Karte. Zwei Wochen bevor es mit der Arbeit so richtig losgeht, wird die Karte verschickt. Darauf steht eine kurze Notiz, unterschrieben von uns allen. Naja, nicht allen, aber schon ziemlich vielen. Wem man so bei der Kaffeemaschine aufgelauert hat. „Hier unterschreib mal. Ist für die Melle, die fängt am 1. bei uns im satellite-Team an. Macht Social Media.“ „Wie schön! Gib her, mach ich gerne.“ Das bereitet schon mal alle auf die neue Kollegin vor.
Falls es eine Veranstaltung gibt, denken wir an unsere Neuen. Das gilt für firmenweite Veranstaltungen wie Weihnachtsfeier und insbesondere Team-Events. Wenn kein solches Event in die Wartezeit fällt, dann eben nicht. Aber wenn doch, prima, dann kann man sich schon mal etwas kennenlernen.
Unser letzter Kniff ist das Willkommens-Board. Dort hängen wir die Konterfeis der neuen Kollegen auf, komplett mit Name, Rolle, Team und wann sie bei uns anfangen. So wird man schon am ersten Tag von manchem alten Hasen mit Namen begrüßt. Das ist, und wir zitieren wörtlich: „Bisschen creepy, aber auch voll schön.“
Der Pate.
Endlich! Das Warten hat ein Ende und es kann losgehen. Wie läuft der erste Tag bei uns ab? Am Platz wird man von Blumen und Pralinen begrüßt. Diese Wertschätzung gibt den Ton an, für den Rest unserer gemeinsamen Zeit.
Neben Blumen und Schoki liegt ein Guide mit Basis-Infos und Links zu den wichtigsten Themen wie sipgate Historie, Formalkram, welche Teams es gibt und wie man sie erreicht.
Am allerwichtigsten ist aber der persönliche Pate. Jemand aus dem Team, idealerweise mit der gleichen Rolle, der wirklich jede Frage beantwortet. Außerdem hält der Pate schon den Laptop und wichtige Logins parat. Natürlich kann man immer jeden im Team fragen, aber ganz am Anfang gibt es da doch oft Hemmungen.
Man denkt, es seien nun echt zu viele oder einfach zu blöde Fragen. Gott sei Dank ist der Pate genau dafür da. Und nicht nur ganz am Anfang. Der Pate steht seinem „Patenkind” für die ganzen sechs Monate Probezeit zur Seite. Auch danach ist das Verhältnis oft noch eng.
Paten begleiten und coachen neue Kollegen etwas mehr als der Rest des jeweiligen Teams. Sie organisieren auch die obligatorischen Feedbackgespräche, damit die Neuen von mehreren Seiten Rückmeldungen zur eigenen Arbeit bekommen.
Vom ersten bis zum letzten Tag gilt bei uns: Keine Titel, keine Manager, keine Abteilungen, keine Gehaltsverhandlungen, keine Budgets, keine Angst, keine Überstunden . Stattdessen: Selbstverantwortung, Feedback, Lernen, Freiheit und Spaß – das ist es, was uns glücklich und gleichzeitig besser macht.
vorab veröffentlicht in WiWi Career 2020/2021
