“Agile Org” – Wie skalierte agile Methoden uns bei der Bearbeitung von Veränderungsthemen helfen

Veröffentlicht am 16. September 2020

Behandelte Themen

Einführung von Matthias Rauer

Die Erwartungen an diese Podcast-Folge

Anfänge der agilen Organisation bei Seibert Media

Die Kinderkrankheiten bei der Transition

Konkrete Anlässe, die agilen Prozesse weiter zu skalieren

Die Agile Org

Wer entscheidet über gewichtige Themen?

Herkunft der Themen in der Agile Org

Evolution vom Anfang bis zum Heute

Wie wird der Prozess im Unternehmen angenommen?

Ausblick auf weitere Podcast-Folgen

Transkription des Podcasts

Mit: Matthias Rauer und Paul Herwarth von Bittenfeld von Seibert Media

Matthias:

Hallo und willkommen zu einer neuen Podcast-Folge von Seibert Media. In dieser aktuellen Staffel beschäftigen wir uns mit der Skalierung von Agilität und in den letzten Beiträgen haben wir unter anderem ausführlich über das Scaled Agile Framework in der Produktentwicklung und über Softwareunterstützung bei der Agile Skalierung gesprochen. Heute wollen wir mal ein bisschen weg von der Produktentwicklung gehen und mehr auf die organisatorischen Aspekte in einem Unternehmen zu sprechen kommen. Wo können hier skalierte agile Prozesse helfen.

Das sehen wir uns am konkreten Beispiel von Seibert Media an und zwar von den ersten Gehversuchen mit Scrum bis zur Etablierung als agile Organisation. Als Gast ist mir mein lieber Kollege Paul Herwarth von Bittenfeld zugeschaltet, der bei uns von Anfang an Agile und die Skalierung entsprechender Prozesse mit vorangetrieben hat. Hi Paul, schön, dass du dabei bist!

Paul:

Ja, hallo Matthias, ich freue mich, da zu sein. 

Matthias:

Ich bin Matthias Rauer und Paul, lass uns zum Anfang doch mal kurz auf die Erwartungen an diese Podcast-Folge eingehen. Wir schicken uns ja nun gerade an, über uns selbst zu sprechen. Da runzelt vielleicht der ein oder andere kritische Hörer schon die Stirn. Aha, das klingt aber ganz schön selbst-referenziell. Ob das was bringt? Paul, du hast mit Kollegen schon auf diversen Konferenzen und Events über die agile Organisation bei uns gesprochen. Was für Feedback hast du denn dazu erhalten? Kannst du Entwarnung geben? Hat das den Leuten irgendwas gebracht?

Paul:

Ja, ich hoffe doch. Also wir kriegen auf unsere Vorträge und auch Buchbeiträge durchaus regelmäßig sehr positives Feedback, was letztendlich daran liegt, dass die Art, wie wir agiles Vorgehen bei uns leben, einfach sehr sehr konsequent ist und sich wirklich durch die gesamte Organisation zieht und das doch auch bei Leuten, die sich schon länger mit Agilität beschäftigen, immer wieder sozusagen, ja, für Spannung sorgt, oder auch eben dafür sorgt, dass sie sagen, Mensch, schön, dass man mal eine Organisation sieht, die das auch so konsequent dann auf allen Ebenen letztendlich auch durchzieht.

Matthias:

Okay, dann hören uns hoffentlich auch die kritischen Hörer weiter zu und ich hoffe, sie können irgendwas mitnehmen. Also agile Organisation bei Seibert Media. Blicken wir doch mal zurück und lass uns dabei vielleicht chronologisch vorgehen. So vor zehn, zwölf Jahren haben bei uns die ersten Entwicklungs-Teams angefangen, mit Agile und Scrum zu experimentieren. Die Notwendigkeit etwas zu verändern war offenbar gegeben. 

Paul:

