Wir haben sie alle gelesen; es gibt sie schon seit Jahrzehnten: Bücher über Management, Produktentwicklung und Teamwork. Doch die darin beschriebenen Methoden anzuwenden und gewünschten Resultate zu erzielen, klappt nicht immer so reibungslos, wie es sich dort liest.
Bei einem Projekt, an dem wir kürzlich gemeinsam mit unserem Kunden ShareNow gearbeitet haben, war das anders. Alles kam fast wie von Zauberhand zusammen: Wir haben ein tolles, leistungsstarkes Team zusammengestellt und hatten damit einen sehr erfolgreichen Produkt-Rollout. Hier möchten wir einige der Praktiken vorstellen, die unserer Meinung nach entscheidend für unseren Erfolg als Team waren. Und natürlich auch für das hervorragende Produkt, das wir entwickelt haben.
______
1. Bei der Product Discovery zusammenarbeiten
Das Projekt nahm seinen Anfang nicht in einem Besprechungsraum oder an einem Whiteboard, sondern vor Ort bei den Anwendern. Ein Kernteam aus dem Product Owner, einem Business Analyst und einem Entwickler untersuchten zuallererst, wer die Zielgruppe war. Sie fanden heraus, wie diese ihre tägliche Arbeit erledigten und welche ihrer Probleme mit der bestehenden Lösung durch das neue Produkt beseitigt werden konnten.
Während des Projekts haben wir alle möglichen Arten von Maps genutzt, um unsere zusammengetragenen Informationen zu visualisieren. Das hat dem Produkt- und dem Entwicklungsteam geholfen, sich gemeinsam ein besseres Bild von den Problemstellungen zu machen.
2. Die Zustimmung aller Beteiligten einholen
Nach unserer ersten Recherche arbeiteten wir das Produkt weiter aus und definierten die besten Handlungsoptionen. Hierzu wurden die Prioritäten in einem Workshop mit der Geschäftsleitung noch einmal gezielt abgesteckt. Im Laufe von zweieinhalb Tagen haben wir uns dabei schrittweise auf den Umfang des Projekts geeinigt. Wir verwarfen einige potenzielle Ansätze und definierten gemeinsam die für das Unternehmen nützlichsten Optionen.
3. Ein ausgewogenes Team zusammenstellen
Die meisten Entwicklerteams setzen einen starken Fokus auf das Lösen technischer Probleme. Zu unserem Team gehörten neben den Entwickler:innen und einem Product Owner auch zwei UX-Designer:innen und ein Business Analyst. Damit hatten wir für das Projekt ein ausgewogenes Team zusammengestellt. Wir konnten sowohl die Entwicklungsarbeit als auch die erforderliche Recherche durchführen und Problemen der Anwender auf den Grund gehen.
4. Die Arbeitsweise abstimmen
Das Team entschied gemeinsam, welche Art von Besprechungen wir ansetzen wollten, wie viel wir von zu Hause aus oder im Büro arbeiten und welches Framework wir verwenden wollten. Die wertvollste Erfahrung dabei war, unsere Rollen und Verantwortlichkeiten zu diskutieren. Wir tauschten uns darüber aus, welche Kernkompetenzen und Zusatzkompetenzen jeder in das Team einbringt und welche Erwartungen wir an die Rollen der anderen haben. Daraus entwickelten sich sofort ein Gemeinschaftsgefühl und ein gemeinsamer Teamgeist.
5. Anwender-Feedback-Schleifen aufbauen
Wir sprachen mit den zukünftigen Anwender:innen unseres Produkts regelmäßig auf verschiedenste Weisen, sowohl online als auch vor Ort. Vom ersten Tag an haben wir zudem Analysen und Metriken in unsere Anwendung integriert. Dank einer Betaversion konnten wir direkt Feedback einholen und Funktionen mit Verbesserungsbedarf identifizieren.
6. Das Risiko in den User Journeys verringern
Bei der Umstellung vom alten System auf die neue Lösung mussten wir viele der User Journeys neu konzipieren und den Architekturansatz ändern, was ein gewisses Risiko darstellte. Um dieses Risiko zu minimieren, haben wir zuerst die häufigsten User Journeys ermittelt und diese in das neue Tool aufgenommen. Wir entwickelten eine Migrationsstrategie, die die Anzahl der Baustellen gering hielt.
7. Die gestalterische Arbeit sichtbar machen
Wir haben das Kanban-Board der Entwickler:innen auf das Produktteam ausgeweitet und es "Experimentier-Board" genannt. Unsere UX-Designer:innen, der Business Analyst und der Product Owner nutzten das Board ebenso, um Ideen zu sammeln, sie zu validieren und sie schließlich in eine Analyse- und Designphase zu überführen. Danach wurden sie in das Produktions-Backlog übertragen. Die Visualisierung dieser Arbeit erwies sich als extrem vorteilhaft, denn sie ermöglichte es uns, Ideen frühzeitig mit den Entwickler:innen zu besprechen und gleichzeitig Transparenz und Klarheit für alle Beteiligten und das Management zu schaffen.
8. Interdisziplinär zusammenarbeiten
Neben dem Pair-Programming haben wir auch funktionsübergreifend zusammengearbeitet, um bestimmte Aufgaben zu lösen. Das hat uns geholfen, unterschiedliche Perspektiven einzunehmen, Wissen auszutauschen und schnell die praktikabelsten Lösungen zu finden. So verringerten wir ein langes Hin und Her in Besprechungen.
9. Silos überwinden
Mit den Zweierteams, den Gesprächen über Rollen und Zuständigkeiten und der Teamzusammensetzung schufen wir ein vertrauensvolles Klima. In diesem scheuten sich die Mitarbeiter:innen nicht, auch einmal etwas Neues auszuprobieren. Wir versuchten aktiv, an Dingen zu arbeiten, die nicht zu unseren Kernkompetenzen gehören. Jedes Teammitglied fühlte sich für das Gesamtergebnis verantwortlich und nicht nur für den individuellen Beitrag.
10. Ein soziales Netzwerk schaffen
Wir haben uns gegenseitig kennengelernt. Wir haben miteinander gesprochen. Wir haben unsere Egos hinten angestellt. Dadurch haben wir ein soziales Netzwerk geschaffen. So sind vor allem Einfühlungsvermögen, Aufgeschlossenheit und Vertrauen entstanden. Dies half uns, uns gegenseitig nicht nur bei der Arbeit sondern auch in privaten Situationen zu unterstützen. Als die Pandemie ausbrach und wir komplett auf Homeoffice wechselten, konnten wir auch remote erfolgreich zusammenarbeiten.
______
Unser Produkt ist von Anwender:innen und Stakeholdern hervorragend bewertet worden, und wir haben keinen Zweifel, dass der Erfolg eng damit zusammenhängt, wie gut wir als Team funktioniert haben. Wir hoffen, dass diese zehn Best Practices als Inspiration für andere Teams dienen. Die "Rezeptur" lässt sich entsprechend verfeinern, um diese Erfahrung in anderen Teams zu wiederholen – etwa mit Ideen aus dem Playbook "Design as a Team". Wenn es funktioniert, ist es fast magisch und macht eine Menge Spaß!
Wenn Sie mehr über dieses Thema erfahren möchten, schauen Sie sich unsere On-Demand Session an.
Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.
