Warum tun sich Produktteams mit dem Betrieb ihres Produktes so schwer?

Die moderne Software-Entwicklung hat sich die letzten 20 Jahre deutlich verändert. Neue Strömungen, wie agile Software-Entwicklung, Software Craftsmanship, Site Reliability Engineering und DevOps haben Einzug gehalten. Auch die Technologien haben sich massiv weiterentwickelt. Wurde früher auf Bare-Metal-Server oder, in modernen Unternehmen, virtuelle Maschinen gesetzt, kommen heute vermehrt containerisierte Plattformen zum Einsatz. Dies führte zu einer veränderten und deutlich höher frequentierten Form der Lieferungen. Monolithen, die quartalsweise manuell auf einer virtuellen Maschine mit einem Tomcat oder Apache httpd ausgerollt wurden, gehören in den meisten Fällen der Vergangenheit an. Auch manuelle Konfigurationen an Serversystemen kommen immer seltener vor. Stattdessen werden mehrere Lieferungen am Tag vollautomatisiert via CI/CD-Pipelines in Produktion gebracht. Änderungen an der Infrastruktur werden durch Infrastructure as Code und GitOps vollzogen, Konfigurationen als YAML-Files in git eingecheckt.

Cloud-Native ist angesagt. Dies bringt auf der einen Seite neue, spannende Herausforderungen mit sich, auf der anderen Seite gehen klassische Arbeitsweisen im Grundrauschen des schrillen Marketings von Produktherstellern und Beratungsunternehmen unter.

In diesem Artikel erfährst du die Hintergründe, warum Produktteams bei Standardaufgaben, wie dem Betrieb eines Softwareproduktes, so oft ins Schwimmen geraten.

Die Komplexität heutiger Softwareentwicklung

Die CNCF-Landkarte, eigentlich ein gut gemeintes Werkzeug, um den Überblick zu behalten, zeigt das volle Ausmaß der heutigen Probleme bei der Produktentwicklung:

Quelle: https://landscape.cncf.io/images/landscape.png, abgerufen am 08.10.2022

Neben der unüberschaubaren Menge an Tools, die potenziell für den modernen Entwickler wichtig sind, kommt zusätzlich die geringe Halbwertszeit der eingesetzten Lösungen. Kaum ist eine Lösung etabliert, schon gehört sie zum alten Eisen und wird durch etwas „noch viel besseres“ ersetzt. Wobei „besser“ leider in den meisten Fällen nur „anders“ bedeutet. Es gibt kaum die Möglichkeit, sich über mehrere Jahre zum Experten auszubilden.

Um dieser Komplexität Herr zu werden, versuchen viele Unternehmen, diesen Umstand mit sogenannten Produktteams zu bekämpfen.

Was ist ein Produktteam? Eine einfache Definition.

Ein Produktteam zeichnet sich durch eine wichtige Eigenschaft aus: Es ist sowohl für die (Weiter-)Entwicklung als auch für den Betrieb eines Produktes oder eines Services verantwortlich. Ein Produkt kann dabei eine selbstentwickelte Software, eine Plattform oder ein bereitgestellter Service sein. Dabei deckt das Team mit seinen Mitgliedern, soweit leistbar, alles relevante Wissen und die nötige Erfahrung ab, um seine Aufgaben zu erfüllen. Es arbeitet auf Basis der zwölf agilen Prinzipien in einem flexiblen Modus zusammen, um schnell auf Veränderungen reagieren zu können.

Warum ist diese Art von Produktteam interessant?

Um die Stärken der Produktteams mit ihrer Ende-zu-Ende-Verantwortung zu verstehen, lohnt sich einen Blick auf die drei DevOps-Prinzipien zu werfen und zu prüfen, ob und wie Produktteams diese erfüllen:

DevOps-Prinzip #1: Flow/Systems Thinking

Das Prinzip des Flow bzw. das System Thinking besagt, dass wir den gesamten Wertstrom (Value Stream) im Blick haben sollen, also den Weg von einer Anforderung, die ins System hereinkommt, bis zum fertig umgesetzten Feature, das in Produktion ausgerollt ist. Das Produktteam vereint alle Rollen und Verantwortlichkeiten in einem Team, sodass über den Software-Entwicklungsprozess jedem jederzeit klar ist, welche Anforderung sich an welcher Stelle im System befindet und wann es in Produktion geht.

DevOps-Prinzip #2: Amplify Feedback Loops