Ja, also ich sage mal, es gibt zwei Gründe, warum große Veränderungen stattfinden. Und in der Regel sind das entweder große Probleme, die man hat, oder große Hoffnungen. Bei uns muss man eigentlich eher, dass es wirklich das Zweitere war. Also es waren größere Hoffnungen, die dadurch geweckt wurden, dass einfach Leute gesagt haben, oh, da gibt es irgendwie was Neues mit den agilen Vorgehensweisen. Das ist so 2007/2008 bei uns angefangen, und einfach erstmal ein Interesse da war. Und nachdem wir dann auch intern so ein bisschen schon Scrum gemacht haben und haben wir uns da dann im Rahmen einer Ausgründung, die wir gemacht haben. Also wir haben eine neue Software-Applikation, sozusagen Greenfield, gebaut, also von ganz neu angefangen. Und wir waren dabei eben unserer eigener Investor. Und das hat uns einen guten Rahmen gegeben, eben zu sagen, lass uns doch jetzt einmal Scrum by the Book machen. Weil wir vorher also das typische Scrum But, wie man das damals auch gerne nannte. Also wir machen Scrum, aber wir haben eben eigentlich keinen richtigen Scrum-Master. Oder wir machen Scrum, aber wir haben keine Daily Stand-ups und machen auch nicht regelmäßige Retrospektiven. 

Und das war so ein bisschen unserer Stand 2008/2009 und wir sind dann wirklich dazu übergegangen, unter diesen ja, guten Rahmenbedingungen dann zu sagen, wir probieren das wirklich mal drei Monate aus und haben uns da gegenseitig im Team das Commitment gegeben, dass wir uns daran halten, was in dem Scrum Guide auf diesen 15/16 Seiten dargelegt ist, dass wir uns da quasi sklavisch mal dran halten, um die Effekte von Scrum wirklich selbst im Team erleben zu können. Und das war wirklich der Startschuss davon und der weitere Rollout innerhalb der Organisation war dann wirklich von diesem Effekt, den wir gespürt haben, dass wir gesagt haben, das war jetzt das erste Mal, dass wir richtig verstanden haben, wie Teamzusammenarbeit funktionieren kann. Und das hat diese große Hoffnung letztendlich geschürt, dann damit die Organisation massiv voranbringen zu können. 

Matthias:

Gehen wir mal ein paar Schritte weiter. Nachdem die Kinderkrankheiten überstanden waren, die ja bei so einer Transition auch durchaus auftreten, war das für die agilen Teams ja eine ganz neue Welt mit neuen Möglichkeiten und vielen Vorteilen. Was gab es denn dann für konkrete Anlässe, darüber nachzudenken, die agilen Prozesse weiter zu skalieren? Auch über die Teams hinaus. Hast du ein, zwei Beispiele für damalige Probleme, die so mit Scrum allein im Team nicht zu lösen waren?

Paul:

Ja, du hast es schon angesprochen. So eine erste Einführung von Scrum, da sind schon sehr sehr viele Fragestellungen auch erstmal gewesen, die wir in diesem Team über die ersten Monate klären mussten, weil natürlich Scrum auch nur ein Framework vorgibt und dann ja ganz viele Dinge selbst lösen muss und überlegen muss, was passt zu uns als Team zur Lösung. Und tatsächlich war es so, dass wir den Rollout von Scrum sozusagen dann auf weitere Teams gar nicht wirklich stark forciert haben. Sondern im Endeffekt immer dann, wenn jemand eine Problemstellung äußerte im Team. So Dinge wie, na, wir haben gerade das Problem, dass irgendwie nicht jeder weiß, was die anderen eigentlich so machen. Uns fehlt da irgendwie so ein Überblick. Und dann sind wir letztendlich immer hingegangen und haben gesagt, okay, da gibt es eben aus dem agilen Werkzeugkasten sozusagen Elemente, die können wir noch nehmen und bei euch jetzt mal ausprobieren. 

