Vielerorts bzw. in vielen Umgebungen herrscht die Meinung vor, dass jede Person doch bitte genau eine Rolle auszuführen hat – und das doch bitte ohne die anderen Personen in anderen Rollen zu stören oder zu belästigen (Stichwort: „Kümmere Dich mal um Deinen Kram…“).
Da wir ein Softwarehaus sind, das verschiedene Tätigkeiten ausführen muss um unseren Kunden die gewünschten Produkte zu liefern, haben auch wir zunächst in Rollen gedacht und gelebt. Jeder kennt das – aber letztlich will es keiner haben.
So stieg die Unzufriedenheit bei uns an – wir wechselten den Job bzw. Arbeitgeber – nur um festzustellen, dass es andernorts genauso oder ähnlich verkorkst zugeht.
Was also tun ?
Die meisten von uns kommen aus der Software-Entwicklungs-Ecke, die meisten haben dort auch schon agil kennengelernt. Oder zumindest das, was dort als agil bezeichnet wurde.
Nun passt aber das eine agil nicht immer zum anderen agil – und so muss jedes Team sein Agil finden.
Hilfsmittel
Es gibt diverse Hilfsmittel – prozessualer als auch zwischenmenschlicher Natur – die helfen können die Herausforderungen in der Welt der Software-Entwicklung zu reduzieren.
Es gibt kein Problem
Wichtigster Punkt in allen betrachteten Szenarien ist die eigene Einstellung zu unbekannten Gebieten und plötzliche eintretenden Ereignissen.
Schnell spricht man gerne vom „Problem“.
Es ist dabei wichtig sich vor Augen zu führen, was genau denn nun das Wort Problem beschreibt.
Allgemeinhin gilt:
Ein Problem nennt man eine Aufgabe oder Streitfrage, deren Lösung mit Schwierigkeiten verbunden ist. Ausgangssituation, Hindernis und Zielsituation müssen hierzu festgestellt werden, während der Lösungsweg offen, unbestimmt bleibt.
Wikipedia
Spitzt man die Formulierung weiter zu, entsteht daraus Folgendes:
Ein Problem ist eine – aktuell und mit dem vorhandenen Wissen und der vorhandenen Technik – nicht lösbare Herausforderung, bezogen auf die aktuelle Aufgabenstellung.
Kai Sieveke
Vor diesem Hintergrund gibt es also vorher – bevor es Probleme werden – immer die Herausforderung!
Nun liegt es an den Menschen, ob es zum Problem wird – oder ob es eine Lösung für die Herausforderung gibt.
Da wir Lösungen für unsere Kunden bieten und auch bieten wollen – ist es also nicht besonders ratsam von Problemen zu sprechen. Die Wortwahl in den ersten Gesprächen und auch im Team selbst ist besonders wichtig, wenn es um das finden von Lösungen geht.
Findet man eine Lösung für eine gestellte Aufgabe, wird die Herausforderung beherrschbar und ist damit keine Herausforderung mehr.
Vielfalt in der Arbeitswelt
Jeder kennt das
- etwas ist neu und toll
- man opfert sich auf, um das Neue für sich beherrschbar zu machen
- nach einiger Zeit wird man besser, man beherrscht das Neue besser
- wenn noch mehr Zeit mit einer Tätigkeit vergeht, meistert man das Neue – und damit die Herausforderung – das Thema wird zum Standard
- ist das Thema eine Zeit lang Standard, beginnt es langweilig zu werden
- vergeht noch mehr Zeit mit dieser Tätigkeit stumpft man unweigerlich ab und macht „Dienst nach Vorschrift“
Diese auch als Abwärts-Spirale bezeichnete Abfolge in der Wahrnehmung der Menschen ist völlig normal. Sie führt uns dazu mehr zu wollen, weiter zu denken, neue Herausforderungen zu erkennen und sie meistern zu wollen.
In der Arbeitswelt macht es aber wenig Sinn nach 1 bis 2 Jahren als Maurer in eine neue Tätigkeit als Bäcker zu gehen, dort wiederum 1 bis 2 Jahre zu verweilen, um dann eine Tätigkeit als Bankberater anzustreben.
Sicher kann man das tun – ob es erfüllend ist, steht auf einem anderen Blatt.
Erfüllung im Job
Man findet sie in der Regel dann, wenn das Umfeld passt, die Leute nett und zuvorkommend sind, die Entlohnung subjektiv gut ist und die Entwicklungs-Möglichkeiten uns Raum lassen.
Auf die Software-Entwicklung umgemünzt bedeutet dies, dass man allen Teilnehmern bzw. Mitarbeitern außer den obigen Rahmenbedingungen noch Abwechslung in der Tätkigkeit bieten muss. Bei uns wird daher die Tätigkeit nicht nach fester Rolle definiert, sondern variable in Funktionen gegliedert.
Gelebte Funktionen
Die Team-Mitglieder können für ein Projekt jede Rolle einnehmen, die sie wollen. Voraussetzung für das Einnehmen einer spezifischen Rolle für eine Zeit oder ein Projekt ist die gleichmäßige Aufteilung der Rollen auf die Mitglieder des Teams.
Daher sprechen wir lieber in Funktionen, die während der Schaffung eines Produktes notwendig sind.
Folgende Matrix verdeutlicht die Menge an Personen für eine solche Produkt-Entwicklung als auch die notwendigen Funktionen zur Ziel-Erreichung (bzw. Produkt-Auslieferung).
Beispiel-Matrix für die Zuordnung von Funktionen
| Product Owner | Business Analyst | Requirements Engineer | Architekt | UI Design | Entwicklung | Test | |
|---|---|---|---|---|---|---|---|
| Person 1 | X | X | X | X | X | ||
| Person 2 | X | X | X | X | |||
| Person 3 | X | X | X | ||||
| Person 4 | X | X | X |
Alle Funktionen sind dabei, aus dem T-Shape Ansatz heraus, mehrfach besetzt.
Bei 4 Personen im Team (wie in diesem Ansatz) wären Person 1 und Person 4 ausreichend, um alle Funktionen abzudecken – mit einem jeweiligen Backup durch je eine weitere Person mit entsprechender Funktionen, wird eine mindestens 200%-ige Abdeckung aller Funktionen erreicht und für Ausfälle vorgesorgt.
Wie viele Personen pro Funktion benötige ich im Team ?
Man kann die Ausprägungs-Vielfalt bzw. die mindestens erforderlichen Personen pro Funktion im Team mit einer Formel errechnen.
Die Formel dafür ist denkbar einfach und lautet:
Mind. Personen pro Funktion = RoundUp( Anzahl Funktionen / Anzahl Team-Mitglieder )
Für unser Beispiel bedeutet dies Folgendes:
Mind. Personen pro Funktion = RoundUp ( 6 / 4) = RoundUp (1,5) = 2
Haben Sie also mehr Personen im Team – und dazu weniger Funktionen – verteilt sich die „FunktionenLast“ auf mehr Schultern bzw. wird kleiner je Person. Das ist der Standardfall in größeren bis großen Unternehmen bzw. Teams, wo man i.d.R. eine Funktion pro Person wünscht.
Wie viele Funktionen pro Person sind sinnvoll im Team ?
Wenn wir nun wissen wie viele Personen je Funktion es im Team geben sollte, bleibt noch festzustellen wie viele Funktionen denn nun jede einzelne Person im Team mitbringen muss, damit der Multi-Funktions-Ansatz gut abgebildet werden kann.
Wir wollen – wie oben bereits angeklungen – den T-Shape Ansatz leben. Das bedeutet, dass jedes Team-Mitglied mehrere Eigenschaften aufweisen sollte (bei uns sogar ein muss):
- kann rudimentär alle Funktionen bedienen
- ist in mindestens x Funktionen mit Expertenwissen vertreten
- Kommunikationsfähigkeit
- Kritikfähigkeit
Das bildet die Grundlage für
RudimentärAlles + Expertenwissen + Kommunikationsfähigkeit + Kritikfähigkeit = REKK.
Unsere REKKen benötigen daher Expertenwissen in verschiedenen Fachgebieten.
Die Funktionen je Person mit Expertenwissen lassen sich ebenfalls mittels einer Formel errechnen:
Mind. Funktionen pro Person = Mind. Personen pro Funktion + 1
Für unser obiges Beispiel bedeutet dies Folgendes:
Mind. Funktionen pro Person = 2 + 1 = 3
Alle Personen im Team sollten (bzw. müssen) also mindestens 3 der Funktionen auf Senior-Level bzw. Exporte bedienen können – oder aber dies anstreben (Jeder fängt ja bekanntlich mal klein an).
Es ist nicht wichtig wie das Kind heißt – es ist wichtig wie man mit Ihm umgeht
Auch für das Beispiel mit geringerer FunktionenLast (siehe oben) und der 1:1 Zuordnung von Funktion zu Person bedeutet dies daher, dass jede Person mind. 2 Funktionen auf seniorem Level bedienen können sollte. Allein um als Team wettbewerbsfähig zu sein und zu bleiben – und den Kundennutzen zu maximieren.
Wie oben bereits kurz angeklungen, ist die „Eine Funktion pro Person“ Regelung sowieso nicht unser Weg zu arbeiten. Wir wollen lieber etwas mehr Abwechslung im Arbeitsleben und nehmen daher auch die Mehr-Funktionen-Belastung und den (freiwilligen) projektweisen Wechsel der Funktionen gerne in Kauf.
Das ist möglich, weil wir von der Spitze her – bis hin zur kleinsten Einheit – in Phasen und Funktionen denken, unser Handeln hinterfragen und im Team offen kommunizieren.
Der Fisch stinkt vom Kopf her
Deutsches Sprichwort
Mit diesem Zitat kann man erkennen, dass alles Denken vom Management ausgehend geprägt ist. Denkt das Management auf eine bestimmte Art und Weise, so fühlen sich auch Mitarbeiter nur wohl, die ähnlich denken und handeln – oder es wird ihnen entsprechend beigebracht (Stichwort: Umerziehung).
„Mal schnell umdenken, und jetzt agil arbeiten“ funktioniert also nur dann, wenn auch das oberste Management „mal schnell umdenkt und agil arbeitet“. Mehr dazu im Artikel Was ist agiles Arbeiten?
Comments are closed