Software-Bauhaus-Konzept: One Team to build it all

Individualsoftware zu entwickeln, ist im Prinzip sehr einfach, oder? Alles, was es dazu braucht, sind schließlich nur eine klar formulierte Idee und ein qualifiziertes Team an Expert:innen, um diese umzusetzen. Und Dank leichtgewichtiger, agiler Entwicklungsmethoden braucht es dazu nicht einmal mehr Wochen und Monate der Planung und Spezifikation. Schöne neue, agile Welt.

Stellen wir uns beispielhaft das junge, innovative Startup „Green Leaves“ vor. Die beiden zwei Gründer:innen Svenja und Lars haben die Vision, mit einer einzigartigen Anwendung, die Pflege von Grünpflanzen in Städten zu revolutionieren. Dank eines gut dotierten Innovationspreises haben die beiden nun die besten Voraussetzungen, ihre Idee möglichst schnell in die Tat umzusetzen. Für die Entwicklung ihrer neuartigen Onlineplattform wollen die beiden keine Kosten und Mühen scheuen, um die erfahrensten Personen anzuheuern.

Also suchen sie zunächst einen Systemarchitekten, Senior Backend- und Frontend-entwickler:innen, einen Scrum Master und zwei erfahrene Tester:nnen. Zwar stammen aufgrund der kurzfristigen Verfügbarkeit alle von unterschiedlichen Dienstleistern, dafür ist jede:r einzelne von ihnen hochqualifiziert und erfahren. Fertig ist es – das hochperformante Scrum-Team.

Den Product Owner beauftragen sie wohlüberlegt nicht extern, sondern stellen ihn selbst: Lars übernimmt die Aufgabe. Schließlich kennt niemand die fachliche Domäne und die Vision besser und die Lehre besagt schließlich auch, dass ein Product Owner idealerweise der Kunde selbst ist. Lars präsentiert dem frisch zusammengestellten Scrum-Team die Produktvision, übersetzt die Anforderungen in User Storys und schon in wenigen Sprints wird es dann soweit sein: Das potentially shippable product wird das Licht der Welt erblicken. Oder auch nicht…

Wer schon einmal ein Softwareprojekt begleitet hat, weiß, ganz so einfach ist es in der Praxis nicht!

Herausforderungen bei der Arbeit mit Softwareentwicklungsdienstleistern

Bei der Arbeit mit dem neuen Team hakt es an vielen Stellen. Regelmäßig schaffen es bspw. die bearbeiteten User Storys nicht durch die Abnahme. Offensichtlich lassen die Akzeptanzkriterien Raum für Interpretation, denn Lars hatte sich bei einigen Features etwas ganz anderes vorgestellt als das, was von den Entwickler:nnen umgesetzt wurde. Aus ihrer Sicht hingegen wurden wichtige Sonderfälle und alternative Szenarien nicht genau genug spezifiziert.

Auch die Tester:innen sind mit der Qualität der Software nicht zufrieden – sie finden zahlreiche Bugs, da offenbar Frontend und Backend nicht fehlerfrei ineinander greifen. Auch mit dem Entwicklungsprozess als solchem sind sie unzufrieden. Sie würden gerne schon früher aktiv werden als erst kurz vor der Abnahme der Storys.

Nach mehreren Sprints herrscht Ernüchterung bei Green Leaves. Die Gründer:innen müssen feststellen, dass das Team aus Expert:innen bei weitem nicht soweit gekommen ist, wie von ihnen erhofft. Die ursprünglich geplante Roadmap ist überholt, das Go-Live rückt in weite Ferne und die Stimmung im Scrum-Team ist am Boden. Aber was genau lief hier schief? Schließlich wurden für das Team nur die Besten der Besten angeheuert.

Dieses Beispiel macht, wenn auch überspitzt, ein paar grundlegende Probleme und Risiken deutlich, die bei der Vergabe von Softwareprojekten häufig auftreten:

• Ein Scrum-Team ist nur so stark, wie sein schwächstes Mitglied und eine Gruppe von Expert.innen garantiert nicht automatisch ein hohes Outcome.

Ein wirklich hochperformantes Team ist vor allem eines: eingespielt. Erst wenn die Mitglieder sich und ihre Arbeitsweise kennen, einander vertrauen und wissen, wo die Stärken und Schwächen der jeweils anderen liegen, können Arbeitspakete realistisch geschätzt, schnell geplant und effizient umgesetzt werden.