Und die Probleme, die damals da waren, wie gesagt, es war zum Teil einfach, dass so gesagt wurde, na ja, wir haben irgendwie nicht so die Transparenz da, oder das eben gesagt wurde, wir haben Schwierigkeiten damit, wenn mal jemand ausfällt. Da gibt es einfach so einen Know-How Träger im Projekt zum Beispiel. Und wenn der im Urlaub ist oder wenn einen Krankheitsfall hat, dann geht gar nichts mehr. Dann sind wir genau in solchen Fällen hingegangen und haben gesagt, okay, genau da setzt letztendlich dann das agile Vorgehen an. Wir können Transparenz schaffen, wir können Ausfallsicherheit schaffen, wir können quasi einen fliessenden Wissenstransfer schaffen. Und haben dann damit letztendlich mit Task-Boards, mit Stand-ups, mit Retrospektiven, drauf reagiert und so wirklich konkrete Probleme lösen können. Und das hat so etwa zwei Jahre gedauert, bis wir dann wirklich so im Kern die Teamstrukturen aufgebaut haben. Also weg von so einer eher abteilungsorientierten Struktur wirklich zu einer Teamstruktur. Auch mit interdisziplinären Teams und dabei dann eben in der Regel mit Scrum oder Kanban dann auch in diesen Teams gearbeitet haben. 

Matthias:

Und jetzt werden wir mal konkret und sprechen vom hier und jetzt und vom heute, bitte. Bei uns gibt es einen Prozess, der sich agile Organisation nett. Kurz Agile Org. Erzähl doch mal, was es damit auf sich hat.

Paul:

Ja, Agile Org ist etwas, was uns was seit 2012 mittlerweile begleitet, ja. Also nochmal ganz kurz, also 2007/2008 haben wir so die ersten Gehschritte gemacht. 2010 dann wirklich angefangen, Teams zu agilisieren und wir waren etwa 2012 dann auf einer Konferenz und haben da die Idee mitgenommen, dass man doch eigentlich so einen Change-Projekt auch mit Scrum aufsetzen könnte. Und das hat irgendwie in uns gearbeitet und wir uns dann einmal hingesetzt und haben überlegt, wenn wir jetzt letztendlich Scrum anwenden wollen, um nicht auf einer Teamebene Veränderungen zu treiben, sondern eben auf einer organisationalen Ebene, was bedeutet das denn, was muss ich dann da ändern. Zum Beispiel für uns die Frage, gibt es dann einen Product Owner, der allein verantwortlich ist fürs Backlog. Oder müssen wir das dann nicht gemeinsam mit der Organisation auch machen und da gemeinsame Voting-Mechanismen entwickeln und…

Matthias:

Also wir reden gerade über Themen, die unternehmensweit sind, die weit über die Teams hinausdenken.

Paul:

Ja richtig, wir reden jetzt über eine Art von Themen, also initial war das wirklich so, dass wir gesagt haben, na ja, wir müssen den Teams, diesen agilen Teams den Rahmen geben, dass die sagen können, an dieser Stelle gibt es in unserem Abrechnungsmodell, beispielsweise Probleme mit dem agilen Vorgehen, das wollen wir jetzt gemeinschaftlich lösen, ja. Es waren aber auch Dinge, wie die Einstellungspolitik vielleicht, wo man sagt, die Art, wie wir einstellen heute, die hindert uns daran, als Teams optimal zusammenzuarbeiten. Und initial war es wirklich so ein bisschen die Agile Org, um sagen die die Schwierigkeiten der Teams aufzugreifen und da eine Veränderung aufzusetzen, wo wir dann unser Vorgehen an Scrum orientiert aufgesetzt haben. 