Wenn ein Team die Ende-zu-Ende-Verantwortung für ein Stück Software hat, dann hat es genau einen Vorteil: Es hat direkten Kontakt zum Kunden, sei es über direkte Gespräche mit dem Kunden oder über indirekte Kanäle, wie Bug- oder Support-Tickets, die Kunden bei dem Produktteam einstellen können. Diese Form von Feedback hilft dem Team wiederum, den Kunden besser kennenzulernen, die Beweggründe zu verstehen und sein eigenes Handeln danach auszurichten. Durch diese Form der Feedback-Schleife gewinnt das Team Sicherheit und liefert Anforderungen in einer höheren Qualität aus.

Aber auch innerhalb des Teams bekommen die Teammitglieder viel schnelleres Feedback, da sie einzelne Schritte gemeinsam oder nacheinander durchführen müssen. Die direkte Kommunikation zwischen den Teammitgliedern hilft dabei, schnelles Feedback zu geben und die gemeinsame Arbeitsweise sukzessive zu verbessern.

DevOps-Prinzip #3: Culture of continual experimentation and learning

In der schnelllebigen Wirtschaftswelt, oft als VUCA-Welt (volatility, uncertainty, complexity, ambiguity) bezeichnet, hat es sich bewährt, ständig am Ball zu bleiben. Wie bereits oben erwähnt, ändern sich die Technologien, die Anforderungen und die Rahmenbedingungen in immer schnellerem Maße. State-of-the-art-Technologien sind morgen „Kram von gestern“, Kundenwünsche ändern sich und neue Mitbewerber betreten die Bühne. Selbst in einem stabilen Umfeld kann es wichtig sein, Experimente durchzuführen, um beispielsweise die Sicherheit beim Betrieb zu erhöhen, adäquat auf Desaster-Szenarien vorbereitet zu sein oder frühzeitig den Absprung von einer ausgemusterten Technologie zu schaffen. All diese Tätigkeiten zahlen darauf ein, zukünftige Krisen und bestehende Risiken zu entschärfen.

Das Produktteam erfüllt dieses Prinzip, indem es aktiv die Feedbacks der Kunden beachtet, sich daran ausrichtet und sich regelmäßig darüber austauscht, an welchen Stellen es weiteren Verbesserungsbedarf gibt, zum Beispiel durchs Ausprobieren einer neuen Technologie, eines neuen Betriebsprozesses oder durch Einführung guter Praktiken wie Test Driven Development oder Chaos Engineering.

Welche Alternativen gibt es zum Produktteam?

Natürlich ist das Produktteam kein Allheilmittel. Wir gehen später noch darauf ein, an welchen Stellen Produktteams meistens scheitern oder zumindest in Schieflage geraten. Es gibt zwei gleichwertige, populäre Ansätze, die die Ende-zu-Ende-Anforderung erfüllen:

Software-Entwicklungsteams arbeitet eng mit einem Site Reliability Engineering Team zusammen

Google und einige andere moderne Unternehmen setzen auf sogenannte Site Reliability Engineering Teams (SRE-Teams), die den Betrieb und den Support der Services verantworten. Diese arbeiten eng mit den Entwicklungsteams zusammen. Auch wenn es die ganze Magie von dem schönen Wort „Site Reliability Engineering“ wegnimmt: SRE-Teams sind die moderne Interpretation der klassischen Betriebsteams. Sie bekommen von einem Entwicklungsteam ein Stück Software übergeben, das sie in Produktion bringen und dort verwalten. Dabei setzen SRE-Teams im Vergleich zum klassischen Betrieb vermehrt auf Automatisierung, auf einfache, wirkungsvolle KPIs wie Service Level Indicators (SLI) und Service Level Objectives (SLO) und sie dienen als letzte Entscheidungsinstanz für die Inbetriebnahme von Produktinkrementen. Das SRE-Team entscheidet, wann eine Software in Produktion gehen darf, die Bringschuld und Verantwortung für die Betreibbarkeit trägt das Entwicklungsteam.

Entwicklungsteam übergibt Produktinkremente einem klassischen Betrieb, der sie in Betrieb nimmt

Der klassische Betrieb unterscheidet sich von SRE-Team darin, dass es weniger auf standardisierte Prozesse, KPIs und die Automatisierung konzentriert. Vielmehr sind hier Eigeninitiative, technisches Know-How und eine individuell geregelte Zusammenarbeit mit den Teams gefragt. Leider trifft man hier oft auf virtuelle Mauern, die sich zwischen den Entwicklern und dem Betrieb gebildet haben. „Software über den Zaun werfen“ ist ein schönes Bild für die Zusammenarbeit.