• Auch das Zusammenspiel von Expert:innen benötigt Zeit.

Zeit, die unsere ExpertInnen höchstwahrscheinlich noch nicht miteinander verbringen konnten. Bis sie die erwarteten Ergebnisse erzielen, müssen erst einmal einige Sprints und deren Retrospektiven absolviert werden. Denn wie in jedem anderen Kontext auch, durchläuft ein Entwickler:innen-Team die üblichen Phasen des Stormings & Normings bis es tatsächlich „hochperformant“ arbeiten kann.

• Das Ausfallrisiko liegt beim Auftraggeber bzw. der Auftraggeberin.

Fällt ein Teil des neu formierten Teams durch Krankheit oder Kündigung aus, muss Ersatz gefunden werden und der Teambuildingprozess beginnt von neuem. Stagnierende Velocity, Moving Targets und Frustration im Team sind dann oft die Folgen. Das Ausfallrisiko trägt in solchen Fällen häufig der Auftraggeber bzw. die Auftraggeberin.

• Der Faktor Zeit und methodische Expertise auf Seiten der Auftraggebenden

Die Idee, dass der Product Owner durch die oder den Auftraggebenden gestellt wird, ist natürlich grundsätzlich eine gute. Denn schließlich kennt und versteht diese:r die eigene Idee, die Vision und eventuell auch die fachliche Domäne am besten.

Problematisch daran ist häufig der Faktor Zeit. Product Owner zu sein, also „Produkterfolg zu verantworten“, ist ein Vollzeit-Job. Gerade in den frühen Phasen eines Softwareprojekts ist es für ein Entwicklerteam wichtig, permanent eine:n Ansprechpartner:in auf der Fachseite zu haben.

Zudem braucht es für die Aufbereitung, Planung und Abnahme der Arbeitspakete neben einer fachlichen auch eine methodische Expertise: “

• „Wie präsentiere und schärfe ich die Produktvision?“
• „Wie finde und spezifiziere ich werthaltige, umsetzbare User Storys?“
• „Wie sehen hilfreiche Akzeptanzkriterien aus?“

Besonders dann, wenn die Idee noch sehr frisch und unklar ist, braucht ein Product Owner auf diese und andere Fragen gute Antworten. Die Realität zeigt: Zeitliche Verfügbarkeit und methodische Expertise sind oft nicht ausreichend vorhanden. Und das Risiko? Das liegt einmal mehr bei den Auftraggebenden.

Ein Team von der Idee bis zur Wartung

Nach inzwischen zehn Jahren Erfahrung als Dienstleister im Softwarebereich war unser ehrgeiziges Projekt als QualityMinds, auf eben diese Herausforderungen eine adäquate Antwort zu geben. Unser Software-Bauhaus-Konzept setzt exakt an diesen Problemen an.

Der Grundgedanke folgt dabei der Philosophie des namensgebenden und von Walter Gropius 1919 gegründeten Bauhauses:

Funktionales Design im Sinne der NutzerInnen erwächst aus der handwerklich versierten, interdisziplinären Zusammenarbeit.

Das bedeutet für uns: Wir stellen Auftraggeber:nnen ein komplettes, eingespieltes Team zur Seite und begleiten von der ersten Idee bis hin zur Inbetriebnahme und Wartung. Auf diesem Weg unterscheiden wir grundsätzlich zwischen einer Discovery- und einer Buildphase.

In erstgenannter erkunden wir zusammen mit Kunden deren Idee und stellen mit Hilfe bewährter Methoden aus UX, sowie klassischem und agilem Requirements Engineering sicher, dass diese auch reif genug für eine Umsetzung ist. Sobald das der Fall ist, leiten wir aus den Ergebnissen ein initiales Backlog ab und starten in der Buildphase mit der Umsetzung; immer soweit und solange der Kunde das möchte.

Das Versprechen dabei lautet: Zu jedem Zeitpunkt der Entwicklung stellen wir sicher, dass im Team die richtigen Leute miteinander arbeiten.

Für unser Beispiel der Green Leaves könnte ein Bauhaus-Szenario folgendermaßen aussehen:

Zusammen mit Svenja und Lars veranstalten wir einige Discovery-Workshops. Hier „kneten“ wir ihre Idee, das heißt, wir spielen die verschiedenen Haupt- und Ausnahmeszenarien durch, ermitteln wichtige System-Constraints, identifizieren potenzielle Risiken und skizzieren mögliche Lösungen hinsichtlich eines geeigneten User-Interfaces.