Wir haben dann aber gar nicht allzu viel später festgestellt, dass das, was wir damals noch in so eine Art Management-Board Meeting regelmäßig besprochen haben, das war der Lenkungskreis damals, das eigentlich alle Themen, die wir da üblicherweise besprechen würden, sich über die Agile Org sehr gut gemeinschaftlich mit der Organisation abdecken ließen. Und so ist es wirklich dazu gekommen, dass wir auch heute quasi gar nicht mehr so Management-Board Meetings oder so, dass wir uns irgendwie so alle zwei Wochen oder so zusammensetzen und sagen, jetzt trifft sich da irgendwie die Geschäftsführung und macht da jetzt die wichtigen Entscheidungen. Sondern, dass wir wirklich ein fließendes Vorgehen haben, wo vom Azubi über einen Praktikanten bis hin eben natürlich auch zur langjährigen Vollzeitmitarbeitern oder auch Gesellschaftern, jeder die Möglichkeit hat, auch Themen mit einzubringen und zu sagen, wenn wir als Organisation besser werden wollen, dann sollten wir an diesen Themen arbeiten und das Ganze eben aber auf agilen Prinzipien. Das heißt auch mit einer Selbstorganisation hinten dran. Das heißt, Leute, die die Veränderung treiben wollen, können wirklich aktiv werden. Das Ganze aber auch unter einer Transparenz, einer sehr hohen Transparenz, und zugleich auch mit einem kontinuierlichen Feedback, das dann aus der Organisation da reingeholt werden muss, um sicherzustellen, dass die Themen eben so umgesetzt werden, dass die Organisation dann auch wirklich ja damit zufrieden ist und damit besser wird. 

Matthias:

Du hast gerade angesprochen Themen wie Einstellungspolitik oder Projektabrechnung, das sind ja sehr gewichtige Themen, die das ganze Unternehmen tangieren. Wer entscheidet denn letztlich darüber?

Paul:

Ja also, wir orientieren uns daran, dass wir eben sagen, die Entscheidung sollte immer dort getroffen werden, wo die besten Informationen darüber sind. Das heißt, wenn es jetzt eine Entscheidung ist, die ein bestimmtes Team treffen kann, weil es in erster Linie dieses Team betrifft, dann wird schon geschaut, dass dieses Team auch diese Entscheidung alleine treffen darf und dann letztendlich es da zu einer Entscheidung kommt. Wenn es aber diese eben diese Teamgrenzen verlässt, dann greift genau die Agile Org. Wenn wir sagen, wir brauchen ein einheitliches Vorgehen, um am Markt zum Beispiel auch einheitlich sozusagen zu erscheinen, dann wird das in die Agile Org reingegeben und dort werden dann letztendlich, wird eine Gruppe entschieden, die letztendlich, die dieses Thema vorantreibt. Ja, das sind die, früher hätte man gesagt, Story-Owner, die quasi dieses Thema dann verantworten und auch zu einer Entscheidung bringen. 

Wir orientieren uns da an dem sogenannten konsultativen Einzelentscheid, in dem man in einem zweischnittigen Vorgehen letztendlich vorgeht und eben erst entscheidet, wer sind denn die Entscheider für das Thema. Und die Entscheider dann den Auftrag haben, sich beraten zu lassen, also sich Beratung reinzuholen durch Know-How Träger zu dem Thema. Das heißt, wenn es jetzt um so ein Abrechungsthema ginge, würden diese Entscheider letztendlich in Austausch mit den verschiedenen Teams gehen, verschiedene Sichtweisen einholen, die dann auch transparent aufbereiten und dann sagen, auf Basis all dieser Daten, Fakten, Infos, aber auch Empfindung vielleicht oder Gefühlen, die so aus den Teams zurückgespiegelt werden, kommen wir zu der Entscheidung, dass wir das so und so jetzt umsetzen. Und wir haben eben erlebt, dass diese Art von Entscheidung, die ja auch eine sehr starke sozusagen Feedback-Mechanismus schon in sich mit drin hat, mit sehr viel Transparenz auch abläuft, das die einfach eine sehr viel höhere Unterstützung dann auch letztendlich aus der Organisation erfahren und dadurch auch viel viel reibungsfreier umgesetzt werden. Und da spielen ja nicht nur so Sachen, ich sage mal, bei Abrechnungen, da sagt vielleicht der einzelne Mitarbeiter noch, das hat zwar mit unserem, letztendlich mit dem Erfolg als Organisation vielleicht zu tun, aber tangiert mich persönlich eben noch nicht so stark. Das sieht halt anders aus, wenn wir auch über Themen wie Gehalt zum Beispiel sprechen, wo man dann sieht, okay, wie über Gehälter entschieden wird, das ist vielleicht natürlich ein Thema, das auch mal hitziger diskutiert wird. Und da wenden wir eben aber genau diese Vorgehensweisen an. 

