Rezept für eine erfolgreiche Software-Entwicklung

Oliver BurkhalterAugust 2019

Wie können Scrum-Werte wie Crossfunktionalität, Selbstorganisation oder Iteration nicht nur die Software-Qualität, sondern auch die Arbeit im Team verbessern? In diesem Artikel möchte ich meine Erfahrungen mit Scrum sowie weiteren Methoden für eine erfolgreiche Software-Entwicklung teilen.

Gute Lösungen entstehen nur in einem guten Team

Ich bin überzeugt, dass gute Lösungen nur in einem gut funktionierenden Team entstehen können. Auch andere Faktoren beeinflussen die Qualität der Lösung. Aber wenn ein Team gut funktioniert, besitzt es die Durchschlagskraft, seine Umgebung zu prägen und für die gegebene Situation die beste Lösung zu finden.

Für mich sind in der Software-Entwicklung folgende Werte zentral geworden:

Crossfunktionalität
Selbstorganisation
Iteration
Inkrement
Integration

Die meisten dieser Werte durfte ich über das Scrum-Framework kennenlernen. Nach meiner Erfahrung können diese Werte die Software-Entwicklung im Gesamten merklich verbessern, zum Beispiel durch höhere Qualität oder durch bessere Zielerreichung.

In den nächsten Abschnitten möchte ich diese Werte und Prinzipien genauer illustrieren.

Crossfunktional, interdisziplinär, fachübergreifend – ganzheitlich

Ein Schlüssel in agilen Projekten sind das Verständnis und die Anwendung von Crossfunktionalität. Zu Projektbeginn definieren wir ein Team, welches das notwendige Wissen mitbringt, um die Anforderungen des zu bauenden Software-Systems umzusetzen. Ich möchte hier zu Projektbeginn unterstreichen. Denn allzu häufig sind die Disziplinen und dadurch die Projektmitglieder über die Projektlaufzeit verteilt. Dadurch erhält man ein künstliches Wasserfall-Modell und trennt die Projektmitglieder voneinander.

Als Beispiel kann ich die Konzeptionsphase eines Projekts nennen. Darin spielen meistens nur Personen aus den Bereichen Business, Konzeption und Design mit. Mit einem Projektleiter hingegen, der ein Verständnis für Crossfunktionalität hat, begleiten Frontend- und Backend-Entwickler/-innen bereits diese Konzeptionsphase.

Developers von Beginn an einbeziehen

Ich empfehle radikal, mit einem crossfunktionalen Team zu starten. Auch wenn man das Gefühl hat, dass die Backend-Entwickler/-innen noch nichts beitragen können. Wenn wir das Prinzip Deliver working software frequently...Working software is the primary measure of progress (Agiles Manifest, Prinzipien) anstreben, dann haben auch Backend-Entwickler/-innen bereits zu Beginn einiges zu tun:

Setup Continuous Delivery and Deployment
Abklärungen mit IT
Core Domain herausschälen, implementieren und mehr

Natürlich macht es keinen Sinn, mit einem crossfunktionalen Team zu starten, wenn das «Warum» und das «Was» noch nicht genügend definiert sind. Das Product-Backlog sollte mit den ersten, wichtigsten Product-Backlog-Einträgen gefüllt sein.

Domain-driven Design

Die Grundsätze des Domain-driven Designs (DDD) kommen hier ebenfalls zum Tragen. Beim DDD arbeiten die Fachexperten eng mit den Entwicklern zusammen. Sie definieren gemeinsam eine Sprache, die ihre Domäne beschreibt und sich in der Software wiederfindet. Dies ist nichts Neues, stellt aber in der Umsetzung immer wieder eine Herausforderung dar. Der Fachexperte kann zum Beispiel Tests schreiben, vorbereiten und durchführen. Und das am Besten kontinuierlich: Anforderung für Anforderung, Sprint für Sprint.

Voneinander lernen

Ein anderer Faktor, der zum Zug kommt, ist das gegenseitige voneinander Lernen. Dieser Lernprozess geht oft vergessen. Er funktioniert nur, wenn das crossfunktionale Team von Beginn an zusammenarbeiten und voneinander lernen kann. Dies ist eine Voraussetzung, wenn man ein hochperformantes Team haben möchte.

Prinzip zum Merken:

Starte mit einem crossfunktionalen Team.

Selbstorganisiert, autonom, selbstständig – gegenseitig ergänzend

Ein weiterer Schlüssel in agilen Projekten ist die Selbstorganisations-Fähigkeit des Teams. Darunter verstehe ich, wie stabil/resilient und selbstständig ein Team ist.