Wie man merkt, unterscheiden sich diese beiden Alternativen vom Grundkonzept gar nicht so sehr voneinander. Einzig die jeweilige Arbeitsweise und die Stellung im Gesamtsystem unterscheidet sich. Beim SRE-Team muss das Entwicklungsteam die Qualität und Betreibbarkeit nachweisen, beim klassischen Betrieb bestimmt oft die Hierarchie, wann etwas fertig ist und der Betrieb muss dann die Suppe auslöffeln.

Da es oft anders dargestellt wird, ist es mir wichtig, noch einmal hervorzuheben: Beide Alternativen sind „DevOps-Konform“, wenn die darunterliegenden Prinzipien adäquat umgesetzt werden, heißt, die Teams eng zusammenarbeiten und an einem Strang ziehen, sich untereinander austauschen und Teamübergreifende Experimente zur Verbesserung der Gesamtsituation durchführen.

Welche Herausforderungen muss ein Produktteam meistern?

Kognitive Überlastung des Teams

Ein Team hat ein Limit, wie viele Informationen es zu einem bestimmten Zeitpunkt in den Köpfen der Teammitglieder halten kann. Das bedeutet, das Team kann eine bestimmte Menge unterschiedlicher Technologien und Aufgabentypen, Komplexität der Architektur und Abläufe, sowie fachlichem Domänenwissen verarbeiten und dieses gezielt einsetzen. Es gibt in jedem Team einen Punkt, an dem es zu einer Überlastungssituation kommt. Dann wird die Arbeit chaotisch, es gibt zu viele Kontextwechsel, die Arbeit verlangsamt sich massiv und die Fehlerrate springt enorm.

Zu viele Abhängigkeiten

Moderne Produktentwicklung findet meistens nicht im luftleeren Raum statt. Heutzutage sind große Programme und die Transformation zu agilen Organisationsformen an der Tagesordnung. SAFe, LeSS und das Spotify Modell sind allgegenwärtig. Damit steigen auch die Abhängigkeit zu anderen und die gemeinsame Arbeit wird komplizierter.

Ungeplante Aufgaben

Die meisten Produktteams bieten durch die Betriebsverantwortung zwangsläufig neben der Softwareentwicklung noch verschiedene Services an, unter anderem Third-Level-Support für die Anwender und Ansprechpartner für Nachbarteams. Dazu muss das Team Betriebsthemen leisten, wie

  • Lifecycle Management aller eingesetzten Komponenten,
  • Schwachstellenmanagement,
  • Secrets Management,
  • Incident- und Problemmanagement,
  • Desaster Recovery-Prozesse und Szenarien,
  • Kommunikationskanäle im Notfall,
  • konstruktives Monitoring und Alerting des Systems, sowie
  • Bereitschaftsdienst, teilweise 24/7.

Neben den Anwendern gibt es weitere Stakeholder, unter anderem der Cloud-/Plattform-Anbieter, die Compliance- und Security-Abteilung, das Enterprise Architektur Management und ähnliche. Diese Stakeholder haben die unangenehme Eigenschaft, dass deren Anforderungen in der Regel als wichtig und dringend eingestuft werden, was gerne einmal einen oder mehrere Sprints/Iterationen verhagelt.

Und wie sieht die Realität aus?

