Das Feedbacksystem in der Entwicklung

Der Hintergrund

Unsere IT-Teams wachsen seit Jahren immer weiter. Es kommen neue Mitarbeiter hinzu, Mitarbeiter gewinnen an Erfahrung, es kommen Berufseinsteiger, Mitarbeiter mit Erfahrung aber auch Auszubildende dazu. Der Umfang unserer Softwareprodukte wächst seit Jahren, folglich nimmt auch die Anzahl der Autoren weiter zu, die an unserem Hauptprodukt onOffice enterprise über die letzten Jahre mitgewirkt haben – wie im folgenden Graph zu sehen:

War unsere CRM-Software ursprünglich ein reines CRUD-System, haben wir mittlerweile Module, die einen hohen Grad an Automatisierung für unsere Kunden ermöglichen. Deren Komplexität ist dadurch aber deutlich höher, als eine reine Daten Ein- und Ausgabe. Für alle diese Punkte ist es wichtig, sich konstant weiterzuentwickeln. Neben Schulungen und Vorträgen sehen wir hierbei das gegenseitige Feedback als wichtiges Instrument.

Was genau ist Feedback (in der IT)?

Feedback (Rückübermittlung) bezeichnet die Kommunikation, bei der ein Empfänger das Wahrgenommene wiedergibt. Wir erhalten also aus der Perspektive eines anderen Informationen darüber, was wir gesagt oder getan haben. Wenn wir über Feedback in der IT reden, beziehen wir es in der Regel auf Programmcode, erstellte Planungsdokumente oder ähnliches – Erzeugnisse, in die der Ersteller viel Zeit investiert hat. Es kommt jemand zweites, schaut sich den erstellten Programmcode oder die erstellte Planung an und gibt eine Rückmeldung darüber – ein kritischer Schritt. Um konstruktives Feedback geben zu können, muss man sich immer in sein Gegenüber hineinversetzen. Feedback sollte immer sachlich korrekt und nachvollziehbar sein. Genauso wichtig ist es aber, dass man selbst in der Lage ist, Feedback anzunehmen – auch hier sollte man immer im Blick haben, dass sich gerade jemand bewusst Zeit dafür nimmt, diese Rückmeldung zu geben.

Feedback-Bausteine einsetzen

Unsere Kanban-Grundphilosphie enthält Feedback-Zyklen fest als eine Kernpraktik “Implementiere Feedbackzyklen”. So sind sie natürlich bei uns an vielen Stellen in unserem Entwicklungsprozess oder der täglichen Arbeit solche Feedback-Zyklen eingebaut.

Prüfung der Planung

Jede Erweiterung unserer Software beginnt mit einem Planungsdokument, das ein Produktmanager verfasst. Die erstellte Planung wird immer von einem Entwickler und einem Softwaretester geprüft. Sie hinterlassen Kommentare mit Hinweisen zu Stellen der Planung, die noch verbessert oder vereinfacht werden können. Der Produktmanager entscheidet dann, welche Rückmeldungen noch in die Planung aufgenommen, noch einmal genauer besprochen oder verworfen werden.

Beginnt der Entwickler die Umsetzung, spricht er sein Vorgehen immer mit einem erfahrenen Entwickler / Architekten ab. Jede Änderung wird zusätzlich noch von mindestens einem anderen Entwickler gereviewed. Beide Entwickler / Prüfer geben Rückmeldungen an den Entwickler, einmal vor- und einmal nach durchgeführter Umsetzung. Wichtig an beiden Stellen ist, dass es als “Feedback-Zyklus” und nicht als klare Vorgabe/Anweisung gedacht ist. Der Reviewer gibt nicht vor, was noch angepasst werden soll, er gibt eine Rückmeldung an den umsetzenden Entwickler. Ist der Entwickler anderer Meinung, diskutieren die beiden die Rückmeldung. Ziel des Feedback-Zyklus ist es, dass alle weiter voneinander lernen.  Dafür muss die Rückmeldung verstanden, eventuell diskutiert werden – sie darf nie blind angenommen werden.