Dabei ist uns wichtig, nicht auf einen speziellen Technologie-Stack fixiert zu sein. Eine geeignete Wahl treffen wir erst dann, wenn wir das Problem durchdrungen haben. Alle Teammitglieder und deren Perspektive werden von Anfang mit einbezogen, um eine möglichst ganzheitliches „Big Picture“ zu schaffen. Unser Ziel ist es dabei, die Vision von Svenja und Lars auch zu unserer eigenen zu machen. Denn unserer Erfahrung nach liefern wir immer dann die bestmögliche Arbeit, wenn wir uns mit dem Produkt auch selbst identifizieren können.

Trotzdem begrüßen wir die Entscheidung von Lars, die Rolle des Product Owners selbst zu übernehmen. In diesem Fall verstehen sich unsere Expert:innen für Requirements Engineering und UX als eine Art Sparring Partner für Lars, die ihm mit Methoden wie User Story Mapping, Specification by Example oder Story Splitting Heuristics zur Seite stehen und dabei helfen, werthaltige Stories zu schreiben und die Product Roadmap zu planen. Dabei stellen sie sicher, dass sie stets bereit sind, im Zweifelsfall für ihn einzuspringen und die Fachseite dem Team gegenüber zu vertreten, sollte Lars selbst einmal nicht verfügbar sein.

Aber auch wenn er und Svenja im Verlauf der Entwicklung mit anderen Themen beschäftigt sein sollten, halten wir die Kommunikation zwischen ihnen und dem Team stets aufrecht. Bei voller Transparenz über den Fortschritt entscheiden sie zu jedem Zeitpunkt, was für ihr Produkt den meisten Wert stiftet. Anders als sonst müssen sie sich dabei um Personalien keine Gedanken machen. Um Ausfallsicherheit und das richtige Know-how im Team kümmern wir uns – immer mit der Garantie: Dieses Team kennt sich und arbeitet effektiv zusammen. Mit diesem Versprechen können sich Svenja und Lars also ganz auf das konzentrieren, was wichtig ist – ihre Idee.

Vorteile des Software-Bauhaus-Konzepts

Aus unserer Sicht birgt das Software-Bauhaus-Konzeept mehrere Vorteile gegenüber dem selbst orchestrierten Staffing durch Auftraggeber:¹

• Wir machen die Vision zu unserer eigenen, um nicht nur in einem Projekt zu arbeiten, sondern uns damit zu identifizieren. Dabei tragen wir einen Teil des Risikos zusammen mit Stakeholdern und Gründer:innen. Diese haben jederzeit vollen Einblick in die Produktentwicklung bei minimalem zeitlichem Aufwand. Ob selbst in der Rolle des Product Owners oder als Haupt-Stakeholder – sie erhalten die notwendige methodische Unterstützung und sind stets genauso weit eingebunden, wie sie es möchten und können.
• Requirements Engineers und UX-Designer stellen dabei zu jeder Zeit sicher, dass das Team alle nötigen fachlichen Details kennt, um zielführend arbeiten zu können.
• Die Zusammensetzung des Teams ist stets abgestimmt auf die anstehenden Schwerpunkte (Design, Development, Operations) und das ohne wesentliche zeitliche Aufwände für Re-Staffing oder Eingewöhnung; denn die Mitarbeitenden im Software-Bauhaus kennen und verstehen einander.
• Die Teammitglieder sind motivierter und engagierter als in individuell „zusammengewürfelten“ Teams, denn durch die frühe Beteiligung in der Discovery-Phase haben sie neben dem selbstverständlichen Know-how auch das „Know-why“ und können so eigeninitiativ technische Lösungen zu Problemen aus der Fachdomäne einbringen.
• Nicht zuletzt profitieren von diesem Ansatz vor allem Nutzer:innen. Denn zum einen ist Softwarequalität eines konstanten, eingespielten Teams nachweislich höher als in „losen“ Projektzusammenschlüssen. Zum anderen garantiert die End-to-End Verantwortung von der Idee bis zum Betrieb eine bessere Wartung und Pflege der Software.

Hinweise:

[1] Detailierte Informationen zu den Vorteilen des Software-Bauhaus-Konzepts finden Sie unter https://qualityminds.com/services/software-development/agile-software-development-teams/

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Von QualityMinds finden Sie im t2informatik Blog weitere Beiträge:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.