Ich treffe immer wieder auf Softwareteams und Software-Entwickler, die keine Ahnung haben, wie sie einen Betrieb auf die Beine stellen können. Das fängt damit an, dass die Teams nicht einmal wissen, was alles für einen seriösen Betrieb geleistet werden muss und wie dies bewerkstelligt, werden kann; ein schlechter Startpunkt für die Auswahl an Tools und die Standardisierung und Automatisierung der Tätigkeiten. Auch viele Product Owner und Führungskräfte haben darin keine Erfahrungswerte. Sie sehen diese Aufgaben oft als lästige Zusatzaufgabe, die möglichst wenig Aufwand in Anspruch nehmen soll. Deshalb verfolgen diese Teams dann eine der drei folgenden Strategien:

  1. Angreifen: Bei der Strategie „Angreifen“ ist Aktionismus gefragt. Es werden DevOps-Tools eingekauft, deren Marketing ein Wunder verspricht und Experten gesucht, die das Problem lösen sollen. Ziel der Strategie ist es, schnelle, einfache Lösungen zu finden, statt sich ernsthaft mit dem Thema auseinandersetzt und nachhaltige Lösungen zu schaffen.
  2. Weglaufen: Bei der Strategie „Weglaufen“ versucht das Team, die Betriebsverantwortung an jemand anderes abzutreten. Die gesamte Energie wird investiert, durch Eskalationen und ähnliche Maßnahmen, die Verantwortung im Nachhinein loszuwerden. Die Strategie ist dann erfolgreich, wenn ein SRE- oder ein klassisches Betriebsteam eingeführt wird, dass dem Produktteam diese Aufgabe abnimmt. Man landet dadurch bei einer der beiden oben genannten Alternativen, die zusätzliche Abhängigkeiten bedeutet. Die Erfolgswahrscheinlichkeit ist allerdings gering. Spätestens dann, wenn ein SRE-Team Anforderungen bezüglich der Betreibbarkeit stellt, muss das Entwicklungsteam dennoch den Aufwand investieren.
  3. Totstellen: Bei der Strategie „Totstellen“ geht es darum, abzuwarten, bis der Kelch am Team vorübergezogen ist oder jemand anderes das Problem gelöst hat. Man beobachtet, was die Angreifer und Weglaufenden erreichen und schließt sich dem Gewinner an. Damit spart man sich viel Aufwand, der Betriebsverantwortung für das eigene Produkt kann man damit allerdings nicht adäquat nachkommen. Und noch viel wichtiger: Man ist vollständig abhängig davon, dass das andere Team sinnvolle und vor allem passende Lösungen schafft. Und das ist leider nie der Fall.

Ich habe bereits einige Jahre in und mit solchen Produktteams gearbeitet und muss sagen, dass es sich die Arbeitsweise, sowohl die Entwicklung als auch den Betrieb zu übernehmen, deutlich besser anfühlt als die traditionelle Software-Entwicklung, bei der man einem anonymen Betrieb sein Produkt über den Zaun wirft. Deshalb gehen wir jetzt auf die Probleme ein, die Produktteams treffen, wenn sie sich ernsthaft mit dem Betrieb auseinandersetzen wollen.

Problem #1: Betriebsthemen sind lästig

Ich habe mich in der Vergangenheit mit vielen Entwicklern über das Thema Betrieb ausgetauscht. Die Entwickler wollen vor allem neue, fachliche Features entwickeln und großartige neue Technologien ausprobieren. Sie haben in der Regel keine Lust auf 24/7 Betrieb, Support-Themen, Wartung und Instandhaltung des Produkts. Deshalb herrscht eine starke Ablehnung, die es aufzubrechen gilt.

Problem #2: Fehlende Erfahrung und Glaubenssätze

Viele Entwickler haben nie gelernt, was genau für einen ordentlichen, gut organisierten Betrieb wichtig ist und welche Zahnrädchen es gibt, die ineinandergreifen müssen. Die Produktpräsentationen auf Konferenzen und Messen verstärken dieses Problem nur noch weiter. Wenn man sich dort, wie es üblich ist, die blank polierten und schön aufbereiteten Optimal-Use-Cases für ein „DevOps-Tool“ anschaut, wirkt es immer so, als sei das alles super einfach. Sobald man das Tool dann selbst im Einsatz hat, merkt man, wie aufwändig und wenig Zielführend das Ganze ist, wenn man die Basics dahinter nicht versteht. Und man merkt, wie wenig die Produkthersteller ihre Kunden verstehen.

Beispiele gefällig? Hier ein paar aus meinem Alltag:

  • Wie soll ich ein Monitoring-Tool konfigurieren, wenn ich nicht weiß, was ich genau sehen will bzw. sehen muss, um den Betrieb zu bewerkstelligen?
  • Wie soll ich ein Alarmsystem einrichten, wenn ich nicht weiß, welche Metriken ich betrachten muss und welche Schwellwerte kritisch sind?
  • Wenn mein Alarmsystem anschlägt: Was muss ich dann eigentlich tun?
  • Wie stelle ich sicher, dass die Produkte, die ich betreibe, keine bekannten Schwachstellen haben?
  • Oh, das Tool ist nicht Mandantenfähig? Das müssen wir beim Hersteller einfordern. Wir zahlen schließlich Geld dafür.

Dadurch entstehen Glaubenssätze wie

  • In meinem Unternehmen können wir kein vernünftiges Monitoring einführen, weil wir die Software-as-a-Service (SaaS)-Lösung XY nicht einsetzen dürfen.
  • Der Betrieb meines Produktes ist chaotisch und behindert mich bei der Weiterentwicklung des Produktes.
  • Ich brauche echte Experten, die den Betrieb machen. Ein einfacher Entwickler kann das in der heutigen Zeit nicht.

Meine Erfahrung ist, dass man die meisten Betriebsthemen in Produktteams mit dem Einsatz der richtigen Werkzeuge zu einer Arbeit machen kann, die ein dressiertes Äffchen ohne Probleme bewerkstelligen kann, die also nebenbei geschieht. Dafür sind allerdings eine gute Vorbereitung und ein Wissensaufbau notwendig. Wie das geht, zeige ich an anderer Stelle.

Problem #3: Ständig wechselnde Tools, keine Konstanz in der Arbeit

Neben der schieren Menge an Tools, die ich weiter oben bereits angesprochen habe, ist eine weitere Herausforderung für Produktteams, dass sich die Produkte ständig wandeln.

Dieser Teufelskreis sieht folgendermaßen aus:

Wie viele Entwickler versuchen krampfhaft, ihr Java-Wissen auf JavaScript oder Go anzuwenden, obwohl beide Sprachen auf völlig anderen Konzepten basieren und eigentlich komplett neu erlernt werden müssten? Wie viele Datenbankexperten versuchen krampfhaft, ihre SQL-Erfahrung auf NoSQL-Datenbanken anzuwenden? Wie viele VM-Experten versuchen Container in einer ähnlichen Weise zu betreiben?

Ich kann sagen: In den letzten 10 Jahren habe ich sehr viele solcher Kollegen erlebt.

Stackoverflow-Entwicklung ist angesagt: Entwickler kämpfen, wie bereits erwähnt, oft mit Problemen und Ungereimtheiten der eingesetzten Frameworks, Sprachen und Bibliotheken. Sich in die Benutzung diese Frameworks und Bibliotheken intensiv einzuarbeiten ist für die Entwickler unwirtschaftlich, weil die Entwickler gelernt haben, dass bald die nächste Sau durchs Dorf getrieben wird. Spätestens dann ist das ganze Wissen über das Framework oder die Bibliothek obsolet. Wer schon einmal Java EE entwickelt hat, dann auf Spring Boot und später auf Quarkus umsteigen musste, weiß wovon ich rede. Für alle JavaScript Entwickler: Von Angular über vue.js nach React.

Der einfachste Ausweg ist es, die Probleme mithilfe von Google zu lösen. Und in den Top 5 findet sich fast immer ein Stackoverflow-Artikel, der, mehr oder weniger akkurat, eine Lösung anbietet. Diese wird meist, ohne größere Prüfung, einfach übernommen. Ob die Qualität passt, man sich vielleicht sogar Sicherheitslücken in sein System reißt, wird leider nicht bedacht. Schlimmer noch: Meist ist der Entwickler gar nicht mehr in der Lage zu verstehen, was die Lösung macht, da er unter Zeit- und Termindruck steht.

Problem #4: Flexibilität des Teams vs. Vollauslastung/Effizienz – Zwei Welten prallen aufeinander

Die erste Welt: Produktteams müssen heute in der Lage sein, eine große Bandbreite an Aufgabentypen und Technologien zu beherrschen. Um dies zu leisten, müssen sie interdisziplinär aufgestellt sein, um flexibel alle Anforderungen erfüllen zu können, die an sie gestellt werden. Moderne Teams bestehen schon lange nicht mehr nur aus Software-Entwicklern. Sie bestehen heute aus Backend-Entwicklern, Frontend-Entwicklern, Business-Analysten, DevOps-/Cloud-Engineers, CI/CD-Spezialisten und vielen weiteren Rollen. Gleichzeitig sollten Team, um schlagkräftig zu sein, eine bestimmte Größe nicht überschreiten. Scrum spricht von maximal 10 Teammitgliedern, Miller’s Zahl bestimmt 7 +/- 2 Teammitglieder als optimale Größe, in der die Kommunikation noch sinnvoll bewerkstelligt werden kann. Warum das so ist und welche Probleme das verursacht komme ich an anderer Stelle zu sprechen.

