Unter der schweizerischen Dachmarke Bison positionieren sich verschiedene IT-Solution-Firmen mit insgesamt 600 Mitarbeitenden und einem Gesamtjahresumsatz in Höhe von 100 Mio CHF (96 Mio €). BISON bietet Informatik-Gesamtlösungen für verschiedene Branchen an, von der Software bis zur gesamten Infrastruktur-Betreuung vor Ort oder auch in einem der firmeneigenen Rechenzentren. BISON ist seit ca. 30 Jahren am Markt.
Die BISON Schweiz AG ist spezialisiert auf die Entwicklung und Einführung von Business Software für mittelständische Unternehmen. Sie hat über 300 Mitarbeitende. Zum Zeitpunkt der Einführung des agilen Vorgehens im Jahr 2012 hatte die Division Softwareentwicklung insgesamt 150 Mitarbeitende, davon 100 in der Schweiz und 50 in Russland. Mit der Umstellung der Entwicklungsmethodik wurde auch die gesamte Führung restrukturiert, um Unternehmen und Entwicklung in Einklang zu halten bzw. zu bringen.
Ziel war es, eine tiefgreifende und nachhaltige Agilität der Organisation zu erreichen. Als Framework bzw. Methodik wurde Scrum gewählt. Der Umbauprozess startete 2011 mit einer einjährigen Vorbereitungsphase, 2012 wurde die gesamt Organisation umgestellt und durch Krisen und Rückschläge hat es bis etwa Ende 2013 gedauert, bis alles rund und robust lief.
Renate, Head of Business Unit Agile Support, berichtet:
Vor drei Jahren haben wir Scrum als Framework für unsere Software-Entwicklung eingeführt. Kein Stein blieb auf dem anderen, wodurch sich auch die ganze Führung unserer Firma verändert hat. Heute haben wir ein agiles Führungs- und Management-Team in der Entwicklung: Vier Manager, inmitten einer klassisch hierarchisch funktionierenden, sich immer noch im Wandel befindenden BISON.
Dieses Management-Team arbeitet ebenfalls agil nach Scrum:
- Der Bereichsleiter und Managing Director Development übernimmt die Rolle des Product Owners (PO) – das einzige Zugeständnis an die Hierarchie im ganzen Bereich.
- Wir machen zweiwöchige Sprints und treffen uns jeden Mittwoch Vormittag vor unserem Board für das Planning-Meeting. Das Board befindet sich in unserem Büro und ist für alle Mitarbeiter zugänglich.
- Auf dem Board befinden sich die User Stories zu den Themen Organisation, Produkt, Ziele, Kennzahlen und auch Finanzen.
- Die User Stories stammen von uns selber, von Mitarbeitern, von anderen Abteilungen oder auch von unserem PO, also von all unseren Stakeholdern. Selbstverständlich werden die Stories eindeutig priorisiert.
- Die „Management“-User Stories am Board sind als echte User Stories formuliert, inklusive den dazu gehörigen Acceptance Criterias.
- Das Planning beenden wir mit einem Commitment. Wir sagen also den Lieferumfang des nächsten Sprints verbindlich zu.
- Wie alle anderen Development Scrum Teams zerlegen wir die User Stories in Tasks und verteilen diese Tasks für die nächsten 24 Stunden. Täglich treffen wir uns zum Daily Scrum, berichten, wo wir stehen und verteilen, was als nächstes zu tun ist.
- Für den Bereichsleiter (jetzt PO), ist dies eine gute Gelegenheit, sich über den Status zu informieren.
- Alle zwei Wochen findet das Review Es ist öffentlich und unsere KollegInnen, die Geschäftsleitungsmitglieder oder Personen aus anderen Bereichen können teilnehmen. Teilnehmer sind auf jeden Fall diejenigen, die auf das Ergebnis der jeweiligen User Story warten oder selber vom Ergebnis betroffen sind.
- Im Anschluss an das Review findet meist auch die Retrospektive Nicht mehr immer, dafür gehen wir auch die wirklich schwierigen Themen an. Wir sind uns auf jeden Fall alle sehr bewusst, dass wir dieses Format wollen und brauchen, damit wir im Team und in der Zusammenarbeit weiterkommen.
Es macht Spass, so zu arbeiten! Es gelingt uns, die geforderten Ergebnisse am Ende der meisten Sprints zu liefern. Das war nicht immer so. Wenn wir drei Jahre zurückschauen, sieht man deutlich, wie wir uns immer wieder anpassen mussten:
Mit der Einführung von Scrum wechselten wir von einer stark hierarchischen Führung auf eine viel flachere Organisation. Fünf Manager führten damals die 110 Mitarbeiter in der Schweiz, also eine Führungsspanne von rund 20 Mitarbeitern pro Führungsperson. Diese Mitarbeiter sind verteilt in ganz unterschiedlichen Teams, damit ist keine Zuweisung von Teams zu den Führungspersonen möglich. Dies war ein bewusster Entscheid.
Keine Änderung für die Führung, dachten wir. Doch wir merkten schnell, dass es nicht mehr klappt wie früher. All unsere Mitarbeiter sind jetzt eben in unterschiedlichen Teams verteilt. Da gibt es auch keine Teamleiter mehr zum Weiterdelegieren von Aufgaben. Dafür gibt es plötzlich Product Owner und Scrum Master – was jetzt? Zusätzlich kamen neue Begriffe in die Organisation wie Story Points, Velocity, Burndown Chart. Die aktuellen Arbeiten, also die Tasks, hingen neu als Zettel im Teamraum und nicht mehr elektronisch im System.
Die Erkenntnis, dass auch das Management nur noch als Team funktionieren kann, war offensichtlich. Wir beschlossen, ebenfalls nach Scrum zu arbeiten, um auch gleich alles am eigenen Leib zu erfahren:
– Auf dem Task Board steht, wer was macht!
– Planung: Wir können uns über Prioritäten einigen und die Aufgaben unter uns verteilen
– Review: Wir erzählen, was entschieden wurde!
– Commitment: Geht nicht im Management, also lassen wir das aus!
– Retrospektive: ja, machen wir irgendwann zwischendurch mal!
Das ging natürlich nicht lange gut und ziemlich schnell stellten wir fest: Scrum geht nicht im Management! Die Lösung war schnell gefunden. Wir entschieden uns für KANBAN: Das ist einfacher und braucht weniger Meetings! Das Board müssen wir nur ein bisschen anpassen und unsere Arbeit erledigen wir nach Priorität …
In zwei Monaten hatten sich eine Handvoll Zettel auf dem Board von links nach rechts bewegt. Sonst nichts! Irgendwie hatten wir immer noch nicht das passende Vorgehen gefunden und wir fühlten uns in unserer Rolle immer unwohler.
Auch die Aussenwirkung der Softwareentwicklung innerhalb der Unternehmung war irritierend und schlecht. Es war eine wirklich schwierige Zeit:
– Wir fünf Manager arbeiteten zwar unermüdlich, rannten aber alle in unterschiedliche Richtungen.
– einen sichtbaren Fortschritt in der Qualität und im Output des Teams gab es kaum.
– Was wir als Organisation der Zukunft verkauften (z.B. Selbstorganisation), entpuppte sich als Boomerang, es sah nach Chaos aus.
Mittlerweile war die Unzufriedenheit im Management-Team derart gross, dass wir begannen, unsere Rolle zu hinterfragen: Was ist überhaupt noch unser Job? Braucht es uns überhaupt noch? Intensive Diskussionen untereinander waren an der Tagesordnung.
Und diese Diskussionen haben uns schliesslich auf den für uns richtigen Weg geführt: Irgendwann stellten wir uns die wichtigste Frage: Was sind eigentlich unsere Aufgaben und wie lösen wir diese am besten?
Wir waren uns weiterhin einig, dass wir sie nur als ein Team lösen können. Also mussten wir ein richtiges Team werden. Wir kamen zurück zu Scrum und entschieden uns, diese Methodik nun mit aller Konsequenz umzusetzen.
Wir holten uns aus einem Development-Team für drei Monate einen Scrum Master ins Management-Team, für beide Seiten eine spannende Erfahrung. Am Ende jedes Sprints führten wir eine Retrospektive durch. Wir erstellten ein neues Board und unser PO schrieb richtige User Stories mit Acceptance Criterias, die dann priorisiert und am Board platziert wurden.
Soweit klappte alles ganz gut, aber es tauchte das nächste Problem auf: Bereits am Ende des ersten Sprints realisierten wir, dass wir es aufgrund unserer vielen Meetings zwar knapp schafften, alle Scrum Meetings gemeinsam zu halten, aber kaum Zeitfenster fanden, um die Tasks zu erledigen. In einer der Retrospektiven entschieden wir, drei halbe Tage für Arbeiten am Board zu reservieren.
Wir nennen diese halben Tage „Arbeitsblöcke“. Visualisiert hängt dieser „Plan“ im Büro direkt neben dem Board, so dass es wirklich jedes Teammitglied sieht. Doch am Ende des nächsten Sprints kam die grosse Ernüchterung: Wir hatten keinen einzigen Arbeitsblock eingehalten.
Ein weiteres Mal war unser PO und damit auch wir unzufrieden! Wir mussten unsere Kalender freiräumen. Die Lösung fanden wir in etwas bewährtem aus den Entwicklungsteams. Wir versuchten es mit „Pair-Calendering“-Sessions: das bedeutet soviel wie Pair-Programming für Manager: Zwei Manager setzen sich vor den Kalender der einen Person. Der Driver erklärt jeden einzelnen Termin und der Navigator fragt einfach immer wieder: «Musst du da wirklich dabei sein? Braucht es dich da?» Und wenn ja, dann «Muss der Termin genau dann sein oder könnte er nicht umgeplant werden?»
Die Kalender leerten sich unheimlich schnell. Noch viel besser: ein aufgeräumter Kalender macht wieder richtig Lust auf Arbeit! Man hat plötzlich wieder Zeit, Dinge zu erledigen!
Jetzt, wo es vorwärts ging, tauchte das nächste Problem auf: Die Tasks am Board wurden nicht nachgeführt! Damit war unklar, wer woran arbeitete und auch der Fortschritt war nicht sichtbar. Eigentlich ist es ja eine kurze Sache, Post-Its mit seinem eigenen Namen zu versehen und diese dem Fortschritt entsprechend am Board umzuhängen. Trotzdem haben wir’s nicht gemacht. Mit etwas Kreativität haben wir auch dafür eine Lösung gefunden: Superheroes fürs Task Board!
Stellen sie sich mal vor, Sie stehen vor einem Board, können Superman nehmen und sagen: «Superman macht das heute» oder «Hulk hat das gerade eben mal im Vorbeigehen erledigt» oder «Flash erledigt dies schnell mal».
In einer Retrospektive hat jeder einen Superhero aufgrund dessen Eigenschaften ausgewählt. Dieser hing ab sofort für am Board und zwar an dem Task, woran er gerade arbeitet
So macht die Fleissarbeit am Board plötzlich Spass! Und wenn man als Manager in der Kaffeepause gefragt wird: «Welcher Superhero bist du?», dann tut das einfach gut! Das Task Board war ab diesem Tag auf dem aktuellsten Stand!
So haben wir ein Hindernis nach dem anderen in Angriff genommen und kamen Schritt für Schritt vorwärts. Wir wurden mit jedem Sprint besser und transparenter – innerhalb des Teams und auch nach aussen: Die Resultate hatten wieder mehr Qualität, wurden deutlich zuverlässiger geliefert und waren vor allem abgestimmt. Es wurde klar sichtbar: das Team hat Fahrt aufgenommen. Die Leistung war nicht nur besser, sondern auch viel transparenter.
Mit dieser Transparenz wurde auch ein weiteres Problem sichtbar: Vier der Manager rannten in gleiche Richtung, einer blieb mehr oder weniger in seinem „Garten“ stehen! Trotz grosser Anstrengungen des Teams stagnierte der Output. Als letzte Konsequenz blieb am Ende nur eine personelle Veränderung.
Ab diesem Zeitpunkt arbeitete das Team zu viert weiter und konnte den Output trotz einer Person weniger sogar erhöhen.
Nach eineinhalb schwierigen Jahren hatten wir es nun geschafft! Wir kannten unsere Aufgaben, hatten klare Prioritäten in Form von Stories und wertvolle, effiziente Meetings. Wir lieferten am Ende jedes Sprints Ergebnisse, die uns stolz machten. Wir waren ein richtig gutes Team geworden, das gemeinsam durch Dick und Dünn ging und hatten wieder richtig Spass an der Arbeit! Auch nach Aussen strahlte das Team: Immer häufiger kamen Führungsleute aus anderen Bereichen oder auch Geschäftsleitungsmitglieder zu den Reviews. Dies hatte auch Wirkung in anderen Bereichen der Bison. Als sichtbares Resultate entstanden dort z.B. verschiedene Boards für die tägliche Arbeit.
Wir waren endlich am Ziel angekommen.
Und dann kam eine echte Bewährungsprobe auf das Team zu. BISON war aufgrund der schwierigen Auftragslage gezwungen, an der Kostenschraube zu drehen.
Keine schöne Aufgabe! Es war klar, was zu tun war. Wir mussten uns von Mitarbeitern trennen. Im Enterprise Product Backlog identifizierten wir das benötigte Knowhow für die nächsten Monate in der Software-Entwicklung. Wir definierten, wie die Teams neu zusammengestellt werden sollen, damit sie möglichst effizient arbeiten können. Übrig blieb eine Liste von Mitarbeitenden, von denen wir uns leider trennen mussten.
Im Unterschied zu einer hierarchischen Organisation wurden alle Personalmassnahmen gemeinsam im Team diskutiert und beschlossen. Der Blick lag dabei immer auf der gesamten Abteilung und nicht auf einzelnen Teams oder Teilbereichen der Entwicklung.
Den agilen Werten wie Transparenz, Mut und Offenheit haben wir Rechnung getragen und die Mitarbeiter sehr früh informiert. Dies wiederum erzeugte Druck auf uns selber, viele Fragen waren zu beantworten, zu denen wir die Antworten selber noch nicht wussten. Dies führte zu vielen sehr schwierigen Momenten für uns als Führungspersonen. Jeder von uns kam gelegentlich an seine Grenzen in dieser Zeit.
Wir haben auch da einen Weg gefunden damit umzugehen: den „Parkplatz“. Dieser Parkplatz hing direkt beim Eingang in unser Büro. Die Abmachung rund um diesen Parkplatz war ganz einfach: Wenn einer aus dem Team mit der Situation überfordert ist oder bemerkt, wie ein Teammitglied gerade nicht klar kommt, dann „besetzt“ er mittels einem roten Post-It den Parkplatz. Das bedeutet dann, dass wir noch am gleichen Tag das Thema gemeinsam ausdiskutieren und lösen und zwar völlig ungeachtet der Aufgaben, die aktuell anstehen.
Wir haben uns in dieser schwierigen Zeit gegenseitig Sicherheit vermittelt und dadurch für alle Herausforderungen gute Lösungen gefunden. Wir haben die richtigen Massnahmen eingeleitet und die gute Stimmung in den Entwicklungsteams behalten. Das Management-Team hatte eine weitere schwierige Aufgabe souverän gemeistert.
Ein agiles Management-Team ist in unserer Erfahrung um einiges robuster und effizienter als alles andere, was wir bis dahin erfahren haben. Trotzdem gibt es Herausforderungen, mit denen man umgehen können muss:
- Personelle Änderungen im Team:
Ein Teammember übernahm eine neue Aufgabe in der Unternehmung, wir brauchten also ein neues Teammitglied. Die Bison-Rekrutierungsmaschinerie lief an: Das HRM stand auf der Matte, zog Assessments aus der Schublade, externe Spezialisten machten Interviews und so weiter … Der Top-Kandidat wurde gefunden. Er erreichte die besten Resultate, es gab grünes Licht vom CEO, grünes Licht von HRM und grünes Licht vom Bereichsleiter bzw. PO. Er informierte das Team und weiter gings …
Neun Monate später musste der Top-Mann wieder aus dem Spiel genommen werden! Wie bitte? Er war nett und enorm leistungsfähig, aber die Teamarbeit war schwierig. Es benötigte sehr viel Abstimmungsaufwand, viele Missverständnisse waren die Folge und damit auch viel Frust! Das Team war nicht einbezogen worden in den Rekrutierungsprozess, was sich jetzt rächte und die entsprechende Folge hatte.
Die Selektion nach bisher bewährtem Schema via HRM und Assessment hat nicht funktioniert. Der Einbezug des Teams ist zwingend notwendig!
- Eine kleine Aufgabe im Vorübergehen zu lösen, geht nicht! Was hindert das Team daran? Vier Personen tragen gemeinsam die Verantwortung für 110 Mitarbeiter in 13 Teams. Dies stellt ein komplexes Netzwerk dar. Die Gefahr von Chaos mit einer unüberlegten Information oder Aktion ist zu gross.
Eine Hauptaufgabe des Management-Teams ist es, die Mitarbeitenden so auszurichten, dass alle in dieselbe Richtung laufen und am gleichen Strick ziehen. Damit startet das Team zu Beginn langsamer, aber die Ergebnisse sind dafür nachhaltiger. Dies wirkt auf die Aussenwelt oft erstmal mühsam, man muss aber lernen, damit zurechtzukommen.
- Alphatiere sind die grösste Herausforderung! Im Management finden sich im Verhältnis viele Alphatiere. Für sie sind Macht, Status und persönlicher Erfolg sehr wichtig. Man kann sich die Frage stellen, was daran ein Problem sein soll, denn schliesslich ist auf dieser Stufe Erfolgsorientierung eine wichtige Eigenschaft.
Der Unterschied liegt in der Art und Weise wie diese Eigenschaft umgesetzt wird. Ein agiles Management-Team hat weiterhin Macht, Status und Erfolg – die Teammitglieder müssen aber lernen, dies zu teilen. Deswegen gilt es, einen Weg zu finden, wie die Teammitglieder sich über Teamerfolge freuen können und sich damit darüber definieren. Dies ist ein schwieriger und steiniger Weg! Aber es lohnt sich, diesen zu gehen!