Matthias:

Woher kommen denn die Themen, die in der Agile Org bearbeitet werden?

Paul:

Das kommt wirklich aus der Breite der Organisation heraus könnte man sagen. Also alle Teams aber auch alle Mitarbeiter und auch alle Gremien sind dazu angehalten, da entsprechend Input mit reinzugeben. Das heißt, es kann natürlich auch von unserer Scrum-Master/Agile Coach Riege kommen. Das die sagen, wir sehen gerade in der Organisation die und die Herausforderungen und wollen das angehen. Das kann auch mal aus der Geschäftsführung oder dem Gesellschafterkreis irgendwie rauskommen. 

Das kann aber genauso, das ist eigentlich also so eine meiner Lieblings-Stories, sage ich mal, aus unserer Agile Org, einfach ein Student sein, der die Baustelle hat, dass er im Rahmen seines Studiums den, aus privaten Gründen jetzt letztendlich, den Standort wechselt und eben nicht mehr in Wiesbaden arbeitet und wir zu der damaligen Zeit eigentlich keine Remote-Arbeiter hatten, ja. Und er eben sagt, ich möchte gern als Entwicklungs-Team Mitglied künftig Remote arbeiten. Wie kann denn der Rahmen dafür sein. Das hat er eben reingebracht und dann sind verschiedene Leute mit dazugekommen und das ist im Rahmen geklärt worden, zum Beispiel, dass das eben, wenn der Mitarbeiter oder die Mitarbeiterin vorher schon etwas Arbeitserfahrung bei uns hat, und quasi unsere Kultur schon verinnerlicht hat und letztendlich dann auch das Team die Bereitschaft hat, zu sagen, okay, wir lassen uns darauf ein, dass wir eben künftig einen Remote-Team Member haben. Dass das der Rahmen ist, unter dem das möglich ist. Und so konnte dieser studentische Mitarbeiter damals, der mittlerweile Vollzeit bei uns arbeitet, eben so eine Veränderung treiben, und die wirklich selbständig aber auch irgendwo Pushen mit Unterstützung natürlich aus der Organisation dann raus.

Matthias:

Du sagst, so 2012 ging das so los, mit der Agile Org. Arbeiten wir jetzt, 8 Jahre später, nach genau dem selben Prozess, oder gab es da auch eine gewisse Evolution drin?

Paul:

Ja, man kann sagen, die Agile Org hat sich so fast jedes Jahr weiter verändert. Das heißt, wir sind früher sehr stark von einem Scrum im Ansatz gekommen. Das hat sich dann eher in ein eher in einen Kanban-Modus verändert, sagen wir mal. Und so die Grundpfeiler sind heute immer noch existent. Als wir angefangen haben, waren wir vielleicht 50 Leute in der Organisation und haben als Beispiel einfach in dem Agile Org Review, also wir haben einmal im Monat, war auch gerade heute Vormittag, so ein Frühstück, das Agile Org Frühstück, wo die Arbeit im Team vorgestellt werden. Und initial war das Entscheidungsverfahren eben wirklich so, dass Zettel rumgegeben wurden. Es gab die Ergebnisvorstellung und dann konnten alle MitarbeiterInnen entsprechend ihr Votum abgeben und sagen, ich bin dafür, ich enthalte mich oder ich bin dagegen. Und sobald es auch nur ein Veto gab, ist es sozusagen nochmal in einen Prüfungsprozess reingekommen. Das muss halt ein begründetes Veto sein, aber man konnte letztendlich mit einem begründeten Veto eine Story an der Implementierung verhindern. 

Jetzt sind wir mittlerweile 190 Leute und natürlich hat sich da einiges auch im Rahmen dieser Agile Org verändert. Die Grundmechanismen sind noch sehr ähnlich, aber wir sind zum Beispiel auf dieses Entscheidungs-Verfahren umgestiegen, was wir selbst dann konsultativer Gruppenentscheid getauft haben. Quasi unsere Adaption von dem konsultativen Einzelentscheid, nur dass wir eben eine kleine Gruppe von Entscheidern dann eben an der Stelle wählen. Und ansonsten ist es noch ziemlich ähnlich. Man kann eben seine Themen aufbereiten. Das läuft bei uns natürlich auch über ein Jira-Projekt, wo ich eben mein Thema mit reinbringen kann. Kann mir dann Unterstützer holen und wenn unser VIP-Limit, das heißt die Anzahl der parallel gerade in Bearbeitung stehenden Themen, dass das hergibt, dass eine weitere Story mit reingenommen wird, dann wird daran gearbeitet und das zur Umsetzung gebracht. Und wir haben aber nicht mehr diesen festen monatlichen Zyklus. Die Frühstücke sind zwar noch monatlich, aber die Bearbeitung einer Story kann, ich sage mal, zwischen zwei Wochen und zwei Monaten so ziemlich, ja verschiedene Zeitfenster einfach einnehmen, bis sie dann zum Abschluss kommt. 

Matthias:

Lass uns zum Abschluss kurz, sag doch mal kurz was, wie wird denn das im Unternehmen angenommen? Stößt das auf großes Interesse?

Paul:

Ja, das ist jetzt natürlich seit 2012 irgendwie was, was wir machen. Das heißt, es ist mittlerweile sehr etabliert und Leute, die als Beispiel als Student zu uns kommen oder die jetzt eben nachträglich zu uns gekommen sind, für die ist das irgendwie ein Stück weit so gegeben, dass eben diese Möglichkeiten da sind, ja. Es ist was, wo man natürlich aber auch immer an der Akzeptanz weiter arbeiten muss. Das heißt, wir müssen eben immer wieder auch sicherstellen, und da sind unsere Agile Coaches durchaus auch sehr aktiv bei, dass wir halt sagen, okay, gewichtige Entscheidungen werden eben nicht einfach mal beiläufig getroffen, sondern, wenn sie wirklich Auswirkung auf die gesamte Organisation haben oder haben sollen, dann bitte auch schauen, dass das über die Agile Org läuft. So dass wir eben die gemeinsame Tragfähigkeit der Entscheidung dann eben auch sicherstellen können. 

Und das ist mittlerweile für uns, wie gesagt, sehr etabliert vom Vorgehen eine hohe Akzeptanz da. Es gibt durchaus immer auch mal Wünsche, kann man denn nicht manche Entscheidungen leichtgewichtiger fällen, und wir sehen auch immer wieder, dass wir an den Entscheidungsverfahren dann innerhalb der Story also, wir haben da verschiedenste Entscheidungsverfahren einfach ausprobiert. Dass man da auch immer wieder also quasi nicht dieser Grundmechanismus mit dem konsultativen Einzelentscheid, sondern manchmal entscheiden sich diese Entscheider eben auch ein Abstimmungsverfahren mit anzuwenden, um Feedback aus der Organisation zu bekommen. Und das ist einfach ein kontinuierlicher Lernprozess, welche Art von Feedback-Mechanismus dann für welches Thema funktioniert, damit man eben möglichst viele wichtige Stakeholder auch in die Entscheidung dann eingespannt hat. Und das ist wirklich ein kontinuierliches Lernen, ja. 

Matthias:

Okay, soviel zum Thema agile Organisation bei Seibert Media. Es ist ein kontinuierlicher Evolutionsprozess, aber ich hoffe, auch kritische Zuhörer fanden das interessant. Wir wollen es dabei an dieser Stelle bewenden lassen. Vielen Dank Paul, für die Einblicke. 

Paul:

Super gerne!

Matthias:

Einblicke gibt es auch in der kommenden Podcast-Folge. Dann sprechen wir über Software-gestützte Skalierungs-Projekte mit Agile Hive. Welche Stolperfallen da lauern können und wie so solche Transitionen möglich erfolgversprechend angepackt werden können. Für heute, vielen Dank fürs Zuhören, bleibt uns gewogen, bis zum nächsten Mal!