Die zweite Welt: Wir möchten möglichst das gesamte Team auslasten, um die maximale Effizienz zu erreichen. Das Problem: Features und neue Aufgaben richten sich nach den Kundenwünschen, nicht nach der Zusammenstellung des Teams. Und auch die Zusammenstellung des Teams ist nicht stabil: es gibt Ausfälle im Team, zum Beispiel durch Krankheit, Urlaub und Fluktuation, und auch durch Situationen, bei denen Experten temporär aus dem Team abgezogen und woanders eingesetzt werden. Davon abgesehen gibt es immer wieder Iterationen, in denen die Weiterentwicklung primär im Frontend oder Backend stattfindet und dadurch Teile des Teams nicht ausgelastet sind. Von Product Ownern und Entwicklern habe ich schon folgende Sprüche gehört:

  • „Und was soll ich den ganzen Sprint lang machen?“
  • „Aber wenn ich mein Team nicht auslaste, dann kommen wir ja nicht schnell genug weiter.“
  • „Wie kann ich meine Teammitglieder einigermaßen sinnvoll beschäftigen?“

An anderer Stelle werden wir im Detail darauf eingehen, da es aus meiner Sicht eines der wichtigsten Themen produktiver Arbeit im Team ist. Hier nur vorweg:

Diese Aussagen zeigen, dass Outcome mit Output verwechselt werden. Statt sich auf den Wert zu konzentrieren, den das Team liefern soll und das Team darauf auszurichten, versucht man die Menschen irgendwie zu beschäftigen, um irgendeine Form des Outputs zu generieren.

Problem #5: Betriebsprozesse lassen sich schlecht in bestehende Entwicklungsprozesse integrieren

Viele Teams arbeiten nach einem iterativen Vorgehensmodell wie Scrum oder Kanban. In ihrer Reinform für die Software-Entwicklung haben diese Vorgehensmodelle massive Probleme damit, Betriebsprozesse adäquat abzubilden.

Folgt man dem Scrum-Guide, findet man keine nützliche Lösung dafür, wie Betriebsthemen behandelt werden können. Deshalb stellen sich im Scrum-Umfeld immer wieder folgende und ähnliche Fragen:

  • Müssen wir das als User Story (oder andere Form von Backlog Item) erfassen oder läuft das nebenher?
  • Wie können wir Betriebsthemen tracken?
  • Wie planen wir Betriebsthemen ein?
  • Wie schätzt man eigentlich eine User Story, die einen Standard-Betriebsprozess abbildet?
  • Wie formuliert man eigentlich Backlog Items, z.B. User Storys, die ein Betriebsprozess abbilden?
  • Welchen Kundennutzen liefern wir, wenn wir Betriebsprozesse durchführen?

Kanban wird immer wieder als valide Alternative für Betriebsteams gesehen. Allerdings ist Kanban in der gelebten Form in Software-Entwicklungsteams nur bedingt dazu geeignet, sowohl die Entwicklung als auch die Betriebs- und Support-Themen zu erfassen. Die Gefahr bei Kanban ist, dass das Team in der Weiterentwicklung stagniert, weil es nur noch Betriebsthemen macht. Fragen, die mir in diesem Umfeld gestellt werden, sind z.B.:

  • Wie stellen wir eigentlich ein gutes Gleichgewicht zwischen Entwicklung und Betrieb her?
  • Wie verlieren wir bei der stupiden Abarbeitung von Tickets den Kundennutzen nicht aus den Augen?
  • Wie können wir einen Verbesserungsprozess etablieren, bei dem wir aus den bearbeiteten Tickets lernen und uns kontinuierlich anpassen und verbessern können?
  • Wie schaffen wir es, nicht in einen reaktiven Modus zu verfallen, bei dem die neuen Themen, die uns von der Seite treffen immer oben im Backlog landen und andere, wichtige Themen im Backlog vergammeln?

Die hier gestellten Fragen bilden nur die Spitze des Eisbergs. Wie du diese Probleme angehen kannst und nicht nur Symptombekämpfung, sondern nachhaltige Verbesserungen und Anpassungen herbeiführen kannst, zeige ich dir an anderer Stelle.

Fazit

Produktteams sind ein erprobtes und gut geeignetes Mittel, den Herausforderungen moderner Software Entwicklung Herr zu werden. Sie sind allerdings kein Allheilmittel. Die Teams, die verstehen, dass moderne Software-Entwicklung mehr ist als nur die Benutzung einiger Tools und einfaches herum coden, können damit sehr erfolgreich werden. Sie müssen nur bereit sein, über ihren Tellerrand zu schauen und die oben genannten Probleme auf ihre Art zu lösen.

Wie du diese und ähnliche Probleme nachhaltig und unter Einhaltung aller euch umgebender Rahmenbedingungen effektiv lösen könnt, zeige ich euch gerne in Form von Blog-Beiträgen, Online-Kursen und Erfahrungsberichten.