BLOG / SOLUTIONS · ENTWICKLUNGSTEAMS

M iteinander konkurrierende Ziele können Entwicklungsteams in der Software­entwicklung auseinander­reißen. In diesem Beitrag beschreiben wir einen Weg, wie das Team-Setup gelingen kann, wenn Sie einerseits die Nutzer des aktuellen Produkts zufrieden­stellen möchten und andererseits zugleich das Produkt umfassend weiterent­wickeln wollen.

Viele Softwareunternehmen stehen vor dem gleichen Problem. Sie müssen ihre Kunden mit der aktuellen Produktversion zufrieden­stellen und das Produkt gleichzeitig modernisieren. In einem solchen Szenario kann ein Entwicklungsteam hin- und hergerissen sein, wenn es einerseits die Software modernisiert, um das Produkt der nächsten Generation zu erstellen, und andererseits dem Kunden immer noch das Gewohnte bieten möchte.

WAS ENTWICKLUNGSTEAMS AUSEINANDER­REISST

Für Entwicklungsteams, die einen agilen Ansatz wie Scrum oder Kanban verwenden, ist die Festlegung von Prioritäten in dieser Situation von entschei­dender Bedeutung. Und es ist zugleich ein schwierig zu lösendes Problem: Soll das Entwicklungsteam den aktuellen Kunden zufrieden­stellen oder soll es sich auf die Modernisierung des Produkts konzen­trieren, um in Zukunft neue Kunden zu gewinnen?

Ohne eine klare Trennung dieser beiden Ziele entsteht eine Lose-Lose-Situation. Der bestehende Kunde ist unzufrieden, weil man nicht in der Lage ist, sich voll auf seine Bedürfnisse zu konzen­trieren, und die neue Produkt­version kommt später, als man es geplant haben.

INNOVATION BRAUCHT VOLLE KONZENTRATION

Wir wissen, dass der Prozess der Softwareent­wicklung evolutionär sein sollte. Das bedeutet, dass sich das Produkt ständig verändert und verbessert. Unternehmen stehen jedoch oft vor der Situation, dass eine tiefgrei­fende Modernisierung erfor­derlich ist. Wenn diese Modernisierung von demselben Team durch­geführt wird, das sich um die Bedürfnisse der aktuellen Nutzer:innen kümmert, erhält man höchstwahr­scheinlich wieder dasselbe Produkt mit einem anderen technischen Stack.

TRENNUNG DER (TEAM-)ZIELE

Sobald diese Probleme erkannt werden, ist es gut, die Entwicklungsteams neu zu organisieren. Jedes Team sollte sich mit so wenig Themen wie möglich befassen. In diesem Szenario bedeutet das, dass ein Team entweder am Produkt für die beste­henden Kunden arbeiten sollte oder an der Entwicklung der nächsten Produkt­generation, aber nicht an beidem. Dies sorgt nicht nur dafür, dass die Priori­sierung der Arbeit für beide Teams viel einfacher wird. Es reduziert auch die kognitive Last (den “mental load”), die jedes Team bewältigen muss. So kann sich jedes Team auf das konzentrieren, was für das beste Ergebnis erfor­derlich ist.

Im Prozess der Softwareentwicklung geht der Ansatz, Teams nach Zielen zu trennen, sogar noch weiter. Gewöhnlich werden Teams nach Komponenten wie Backend und Frontend getrennt. Diese Trennung hat den Vorteil, dass Menschen mit den gleichen Fähigkeiten in einem Team zusammen­kommen. Daher haben diese Teams eine niedrige Truck Number.

Das Problem dieser Teamkonstella­tion ist jedoch ein sehr hoher Kommunika­tionsbedarf zwischen den Teams, da sie ständig Schnitt­stellen definieren müssen, damit die Komponenten miteinander kommunizieren können. Außerdem weiß keines der Teams, wie das Produkt ganzheit­lich funk­tioniert.

BENUTZERZENTRIERTES TEAM-SETUP

Die Lösung wäre ein Team-Setup, bei dem die Teams nicht nach ihren Fähigkeiten oder nach der Komponente, die sie entwickeln, getrennt sind. Die Trennlinie verläuft vielmehr entlang der Sichtweisen, die die verschie­denen Arten von Benutzern auf das Produkt haben. Dadurch wird sichergestellt, dass jedes Team durchgängig arbeiten und unabhängig von den anderen Teams einen Mehrwert liefern kann.

Darüber hinaus ist die kognitive Last des Teams auf die Anwendungs­fälle des Benutzertyps beschränkt, den das Team anspricht. Die Teammit­glieder müssen die Art und Weise verstehen, wie ihr Benutzertyp mit dem Produkt arbeiten möchte, anstatt jeden Anwendungs­fall zu kennen, den das Produkt bietet.

Durch die Anwendung dieser benutzer­zen­trierten Methodik für den Aufbau des Teams wird der Kommunika­tionsaufwand zwischen den Teams minimiert. Es besteht keine Notwen­digkeit, Schnitt­stellen zwischen den Teams zu definieren und selbst über kleine Änderungen zu sprechen. Das Team kann alle notwendigen Schritte unternehmen, um in jeder Iteration ein besseres Produkt zu liefern.

DIE IDEALE GRÖSSE VON ENTWICKLUNGSTEAMS

Wie bereits erwähnt, ist die Begrenzung der Kommuni­kation zwischen den Teams der Schlüssel zur Effizienz. Daher sollte auch die Teamgröße darauf abgestimmt sein. Die Dunbar-Zahl ist hierbei ein guter Indikator dafür, wie groß ein Software­entwicklungsteam sein sollte. Diese Zahl gibt eine Grenze für die Anzahl von Personen an, mit denen wir enge persönliche Beziehungen und ein gemeinsames “Arbeits­gedächtnis” unterhalten können (Matthew Skelton/Manual Pais: Team Topologies, 2019).

Die Anzahl der Personen, die wir in dem beschriebenen Zuschnitt haben, beträgt etwa 7 bis 9 pro Team. Dies ermöglicht eine geringe kognitive Belastung und einen geringeren Kommunika­tions­bedarf innerhalb der Gruppe.

KOGNITIVE LAST UND KOMMUNIKATIONS­AUFWAND MÖGLICHST GERING HALTEN

Bei der Zusammenstellung von effizienten Teams sollte immer die kognitive Last der einzelnen Teams sowie der Umfang der Kommunikation innerhalb und zwischen den Teams berück­sichtigt werden. Effizienz lässt sich durch eine geringe mentale Belastung und eine benutzer­zentrierte Teamzusammen­setzung erreichen.

Da die Dunbar-Zahl nicht spezifisch für die Software­entwicklung ist, kann die Schluss­folgerung bezüglich der Teamgröße auf jedes Team übertragen werden, in dem die Teammitglieder kommunizieren müssen, was jeweils die anderen tun. Das heißt, die Überlegungen zur Teamgröße sind nicht nur für die Software­entwicklung, sondern auch für andere Unternehmens­bereiche interessant.


Mehr zu Softwareent­wick­lung, Scrum und Co.:

➡ AGILES ARBEITEN: VON SCRUM ZU KANBAN IN 90 MINUTEN
➡ SCRUM: DER SPRINT
➡ DIE/DER SCRUM MASTER:IN
➡ DIE/DER PRODUCT OWNER:IN
➡ EINBLICKE IN UNSERE AGILE ARBEITSWEISE BEI FLS
➡ DEEP DIVE IN DAS SCRUM-ENTWICKLER-TEAM

Lust auf agile Arbeitsweisen und spannende Softwareentwicklung? Zu unserem Karriere-Portal: