Sind wir nicht alle ein biss­chen agil?

Immer häufi­ger errei­chen uns Anfra­gen zur Einfüh­rung agiler Metho­den in Orga­ni­sa­tio­nen und Abtei­lun­gen. In unsere letz­ten Blog­bei­trä­gen von Dirk Jung und Anna Schulte haben wir uns dazu aus dem Blick­win­kel eines Orga­ni­sa­ti­ons­ent­wick­lers geäu­ßert. Wie aber sieht das im Einzel­nen ganz prak­tisch aus? Mit eini­gen netten Anek­do­ten aus dem agilen Arbeits­all­tag gewäh­ren wir in diesem Blog­bei­trag einige Einbli­cke, wie erste Schritte Rich­tung “mehr Agili­tät” ausse­hen können.

Auch wenn wir stets beto­nen, dass Agili­tät nicht über­all und in jede Abtei­lung einzie­hen muss, so möch­ten wir doch denen, die neugie­rig sind und meinen, hier etwas sinn­vol­les Neues zu entde­cken, ein paar Beden­ken gegen­über dem Thema Agili­tät nehmen und dazu anre­gen, sich Metho­den anzu­eig­nen, die auf die eige­nen Bedürf­nisse passen – und dabei Fehler zu machen und aus diesen zu lernen.

Stand-Up Meetings – Infor­ma­ti­ons­be­darf

Stand-Up Meetings sind erst­mal nur Meetings, bei denen die Teil­neh­men­den stehen – und da stehen auf Dauer eher unbe­quem ist, zeich­nen sich Stand-Ups meist durch ihre zeit­li­che Kürze aus. Vielen sind diese Meetings aller­dings als fester Bestand­teilt von Teams, die nach Scrum arbei­ten, bekannt. Jeden Tag zur selben Zeit tref­fen sich die Entwick­lungs­teams für maxi­mal 15 Minu­ten und tauschen sich (stehend!) kurz und bündig dazu aus, was jede*r einzelne gestern erle­digt hat, heute erle­di­gen möchte und mit welchen aktu­el­len Schwie­rig­kei­ten er*sie konfron­tiert ist. Das schafft Trans­pa­renz über den Projekt­fort­schritt und führt zu einer geteil­ten Einschät­zung, welche Aufga­ben wieviel Zeit in der Bear­bei­tung bean­spru­chen.

Wir spra­chen vor allem mit Start-Ups über Stand-Up Meetings. Oft hieß es dort: „Stand-Ups funk­tio­nier­ten bei uns anfangs über­haupt nicht.“ Gründe dafür waren u.a. zu viele betei­ligte Leute, zu wenig wesent­li­che Infor­ma­tio­nen oder ein zu klei­ner Raum. Die meis­ten Teams haben die Stand-Ups dennoch nach den ersten Fehl­ver­su­chen nicht gleich über Bord gewor­fen, sondern nach­ge­schlif­fen: Sie begrenz­ten die Perso­nen­zahl für das Meeting und einig­ten sich auf die Bespre­chung bestimm­ter Kern­the­men. Beson­ders bei Teams, die Stand-Ups außer­halb von Scrum nutzen, hat es sich bewährt, die zu bespre­chen­den Fragen auf die tatsäch­li­chen Infor­ma­ti­ons­be­darfe des Teams anzu­pas­sen.

Bei denk­mo­dell selbst gibt es Stand-Ups in klei­ner Runde von bis zu fünf Mitarbeiter*innen. Meis­tens handelt es sich um schnelle Brain­stor­ming-Sessi­ons mit einer vorde­fi­nier­ten Frage an der Kaffee­bar. Kein star­res Fest­hal­ten daran, was die „reine Lehre“ von Stand-Ups vorschreibst, sondern eine Anpas­sung an die prak­ti­schen Bedarfe des Teams.

„Agile Kommu­ni­ka­tion“ – Wissens­ma­nage­ment in der Test­phase

Bei Agili­tät dreht sich alles um Trans­pa­renz, Wissens­aus­tausch und eine funk­tio­nie­rende Lern­kul­tur. Dafür ist eine gute Kommu­ni­ka­tion unab­ding­lich. Am Anfang hieß das für viele klei­nere Orga­ni­sa­tio­nen oft: Ich kann zu jeder­zeit meine Kollegen*innen anspre­chen und mit Fragen löchern. Prima, wenn es wenige Mitarbeiter*innen sind und der Frage­mo­dus zum Tages­ge­schäft passt.

In manchen, beson­ders wach­sen­den, Orga­ni­sa­tio­nen sorgt das aber eher für Frust statt Lust. Wir haben unter­schied­lichste Umgangs­for­men damit kennen­ge­lernt: spezi­fi­sche Konzen­tra­ti­ons- und Kommu­ni­ka­ti­ons­stun­den; feste Team­mee­tings (ob Stand-Ups oder andere Kurz­tref­fen á la Jour-Fixe, Chat­ver­läufe, die mehr als 10 Zeilen über­schrei­ten, müssen in einem persön­li­chen Gespräch bei einem Kaffee geklärt werden…). Als funk­tio­nie­ren­des Kommu­ni­ka­ti­ons­me­dium hat sich bei vielen Orga­ni­sa­tio­nen „slack“ heraus­kris­tal­li­siert. Hier empfiehlt sich ein erster Test­durch­lauf, bevor man ein neues Kommu­ni­ka­ti­ons­me­dium auf die gesamte Kolle­gen­schaft loslässt.

Bei denk­mo­dell durch­lau­fen wir solch einen Test eben­falls. Bishe­ri­ges Ergeb­nis z.B. eine Anlei­tung zur Einstel­lung von „Push Nach­rich­ten“ in slack an alle Kollegen*innen senden. Hier gilt: Mögli­che Fehler­quel­len durch ein frühes Testen und Rumpro­bie­ren mit den Kolleg*innen (v.a. den weni­ger IT-affi­nen) schnell erken­nen und Abhilfe schaf­fen.

Der Kicker­tisch – ein Inno­va­ti­ons­mo­tor?

Vorab schon mal der Hinweis: Ein Kicker­tisch (oder auch mehrere Kicker­ti­sche) wird nicht Ihre Orga­ni­sa­ti­ons­kul­tur revo­lu­tio­nie­ren. In Unter­neh­men, die Inno­va­ti­ons­be­ra­tun­gen anfra­gen, steht er oft (unbe­nutzt und leicht stau­big) in einem Groß­raum­büro. Auf Nach­frage heißt es manch­mal, er diene Reprä­sen­ta­ti­ons­zwe­cken und soll die den Inno­va­ti­ons­wil­len zur Schau stel­len. Hier zeigt sich schön: Nur die Anwe­sen­heit des Kicker­tischs alleine bringt keine Verän­de­rung.

Wie nutzen Start-Ups den Kicker­tisch? Sie orga­ni­sie­ren Kicker­tu­niere oder rich­ten spezi­elle Kicker­pau­sen ein. Der Kicker­tisch steht an einem Ort, der als Pausen­raum genutzt werden kann – arbei­tende Kollegen*innen werden nicht durch das Spiel gestört. Es ist eine von vielen Möglich­kei­ten, Zeit und Raum für infor­mel­len Austausch und Begeg­nung zu schaf­fen. Nicht verschwei­gen möch­ten wir:, Selbst Start-Ups geben zu, in den stres­sigs­ten Zeiten auf den Spiel­spaß zu verzich­ten.

Gene­rell gilt: Für krea­tive oder inno­va­tive Arbeit sollte ein Raum nicht durch­ge­stylt, sondern flexi­bel und auf die Bedarfe des Teams ange­passt sein. Bei denk­mo­dell haben wir keinen Kicker­tisch – dafür können Mitarbeiter*innen indi­vi­du­ell einen Arbeits­stuhl wählen; auch mal im Stehen oder in einer “Kuschel­ecke” arbei­ten.

Design Thin­king Sprints – schnelle Ideen­ent­wick­lun­gen

Wäre es nicht wunder­bar, wenn man für jedes Problem ein Team zusam­men­stel­len könnte, das ein paar Wochen mit Design Thin­king an Lösungs­op­tio­nen arbei­tet? Eine schöne Vorstel­lung – doch bei weitem nicht Alltag in den meis­ten Orga­ni­sa­tio­nen. Der Ansatz gemein­sam inno­va­tive Lösun­gen zu entwi­ckeln, verlangt viel Vertrauen und gegen­sei­tige Offen­heit, die noch nicht in jede Orga­ni­sa­tion einge­zo­gen ist. Trägt Abtei­lung A wirk­lich etwas zur Lösung bei, wenn eine der Optio­nen ihr ggf. Kompe­tenz wegneh­men  könnte? Hat Abtei­lungs­lei­ter B ein echtes Inter­esse an der Lösung, wenn es bedeu­ten könnte, dass jemand aus seinem Team in ein ande­res wech­selt? Gibt es nicht doch unaus­ge­spro­chene Hier­ar­chien, die einer wirk­lich freien und krea­ti­ven Ideen­ent­wick­lung im Weg stehen?