Mit das wichtigste Feedback-Element zur Qualität unserer Software und unseren Umsetzungen sind die Bug-Reports unserer Kunden. Etwa 70% der Tickets, die als Bug-Report gemeldet werden, sind keine klaren Programmierfehler. Viele dieser Meldungen sind eher darauf zurückzuführen, dass die Software im entsprechenden Bereich unklar oder unverständlich ist. Dieses Feedback ist oft noch wertvoller als Meldungen zu wirklichen Programmierfehlern. Hier ergeben sich immer Verbesserungsmöglichkeiten auf einer ganz anderen Ebene als der, auf der sich Entwickler zum größten Teil bewegen. Es geht nicht mehr um Code-Qualität oder Code-Architektur, sondern um die Qualität der Software selbst – aus der Sicht unserer User. Gerade diese Meldungen werden im ersten Schritt vom Entwickler als unfair empfunden. Wie im direkten Feedbackgespräch zwischen zwei Mitarbeitern sollte aber immer im Fokus stehen, dass wir hier etwas lernen können. Daher wollen wir uns hier auch nie in Diskussionen darüber verlieren, ob eine solche Meldung nun ein Fehler eines Entwicklers oder ein Fehler in der Planung ist. Ein Benutzer meldet einen Fehler – unabhängig davon ob ein Programmier- oder Planungsfehler vorliegt oder die Software durch neue Erweiterungen inkonsistent wirkt. Also wollen wir aus einer solchen Rückmeldung lernen und die Software besser machen.

Feedback-System vs. Teams

Der Bereich Softwareentwicklung besteht bei uns mittlerweile aus mehreren Abteilungen und Bereichen. Wir haben eine Abteilung, die für die Umsetzung neuer Features verantwortlich ist, eine Abteilung, die die Wartung und Pflege der Softwareprodukte im Fokus hat und auch Teams, die eigene kleine Softwareprodukte betreuen. Die Feedback-Zyklen sind bewusst teamübergreifend:

• Tester sprechen mit Produktmanagern,
• Tester mit Entwicklern,
• Entwickler mit Produktmanagern und
• Entwickler verschiedener Abteilungen und Teams miteinander.

Auch innerhalb der Programmierung werden Code-Reviews und technische Planung team- und abteilungsübergreifend besprochen. Auch wenn der Aufgaben-Fokus sich unterscheidet (z.B. Weiterentwicklung vs. Wartung) geht es fachlich um das gleiche Thema.

Mitarbeitergespräche

In allen IT-Bereichen führen wir zweimal im Jahr ein Mitarbeitergespräch, das auch als Austausch / gegenseitige Feedbackrunde gedacht ist. Das Jahresgespräch legt den Fokus eher auf fachliche und methodische Punkte, das Zwischengespräch ist ein Rückblick auf die Projekte und Aufgabenbereiche der letzten Monate. In beiden Gesprächen geben sich Mitarbeiter und Team- oder Abteilungsleiter aber gegenseitige Rückmeldungen zur Zusammenarbeit. Ziel ist immer ein Gespräch auf Augenhöhe (Kanban: “Ermutige dazu, Führung auf jeder Ebene des Unternehmens zu zeigen”), was für das Geben und Annehmen von Feedback ein wichtiger Punkt ist.

Feedback-Zyklen zu Feedback-Zyklen

Zu guter Letzt kann man sogar eine Rekursion eröffnen. Auch unsere Feedback-Zyklen sind Gegenstand regelmäßiger Feedback-Zyklen. Der Modus zur Durchführung von Code-Reviews wird regelmäßig hinterfragt und wir tauschen uns dazu aus, wie gut das System in der Form funktioniert. Durch die eingangs angesprochenen wachsenden Teams, Abteilungen und Bereiche steuern wir auch hier immer wieder nach. In den letzten Monaten hatten wir einen festen Kreis an Code-Reviewern. Gerade starten wir erste Versuche die Code-Reviews in kompletten Teams zu verteilen – “jeder reviewed jeden”. Und natürlich werden wir auch hier wieder Rückmeldungen der Entwickler einholen, um weiter zu lernen.