Eine zentrale Frage: Funktioniert das Team weiterhin, auch wenn der Release-Manager, die Architektin oder der Scrum Master fehlt? Hat das Team das Projektwissen breit verteilt und gut kommuniziert?

Oder noch wichtiger: Kann das Team zwischenmenschliche Probleme selbstständig lösen, indem es die schwierigen Punkte ehrlich und offen vorbringt? Herrscht eine Kultur des gegenseitigen Respekts und echter Wertschätzung (Stichwort: Psychological Safety)? Wie gut ergänzen sich die Teammitglieder? Wie hoch ist die Bereitschaft jedes Mitglieds, sich weiteres Wissen anzueignen, damit das Team als Gesamtes widerstandsfähiger werden kann (T-Shaped Professionals)?

Die Rolle des Scrum Masters – befähigen, nicht befehlen

Für den Aufbau dieser Selbstorganisations-Fähigkeit ist vor allem der Scrum Master gefragt. Er ist der Meister für die Etabilerung eines selbstorganisierten Teams. Nicht indem er Befehle gibt, sondern indem er jeden Einzelnen dazu befähigt, sich ins Team einzubringen. Je nach Maturität des Teams muss der Scrum Master es mehr oder weniger in dieser Thematik begleiten.

Hervorzuheben sind die Begriffe Befähigen und Begleiten. Der Scrum Master übt keine Macht gegenüber dem Team aus. Er kann nicht befehlen. Ziel ist nicht, dass die Dinge so gemacht werden, wie er es für gut hält. Das Team soll dies selber herausfinden und sich in seiner Selbstorganisation verbessern. Der Scrum Master kitzelt die Selbstorganisation aus jedem einzelnen Teammitglied heraus. Er fordert das Team mit gezielten Fragen heraus.

Die Retrospektive-Meetings – sich nach und nach verbessern

Wie lernt das Team, selbstorganisierter zu werden? Indem es zum Beispiel regelmässig zurückschaut, sich inspiziert, innehält und gemeinsame Aktionen zur Verbesserung der Zusammenarbeit definiert. Wir nennen diese Gemeinsam-Zurückschauen-Meetings Retrospektive-Meetings. Sie fördern stark die Idee des Continuous Improvement.

Vielfach werden die Retrospektive-Meetings kritisiert: Sie nützten nichts, und man könne sich im Team direkt absprechen und Verbesserungen anbringen. Dem stimme ich zu. Das ist der Idealzustand respektive das Ziel, dass ein Team eine solche Maturität erreicht und sich in Richtung hochperformantes Team bewegt. Aber die Erfahrung zeigt, dass dies nicht immer der Fall ist. Diese regelmässigen Retrospektive-Meetings können einem Team helfen, sich zu verbessern. Schritt für Schritt, Sprint für Sprint.

Die Scrum-Werte spielen für den Erfolg der Retrospektive-Meetings eine zentrale Rolle. Wenn die Teammitglieder nicht bereit sind, Werte wie Mut, Respekt oder Offenheit zu verinnerlichen und zu leben, dann bringen die Retrospektive-Meetings nicht viel. So wird Scrum in seiner Ganzheit nie wirklich zum Leben erweckt.

Prinzip zum Merken:

Fördere wertebasierte Selbstorganisation im Team.

Iterativ, inkrementell – Feedback-getrieben

Für mich steckt hinter dem Begriff iterativ ein tieferes Verständnis von der Zukunft. Es bedeutet: Ich gestehe mir ein, dass wir zum aktuellen Zeitpunkt noch nicht alles wissen. Es hat für mich mit Demut zu tun, zu akzeptieren, dass ich nicht alles vorhersehen kann. Wenn wir iterativ vorgehen, zeigen wir den Mut, eine erste funktionierende Lösung umzusetzen, mit dem Ziel, aktiv von den Endbenutzer/-innen Feedback einzuholen. Wir wollen in kurzen Iterationen den Endbenutzer/-innen eine erste funktionierende Software bereitstellen, die sie anfassen können. Damit können wir das Vertrauen ins Entwicklungsteam festigen.

Früh eine funktionierende Software liefern

Ich betone hier nochmals: funktionierende Software. Es herrscht manchmal das Missverständnis vor, dass man mit Scrum & Co. halb fertige Software liefern darf. Aber das ist überhaupt nicht die Idee. Es geht darum, möglichst früh eine funktionierende Software liefern zu können, also sprich den ganzen Weg des Softwareproduktionsprozesses zu durchlaufen mit allen beteiligten Parteien inklusive Qualitätssicherung und Betrieb bis in die Produktionsumgebung.