Wie gelingt dennoch eine Lösungs­ent­wick­lung? Oft haben Einzel­per­so­nen eine Idee und entwi­ckeln einen ersten, eher „groben Proto­ty­pen“ – dieser wird dann vor dem Team präsen­tiert und erst dann wird gemein­sam weiter­ent­wi­ckelt. Selbst in agilen, lern­freu­di­gen Start-Ups gibt es von vielen Mitarbeiter*innen den Wunsch, eine Idee erst­mal „im Dunkeln“ allein zu entwi­ckeln. Wich­tig ist nur, dass Zeit für die Ideen­ent­wick­lun­gen zur Verfü­gung gestellt wird und es keine Ergeb­nis­ver­pflich­tung gibt. Und eben­falls wich­tig: Trans­pa­renz darüber, wer über die Ideen und den weite­ren Umgang damit entschei­det. Ist es das Team oder die Leitung? Inko­hä­ren­zen können zu Miss­stim­mun­gen und Demo­ti­va­tion führen.

Bei denk­mo­dell heißt diese Zeit der Ideen­ent­wick­lung „Entwick­ler-Werk­statt“: Themen können einge­bracht werden und zusam­men oder allein werden dann bestimmte Ideen weiter­ge­spon­nen.  Auch die Geschäfts­füh­rung nimmt aktiv daran teil – so kann es direkt auch einen Cross-Check von „Wunsch“ und „Umsetz­bar­keit“ geben. Neben diesen “Werk­stät­ten” die eher 2‑Stun­den-Charak­ter haben, gibt es nun auch einen “denk­tag” – einen Tag, machen, worauf man Lust hat – keine Ergeb­nis­pflicht, keine Kund*innentermine.

Plan­ning Poker – Trans­pa­renz erhö­hen

Mit dem Plan­ning Poker kann in einem Team spie­le­risch Trans­pa­renz über Zeit­auf­wände für bestimmte Aufga­ben geschaf­fen werden. Jede*r Spieler*in erhält Spiel­kar­ten mit Zahlen darauf. Die zu erle­di­gen­den Aufga­ben werden vorge­stellt, die Spieler*innen über­le­gen sich im Gehei­men, wie viel Aufwand für die Bear­bei­tung der Aufgabe notwen­dig ist  und wählen eine entspre­chende Zahlen-Karte. Wenn jede*r Spieler*in eine Zahlen-Karte gewählt hat, wird bis drei gezählt und die Karten werden zeit­gleich umge­dreht. Im Anschluss daran entsteht eine Diskus­sion: Gibt es große Unter­schiede in der Einschät­zung? Wenn ja, warum? Als wir mit Soft­ware-Entwick­lern gespro­chen haben wurde stets posi­tiv von der Methode berich­tet, aber oft hieß es auch: Wenn das Team zu klein ist, reicht es auch aus, einfach mitein­an­der zu reden. Jede Teil­auf­gabe durch­zu­spie­len frisst einfach zu viel Zeit und bringt dann keinen Spaß mehr. In Teams, die etwas größer sind, sich gerade neu kennen­ler­nen, wenig vertraut mitein­an­der sind oder in Teams mit sehr domi­nan­ten und sehr intro­ver­tier­ten Team­mit­glie­dern kann die Methode aber durch­aus hilf­reich sein.

Das alles sind nur Beispiele. Sie sollen deut­lich machen, dass es aus unse­rer Sicht nicht empfeh­lens­wert ist, Metho­den 1:1 zu kopie­ren. Über­le­gen Sie statt­des­sen im Team : Welche Methode macht Sinn und welches Ziel verfol­gen wir damit? Probie­ren Sie die Metho­den aus, fördern Sie konstruk­tive Kritik und feilen Sie dann gemein­sam an der Anpas­sung der Metho­den auf ihre eige­nen Team-Bedürf­nisse. So kann sich Schritt für Schritt mit der Etablie­rung von agilen Metho­den auch ein agiles Mind-Set entwi­ckeln. Aber Achtung: Trägt die Leitungs­ebene das nicht mit, können selbst die besten Metho­den nur schei­tern!