Agile Softwareentwicklung: Bye-bye Codemonkey – Vom Spezialisten zum Alleskönner?
Die Arbeitswelt wandelt sich. Auf der einen Seite werden Markt und Kundenbedürfnisse immer schnelllebiger und fordern so von Unternehmen dynamischere und flexiblere Strukturen. Auf der anderen Seite fordern auch Mitarbeiter eine neue und flexible Ausgestaltung ihrer Arbeitswelt, die von Selbstbestimmung, Teamwork, Ganzheitlichkeit und Entfaltung geprägt ist. Doch nicht alle Mitarbeiter begrüßen diese Entwicklung, einige wollen lieber "in Ruhe coden" und sich auf ihre Expertise konzentrieren. Diese sogenannten "Codemonkeys" versuchen die Auseinandersetzung mit fremden Disziplinen und kollaborativen Anforderungen nach Möglichkeit zu meiden. Welche Herausforderungen ergeben sich durch den Wandel der Arbeitswelt für Mitarbeiter und wie lässt sich damit umgehen? Haben "Codemonkeys" in der Arbeitswelt der Zukunft noch eine Chance?
Mit "T-Shaped"-Skills zum agilen Team
Die Unsicherheit von Vorhersagen zu akzeptieren und damit umgehen zu lernen ist eine große Herausforderung von heute. In der Softwareentwicklung nennen wir das neudeutsch "agile". Scrum [12] heißt ein Framework zur agilen Softwareentwicklung, das Unsicherheit explizit integriert: "Wir heißen Änderungen willkommen!" In kurzen Iterationen (meist zwei Wochen) werden einzelne Features einer Software fertiggestellt. Das Feedback des Endanwenders dazu fließt direkt zurück in die Planung ein und sorgt für die Entstehung eines Produktes, das näher an den Bedürfnissen des Kunden ist.
Damit tatsächlich die "lead time" einer Anforderung - also die Zeit von der Formulierung der Idee bis zur tatsächlichen Umsetzung - minimiert wird, ist es wichtig, innerhalb einer Iteration auch tatsächlich ein fertiges Produkt entstehen zu lassen. Das ist nur dann möglich, wenn wir innerhalb unseres Teams "cross-functional" besetzt sind, also alle Kompetenzen mitbringen, die zur Produktrealisierung notwendig sind. Damit einher geht eine besonders intensive Form der Zusammenarbeit: Nur wenn wir verstehen, dass wir als gesamtes Umsetzungsteam am gleichen Strang ziehen müssen, kann ein gutes Produkt daraus entstehen. Damit diese enge Zusammenarbeit funktioniert und der Prozess nicht stehenbleibt, sobald jemand ausfällt oder das Team wechselt, braucht es t-förmig qualifizierte Mitarbeiter. Diese bringen zwar auf der einen Seite ein Spezialistentum in ihrer Fachdisziplin mit (das "Standbein des T"), haben aber auch gleichzeitig die Fähigkeit, in anderen Fachbereichen Aufgaben zu übernehmen (der "T-Balken") [siehe Abbildung 1]. Damit ist es möglich, bei Bedarf flexibel in unterschiedliche Rollen zu schlüpfen (z.B. UX/UI, Tester, Frontend-Entwickler, Backend-Entwickler, Konzeptioner, etc.).
Um aus einem "Haufen Spezialisten" ein anpassungsfähiges, interdisziplinäres, agiles Team entstehen zu lassen, können Teams Praktiken aus dem Extreme Programming [1] einsetzen: Pair-Programming ist eine effektive Methode, den Wissensstand in Teams auszubauen. Zusätzlich helfen teamübergreifende Formate, wie Communties of Interest [2], am Wissensausbau zu arbeiten.
Marktorientierung - Kunden besser verstehen
Zur Erstellung eines erfolgreichen Produktes heißt es, neben einem erweiterten fachlichen Skill-Repertoire, auch ein gemeinsames Verständnis über die Bedürfnisse und Bedarfe der Benutzer zu entwickeln und diese dafür so nah wie möglich an den Entwicklungsprozess heran zu bringen. Jedes Mitglied eines Entwicklungsteams muss damit mehr Aspekte beachten, als nur "die technische Qualität des Codes". Als Team gilt es zu verstehen, was der Anwender der Software tatsächlich benötigt, um die für ihn am besten passende Lösung zu bauen. Deshalb werden die Anforderungen in der agilen Softwareentwicklung ja auch im User-Story Format [3] geschrieben, deren Hauptbestandteil es ist, ein Verständnis des Kundennutzens zu schaffen.
Für Mitarbeiter bedeutet das, die Reflexionsfähigkeit für Veränderungen der Umwelt zu schärfen. Dass Veränderungen wahrgenommen, in der Gruppe reflektiert und an das Unternehmen zurückgespielt werden, ist die Grundlage für eine flexible Anpassbarkeit des Unternehmens an die Bedürfnisse der Außenwelt. Vernetzende, teamübergreifende Veranstaltungsformate wie z.B. Design Thinking, Open Space [4], World Café oder Hackathon haben sich dazu als hilfreich herausgestellt. Die direkte Einbindung von Kunden und Stakeholdern hilft dabei, Bedürfnisse aus verschiedenen Perspektiven zu beleuchten.
Um der Dynamik des Marktes gerecht zu werden, ist die Kernaufgabe von Unternehmen heute die Dezentralisierung von Entscheidungen zu ermöglichen. Teams, die sich an den Bedürfnissen des Marktes ausrichten, benötigen Handlungs- und Entscheidungsautonomie. Denn nur die Mitarbeiter, die auch eine gewisse Nähe zum Kunden haben, wissen, was dieser benötigt. Die Zeiten, in denen wir ein Unternehmen nur als "Organigramm" mit "oben" und "unten" dargestellt haben, sind vorbei. Heute geht es vielmehr um "außen" (am Markt) und "innen" (im Unternehmen selbst) [5], die Strukturen sind dynamischer, flexibler und vernetzter.
Am Markt ausgerichtete Teams agieren ähnlich wie kleine autarke Unternehmen. Das bedeutet auch für Mitarbeiter ein ausgeprägtes betriebswirtschaftliches Verständnis sowie Kenntnis der Geschäftsmodelle zu besitzen. Dafür hilfreich ist eine entsprechende Transparenz auf Organisationsebene. Wer nicht weiß, wie es um das Unternehmen steht und welche Strategie verfolgt wird, kann keine sinnvollen Entscheidungen treffen. Damit sich die einzelnen Teams nicht zu weit voneinander entfernen und der eigentliche Sinn des Unternehmens bei all der Entscheidungsautonomie verwässert, kann eine gemeinsam formulierte und von allen getragene Unternehmensvision hilfreich sein. Diese sorgt für Orientierung, um die Entscheidungsvielfalt auf ein vertretbares Maß zu reduzieren.
Selbstorganisation - im Spannungsfeld zwischen Anarchie und Handlungsunfähigkeit
Marktorientierte Teams organisieren sich also - entsprechend der aktuellen Kundenbedürfnisse - selbst. Der Begriff "Selbstorganisation" ist dabei generell von jenem der Selbststeuerung zu unterscheiden. Selbstorganisation findet in jeder Gruppe statt, in der einzelnen Mitglieder in Interaktion treten. Es handelt sich um einen Prozess der Ordnungsbildung, der meist nicht vorhersehbar und für die Beteiligten häufig auch nicht bewusst geschieht. Ob diese Ordnung des gemeinsamen Miteinanders dann im Sinne aller Beteiligten zweckdienlich ist, steht auf einem ganz anderen Blatt. Selbststeuerung hingegen bezeichnet die Fähigkeit eines Teams, einen internen Austausch über Vorgänge und Ergebnisse der eigenen Selbstorganisation zu führen und diese durch bewusste Entscheidungen aktiv und zielgerichtet zu gestalten. Teams können sich also in dem Maße selbst steuern, in dem sie ihr eigenen Verhalten reflektieren können und zur Meta-Kommunikation fähig sind [6]. So können z.B. Teamregeln miteinander formuliert werden, die die verschiedenen Bedürfnisse der einzelnen Mitglieder berücksichtigen und gleichzeitig ein produktives Arbeiten ermöglichen. Dies geschieht in agilen Softwareentwicklungsteams (die nach Scrum arbeiten), hauptsächlich im Rahmen von Retrospektiven, die regelmäßig (im Schnitt alle zwei Wochen) stattfinden. Hier lernen die Teams nach dem Prinzip "Inspect & Adapt" etablierte Handlungen und Methoden zu hinterfragen und diese an die aktuellen Anforderungen nach und nach anzupassen oder gar neue zu etablieren.
Eigene, von den Teams erarbeitete Teamregeln sind deshalb so wichtig, da bei aller Autonomie die eigene Freiheit dort endet, wo die eines anderen beginnt. Wenn jeder nur das tut, worauf er gerade Lust hat, so besteht die Gefahr, dass die Wertschöpfung der Teams sinkt, die Verantwortung auf andere abgewälzt wird und es zum "sozialen Faulenzen" [7] kommt, bei dem sich keiner mehr für das Ergebnis verantwortlich fühlt. Dies tritt vor allem dann auf, wenn die Einzelleistung nicht mehr nachvollziehbar ist. Neben selbst formulierten Regeln spielt hier ebenfalls Transparenz eine entscheidende Rolle. Den Fortschritt des Teams an Boards zu visualisieren und gemeinsam z.B. in Stand-Ups darüber sowie über Hindernisse im Prozess zu sprechen, kann dabei unterstützen. Weiter kann es von Vorteil sein, Teammitglieder ihre eigene Leistung z.B. bei Review-Meetings am Ende eines Sprints vorstellen zu lassen.
Je autonomer Teams und einzelne Teammitglieder agieren, desto größer wird auch der Kommunikations- und Abstimmungsbedarf zwischen ihnen. Dabei steigt die durch Kommunikation verursachte Belastung mit der Anzahl der Mitarbeiter im Team stark an. Häufig ist für die Teammitglieder nur schwer einzuschätzen, was abgestimmt werden muss und wer worüber zu informieren ist. Es kann so zu aufwändigen Abstimmungsprozessen kommen, da die Teammitglieder nicht riskieren wollen, dass ein Kollege, mit dem sie täglich zusammenarbeiten, sich bei einer Entscheidung übergangen fühlt. Leicht entstehen auch Verantwortungsdiffusitäten, bei welchen die Verantwortung immer wieder zwischen den Teammitgliedern hin und her geschoben wird. Die Entscheidungsfindung kann so zu einem schwerfälligen und anstrengenden Prozedere für alle Beteiligten werden. Deshalb ist es sinnvoll, im Team zu diskutieren, wie zukünftig gemeinsame Entscheidungen getroffen werden sollen. Dabei helfen unterschiedliche Entscheidungsverfahren, die vom Team je nach Reifegrad und Anwendungsfall eingesetzt werden können [siehe Tabelle].
| Verfahren | Kurzbeschreibung | sinnvoll bei | Herausforderungen |
|---|---|---|---|
| Konsens | Einigung auf eine von allen getragene Lösung | wenig komplexen Entscheidungen zwischen Teams oder wenigen Personen | Gruppen sind oft nicht konsensfähig |
| Konsent | Einigung auf eine Lösung, bei der der es keine Einwände (Vetos) mehr gibt | komplexen Entscheidungen in kleinen bis mittelgroßen Gruppen | Vetos blockieren eine Entscheidung, das kann die Gruppe lähmen |
| Konsultativer Einzelentscheid [8] | ein befähigter Entscheider trifft unter Einbezug von Konsultationspartnern Entscheidung | Entscheidungen, bei denen Expertenrat sinnvoll ist und Themen, bei denen Vorerfahrung hilfreich ist |
|
| Systemisches Konsensieren [9] | Die Lösung mit dem geringsten Widerstand in der gesamten Gruppe wird gesucht | einfachen und mittelkomplexen Entscheidungen in kleinen und großen Gruppen |
|
| Mehrheitsentscheid | Lösung, für die eine definierte Mehrheit gestimmt hat, wird gewählt | sehr einfachen Entscheidungen in kleinen und großen Gruppen | Minderheiten fühlen sich nicht berücksichtigt und können u.U. (z.B. bei unternehmensweiten Entscheidungen) einen erheblichen Teil der Belegschaft ausmachen; Widerstände können entsprechend hoch sein |
Diversität - mehr als nur fachliche Unterschiede
Durch den Wegfall klassischer, hierarchischer Entscheidungswege und der Entstehung autonom handelnder Teams ist es nun also möglich, unterschiedliche Sichtweisen auf ein Problem zusammenzubringen und daraus Neues zu gestalten. Mit zunehmender Partizipationsmöglichkeit aller Teammitglieder kommt aber auch die Unterschiedlichkeit aller Teammitglied deutlicher zu Tage:
Während Kollegin Heinrichs realistisch, faktenorientiert und analytisch vorgeht und immer auf Nummer sicher geht, präferiert Kollege Schmidt ein intuitives, innovatives Vorgehen, übertritt gerne einmal Regeln und liebt Überraschungen. Ganz anders Kollege Berlich, er hat immer zunächst die Bedürfnisse aller Teammitglieder im Blick, redet gerne und viel - auch über Privates - und hat immer ein offenes Ohr. Kollegin Peters wiederum ist stets pünktlich, ordentlich, äußerst strukturiert und immer bestens auf alle Meetings vorbereitet. So gibt es eine Vielzahl unterschiedlicher persönlicher Ausprägungen.
Neben der Interdisziplinarität, also verschiedenen fachlichen Bildungshintergründen von Mitarbeitenden, kann sich Unterschiedlichkeit auch durch die Neigungen zeigen, mit denen wir Dinge wahrnehmen und angehen. Die Teammitglieder müssen lernen zu verstehen, dass es nicht die eine "Wahrheit" - nämlich ihre eigene - gibt, sondern sehr unterschiedliche Sichtweisen auf ein und dieselbe Situation und jeder einen anderen Umgang damit bevorzugt. Unterschiedliche oder gegensätzliche Meinungen können als Störung betrachtet werden, die nach Möglichkeit zu vermeiden ist. Insbesondere, da der Diskurs dazu nicht selten mit Konflikten einhergeht. Diese Konflikte und Reibungen können aber genauso als fruchtbare Ergänzung genutzt werden. Erst durch die Berücksichtigung unterschiedlicher Blickwinkel ist es möglich, blinke Flecken zu minimieren und es können kreativere und innovativere Ideen entstehen. Dafür brauchen die Teammitglieder einen konstruktiven Umgang mit Konflikten und eine gute Portion Ambiguitätstoleranz [10], die es ermöglicht Andersartigkeit und Ungewissheit auszuhalten. Dafür kann es hilfreich sein, sich gezielt mit verschiedenartigen Denk- und Handlungspräferenzen zu beschäftigen. Eine Möglichkeit dafür bieten diverse Persönlichkeitsmodelle [11]. Diese können im Rahmen von Mentoring- oder Coaching-Gesprächen dabei unterstützen, sich selbst zu reflektieren, aber auch im Team, z.B. im Rahmen von Retrospektiven oder Teamtagen, Unterschiedlichkeiten sichtbar zu machen und einen konstruktiven Umgang miteinander zu üben.
Agile Teams: Führung als gemeinschaftliche Aufgabe
Die Verlagerung von Verantwortung in die Teams macht auch ein neues Führungsverständnis notwendig. Das klassische Management zerfällt in dynamische und flexible Führungsrollen. Führung fällt so häufig als Zusatzaufgabe zur operativen Arbeit an. Das kann auf fachlicher Ebene sein, wenn es um die Expertise zu einer Fragestellung geht. Auf Personenebene, im Rahmen der Weiterentwicklung von Teams oder Mitarbeitern (Mentoring, Coaching). Oder auch auf Produkt- oder Entwicklungsebene, z.B. in der Rolle als Product Owner [12], wenn es darum geht das Team für ein Produkt zu begeistern. Wesentlich hierbei ist, dass es sich eben nicht um Führungspositionen handelt, sondern um Rollen, deren Macht lediglich situativ akzeptiert ist. Führung wird somit zum integralen Bestandteil der Arbeit eines jedes Mitarbeiters.
Aus diesen situativen Führungsaufgaben können Rollenkonflikte entstehen, bei denen die Betroffenen zum Teil mit widersprüchlichen Anforderungen konfrontiert werden. Insbesondere auch bei teamübergreifender Arbeit ist hier die Herausforderung ein Enttäuschungsgleichgewicht herzustellen. Jeder Partner darf in der Zusammenarbeit nur soweit enttäuscht werden, dass - wenn morgen neue Prioritäten gesetzt werden - weiter mit ihm gearbeitet werden kann [13]. Hierdurch werden dann wiederum Andere enttäuscht werden, usw. Enttäuschungen sind somit unvermeidbar und müssen akzeptiert und ausgehalten werden. Andernfalls besteht die Gefahr der Überlastung, im Versuch es allen recht zu machen. Eine gute Selbstreflexion dient dabei als Basis, widersprüchliche Anforderungen zu erkennen.
Wichtig dafür, dass solche Rollen gelebt werden können, ist ein Umfeld, das fehlertolerant ist und zum Experimentieren ermutigt. Andernfalls besteht die Gefahr, immer wieder in gewohnte Reaktionsmuster zu verfallen, in welchen der Ruf nach "der Führungskraft" laut wird, die "nun bitte mal die Sache in die Hand" nehmen möge.
Fazit
Zum Umgang mit der komplexen und dynamischen Marktsituation hat die Softwareentwicklungsbranche scheinbar eine Antwort gefunden: Crossfunktionale Teams, die mit agilen Frameworks wie Scrum arbeiten, sind anpassungsfähig genug, um mit der Marktentwicklung mitzuhalten. Dafür bedarf es nun ein Team von generalisierten Spezialisten, die an einem Strang ziehen und neben der technischen Expertise auch verinnerlicht haben, dass ein wesentlicher Aspekt dabei ist, die tatsächlichen Bedürfnisse des Kunden zu verstehen. Gruppendynamiken kommen durch die steigende Partizipation und Kollaboration stärker zum Tragen und fordern erweiterte Kompetenzen, die es ermöglichen auf Meta-Ebene das eigene Verhalten zu reflektieren und Unterschiedlichkeit nutzbar zu machen. Zusätzlich entsteht durch agile Organisationsformen ein neues Führungsverständnis: klassische Führungspositionen fallen weg und werden auf mehrere Schultern verteilt. Situativ befindet sich dadurch potentiell jeder in der Situation, Führung übernehmen zu müssen.
Die Anforderungen an Mitarbeitende in einem agilen Umfeld steigen also: Wer sich als Spezialist etabliert hat (Vertikale des "T"), von dem werden nun erweiterte fachliche, interdisziplinäre Skills (Horizontale des "T"), sowie zusätzliche soziale Kompetenzen (erweiterte Horizontale des "T") erwartet [siehe Abbildung 2]. Diese gestiegenen Anforderungen spalten die Informatiker in zwei Lager: Auf der einen Seite diejenigen, die diese Entwicklung begrüßen und sinnvoll finden. Auf der anderen Seite diejenigen, die sich weiterhin lieber mit ihrem Fach ("ich bin doch zum Programmieren hierher gekommen!") beschäftigen wollen und die sich deshalb überfordert fühlen, die "Codemonkeys" eben.
Am Ende bleibt die Frage, was mit dem "Codemonkey" passiert. Sicherlich werden es Mitarbeitende in einem agilen Umfeld leichter haben, wenn sie die eigenen Kompetenzen zur Zusammenarbeit ausbauen. Die Herausforderung der heutigen Zeit ist es, Informatiker mithilfe von Weiterbildungen und ggfs. persönlichem Coaching dabei zu unterstützen, den Anforderungen der Zeit gerecht zu werden und mit Überforderungen umzugehen. Aber auch das geschieht nicht von heute auf morgen. Es ist daher im Unternehmen wichtig eine Sensibilität dafür aufzubauen, wo sich ein jeder aktuell befindet und welche Unterstützung er gerade braucht. Für "Codemonkeys", die nicht auf die Sensibilität ihres Unternehmens hoffen wollen, kann auch eine proaktive Kommunikation zum eigenen Standort hilfreich sein: Wer sich darüber bewusst ist, nicht mit den neuen Anforderungen mitgehen zu können oder zu wollen, kann mit diesem Bewusstsein für Unterschiedlichkeit in den Dialog gehen. Ein tolerantes Team, das insgesamt eine hohe Sozialkompetenz aufweist, kann so sicher nicht nur "Codemonkeys" integrieren, sondern sogar von ihnen profitieren!
- http://www.extremeprogramming.org/
- Wikipedia-Eintrag zu "Communties of Interest"
- Cohn, M., 2004, User Stories Applied, Addison-Wesley Signature
- Owen, H, 2011, Open Space Technology - Ein Leitfaden für die Praxis, Schäffer-Poeschel Verlag
- vgl. Wohland, G: "Abbildungen und Erläuterungen zu den Denkwerkzeugen dynamikrobuster Höchstleister" und Pflaegling, N., 2014, Organisation für Komplexität, Readline Verlag
- Stahl, E., 2012, Dynamik in Gruppen; Beltz Verlag
- vgl. Leitl, M., Social Loafing; Harvard Business Manager, 5/2007
- vgl. ausführliche Beschreibung und Praxisbeispiel
- Systemisches Konsensieren
- siehe Wikipedia-Eintrag "Ambiguitätstoleranz"
- z. B. MBTI: Wikipedia- Eintrag zu "Myers-Briggs-Typenindikator" , HBDI, DISG , Insights Discovery u.v.m.
- Rolle im Scrum-Framework, siehe: http://www.scrumguides.org
- Buchinger, K, 2006, Das Odysseusprinzip – Leadership revisited, Klett-Cotta