Die Idee ist nicht, mit der ersten Version bereits alle erdenklichen Features bereit zu haben, sondern nur die zwei, drei wichtigsten. Für die darauf folgenden Versionen beachten wir die erhaltenen Feedbacks der Endbenutzer/-innen und repriorisieren unser Product-Backlog entsprechend. So kann man der Feature-Verschwendung vorbeugen.

Von Iteration zu Iteration den Mehrwert des Produkts steigern

Diese Philosophie kennt man auch aus der Lean-Production-Ecke: Man versucht möglichst keine Verschwendung zu erzeugen. Oder anders ausgedrückt: möglichst effizient zu sein. Man braucht kein riesiges Backlog, um mit der Entwicklung zu starten. Es reicht völlig, die ersten wichtigsten Product-Backlog-Einträge für die nächsten zwei bis drei Sprints im Detail zu beschreiben. Die später folgenden Einträge können auch nur den Titel enthalten. Der Product Owner bearbeitet in Abstimmung mit dem Team das Backlog. Es entwickelt sich von Iteration zu Iteration weiter.

Diese kontinuierliche und regelmässige Pflege am Backlog inklusive das Feedback-Einarbeiten von aussen schärfen das zu entwickelnde System immer mehr, bis es schlussendlich einen wirklichen Mehrwert für die Endbenutzer/-innen bietet.

Prinzip zum Merken:

Arbeite iterativ, inkrementell und Feedback-getrieben.

Integrativ, zusammenbindend – interdependent

Integrativ zu sein, hat für mich mit klaren Grenzen und klarer Kommunikation zu tun. Komponenten im System werden mit klaren Verantwortlichkeiten definiert, sodass sie möglichst nur eine Aufgabe haben. Die Ausarbeitung dieser klaren Verantwortlichkeiten ist die Basis, damit das System eine hohe Kohäsion sowie eine lose Kopplung aufweisen kann.

Wie gut diese Definition der Verantwortlichkeiten gelungen ist, merkt man oft erst beim Umsetzen von durchgängigen User-Stories. Dann kommen die fachlichen Aspekte, Regeln und Prozesse zum Vorschein, und die Komponenten müssen interdependent funktionieren. Das heisst, die unterschiedlichen Komponenten im System sind voneinander abhängig und müssen fachlich korrekt miteinander kommunizieren können.

Klare Grenzen und Verantwortlichkeiten im System und im Team

Je klarer man diese Verantwortlichkeitsgrenzen für die jeweilige Domäne ziehen kann, desto weniger abhängig sind sie voneinander. Das heisst, eine Komponente kann immer noch funktionieren, auch wenn andere Komponenten ausfallen. Die nicht funktionierenden Komponenten im System versuchen, sich selbstständig wiederherzustellen, damit das ganze System wieder die gesamten Funktionen anbieten kann. Hier spricht man dann von der Resilienz eines Systems: Wie widerstandsfähig ist ein System, wenn einzelne Komponenten ausfallen. Und wie schnell können diese wieder bereitgestellt werden?

Um möglichst gute Verantwortlichkeitsgrenzen zu finden, empfehle ich, auch hier nach den Grundsätzen des Domain-driven Designs vorzugehen und den Komponenten-Schnitt entlang der Domäne zu machen.

Diese Idee von klaren Grenzen und Verantwortlichkeiten ist auch für die Zusammenarbeit im Team wichtig. Je klarer die Rollen im Team geklärt sind, desto effizienter ist es. Integrativ zu sein – bezogen auf die Zusammenarbeit – heisst für mich, dass ich mich als Teammitglied bemühe, Empathie zu üben und die richtige Sprache zu finden, um mit meinen anderen Teammitgliedern ehrlich, offen und transparent kommunizieren zu können.

Prinzip zum Merken:

Schaffe Klarheit über die Verantwortlichkeiten im System und im Team.

Mein Fazit

Ich hoffe, ich konnte die Werte, die mich antreiben, nachvollziehbar darstellen. Vielleicht habe ich auch Sie ermutigt, diese Werte beim nächsten Vorhaben in den Fokus zu nehmen und darüber im Team zu diskutieren.

Ich selber merke immer wieder, wie wichtig es ist, darüber zu reden, wie wir besser gemeinsam Software entwickeln können. In diesen Gesprächen lerne ich auch immer wieder ein Stück mehr über die vielschichtigen Mechanismen der Software-Entwicklung und darf/muss mich korrigieren.

Ich denke, Code zu schreiben und Software zu entwickeln, ist eine zutiefst soziale Kunst, die dann zur optimalen Entfaltung kommen kann, wenn wir besser verstehen, wie wir das gemeinsam tun können. Und dies betrifft aus meiner Sicht alle Ebenen vom Fachlichen über das Technische bis hin zum Sozialen.

In dem Sinne schliesse ich mit: Love your teammates and love your code.