So arbeiten wir bei CLINQ

CLINQ ist ein Produkt der sipgate GmbH. Genau wie sipgate arbeiten auch wir bei CLINQ lean und agil in einem crossfunktionalen Produktteam. Konkret heißt das: Alle wichtigen Rollen sind in einem Team vereint: Entwickler, Kundenbetreuer, UXer, Marketing und der Product Owner, der sich um die strategische Ausrichtung des Produkts kümmert. Dadurch, dass alle Rollen in einem Team vereint sind, haben wir kurze Entscheidungswege und können zum Beispiel schneller neue Features implementieren. Hierarchien gibt es bei uns nicht, alle sind gleichberechtigt.

So nutzen wir Scrum
Wir arbeiten bei CLINQ nach Scrum. Oder besser: Wir nutzen bestimmte Methoden und Artefakte aus dem Scrum-Framework. Wie das genau aussieht, lässt sich am einfachsten am Beispiel eines unserer Sprints zeigen.

Ein Sprint startet bei uns immer montags mit dem Planning. Dort legen wir fest, was wir diese Woche erreichen wollen, indem wir Stories aus dem sogenannten Backlog ziehen. Das Backlog pflegen wir gemeinsam im ebenfalls wöchentlichen Grooming. Meist geht es bei den Stories um bestimmte Verbesserungen und neue Funktionen, die wir für die Nutzer implementieren wollen. Aber auch Themen rund um Marketing und Kommunikation tauchen hier auf. Beispielhaft hier mal eine Story aus dem letzten Sprint:

„Als Ulf (eine unserer Personas) möchte ich die Absendernummer eines Channels ändern können, damit ich nicht nur Testanrufe machen, sondern auch echte Kunden anrufen kann.“

Diese Story ist aufgrund von Kundenfeedback entstanden. Viele unserer Alpha-Tester wünschen sich, dass sie auch schon während der Testphase die Absenderrufnummern ihrer Channels ändern können, damit sie bei ausgehenden Anrufen von ihren Kunden erkannt werden.

Und wie geht’s jetzt weiter?
Zwei Entwickler verpflichten sich je nach Bedarf mit einem UXer für die Story und zerlegen sie dann im Task Breakdown in zu erledigende Aufgaben. Die beiden Entwickler arbeiten fast immer am Code, indem sie pairen (also zu zweit am selben Code arbeiten, auch am selben Arbeitsplatz). besonders wenn – wie in diesem Fall – Funktionen in das Interface eingebaut werden, ist ein UXer dabei und erarbeitet mit den Entwickeln zusammen die benutzerfreundlichste Lösung. Zusätzlich versuchen wir, alle neuen Funktionen auch direkt von „echten Nutzern“ ausprobieren zu lassen. Dazu laden wir zum Beispiel Leute zu uns ein oder machen regelmäßige Usertests mit Kollegen außerhalb des CLINQ-Teams.

Kommunikation im Team
Ein weiterer Bestandteil unserer Arbeitsweise ist das tägliche Standup. Hier hält sich das Team gegenseitig auf dem Laufenden: Wie weit kam das Entwickler Pair gestern mit dem Feature, die Absenderrufnummer individuell ändern zu können? Wie soll es heute weitergehen? Brauchen sie dafür eventuell Hilfe von einem anderen Teammitglied?

Retrospektieren hilft
Wir wollen aus der Vergangenheit lernen. Deshalb lassen wir einmal in der Woche den vergangenen Sprint in der Retro Revue passieren. Was ist gut gelaufen, was schlecht? Welche Ideen gibt es? Hier geht es vor allem darum, die Zusammenarbeit im Team kontinuierlich zu verbessern und eventuelle Unstimmigkeiten zu klären. Oft fallen aus den Retros sogenannte Action Items heraus, also Dinge, die das Team in der Zukunft tun möchte, um noch besser und auch schneller arbeiten zu können.

Warum machen wir das überhaupt?
Durch iteratives Arbeiten können wir Fehler früh erkennen und Dinge ausprobieren, bevor wir übermäßig viel Aufwand in die Entwicklung eines Produkts stecken und erst am Ende feststellen, dass es niemand benutzen möchte. Außerdem können durch wöchentliche Sprints kontinuierlich und flexibel neue Produkteigenschaften implementiert werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Weitere Beiträge