intrinsify.me

Überrasche doch mal Deine Schwierigkeiten

Über die Erhöhung der Komplexität von Lösungssystemen

Photonachweis: © www.berlin-bits.de

Über die Erhöhung der Komplexität von Lösungssystemen

Betrachtest Du Komplexität als eine hohe Anzahl von Überraschungen, dann ist es gut das eigene Unternehmen überraschbar aufzustellen, neugierig und wach. Berücksichtigst Du nun noch, dass es zur Lösung komplexer Probleme mindestens ein ebenso komplexes Lösungssystem braucht, stellt sich die Frage wie dieses im Arbeitsalltag aussehen kann. Zum Glück sind Menschen komplexe Wesen – das Potential liegt in der mutigen und leidenschaftlichen Intensivierung der Zusammenarbeit.

Was Scrum von Design-Thinking lernen kann

Agile Methoden wie Scrum und Kanban haben sich in der Softwareentwicklung durchgesetzt und erobern nun weitere Branchen. Dazu kommen Design-Thinking Teams, die oft einen erstaunlich hohen „agilen Reifegrad“ – eine beeindruckende kontinuierliche Zusammenarbeit – aufweisen, so dass sich die Frage stellt, was Scrum und Kanban von Design-Thinking lernen können.

Ganz kurz – was ist Design-Thinking?

Eine Haltung und iterative Arbeitsweise um die Erfolgswahrscheinlichkeit von Lösungen zu erhöhen: Ein multidisziplinäres Team aus offenen Köpfen, die gemeinsam lernen, wachsen und Lösungen für knifflige Probleme finden wollen. Ein gestaltbarer Raum – der reale Arbeitsraum aber auch der Freiraum im Kopf – um mit viel Empathie für den Nutzer dessen Bedürfnisse zu erkunden. Ein Lösungsdenken, welches sich zunächst nur im Raum der Wünschbarkeit entfaltet und erst später die Frage nach wirtschaftlicher und technischer Machbarkeit stellt. Und die Einsicht enthält, dass alle Ideen nur Hypothesen sind, die getestet und bewiesen werden wollen.

Das macht die Entwicklung von Produkten und Features schneller, günstiger und fröhlicher.

Wie Design-Thinking Teams agieren

Ein typischer Tag kann so aussehen:

Musik schallt aus einem Zimmer, Kaffeeduft erfüllt den Flur. Das Onboarding am Morgen findet heute in einer Sofa-Ecke statt. Innerhalb von 10 Minuten wird geklärt: Gibt es neue Informationen? Mit welchen Gefühlen starten wir in den Tag? Was sind die Hauptthemen für heute?

Es folgen Tagesplanung und Verabredungen für die nächsten 2 bis 3 Stunden. Wie folgen wir unserer Richtung? Was wird benötigt? Was kann das Team gemeinsam? Wo sollte sich das Team aufspalten und wann wird ggf. ein Coach benötigt? Wann ist der nächste Synchronisationspunkt und welche Ergebnisse wollen wir dann liefern?

Wird erkannt, dass externe Hilfe nötig ist werden sofort die Netzwerke der Teammitglieder angesprochen.

Ein Teammitglied nimmt spätestens jetzt die Rolle des „kleinen Diktators“ ein und wird darauf achten, dass die Gruppe die verabredeten Timeboxen einhält und fokussiert bleibt. Oft basteln sich die Teams dafür kleine Requisiten – einen Hut, eine kleine Keule, eine Halskette mit einem Wecker daran… – um die Rolle so überzeugter spielen zu können.

Entscheidungen werden so spät und so schnell wie möglich gemeinsam nach dem Konsent-Prinzip (ich habe keinen schweren Einwand dagegen) getroffen.

Nach jeder Timebox (max. 90 Minuten) gibt es eine Unterbrechung, um die Aufmerksamkeit umzulenken, beliebt sind Warm-Ups – kleine körperliche Spiele – die wieder Sauerstoff in jede Zelle pusten und bei denen gelacht wird.

Da das Team sehr viel gemeinsam arbeitet gibt es von allein ein Work-In-Progress Limit auf ein Thema / eine Story.

Hat sich das Team doch ein mal aufgeteilt werden in einer Team Synchronisation / Sharing Session die gesammelten Einsichten geteilt und sofort visuell verarbeitet – mit vielen Haftnotizen an Boards, Wänden, Fenstern, Menschen etc. – mit gesammelten Artefakten und Erinnerungshilfen wird der Teamspace dekoriert.

Neue Informationen beeinflussen daraufhin das weitere Vorgehen. Zu Tagesbeginn war dieser Stand nicht vorhersehbar, daher gibt es mit Blick auf die aktuelle Entwicklung alle 2 bis 3 Stunden eine erneute Planung. – Vielleicht werden nun weitere Informationen beschafft, Ideen generiert oder kritische Funktionen in Prototypen überführt.

Die Ergebnisse des Tages werden Stakeholdern, Nutzern oder anderen Design-Thinking Teams vorgeführt, das Feedback wird dankend angenommen und bei der weiteren Entwicklung berücksichtigt.

Spätestens zum Ende des Arbeitstages findet ein Debrief / eine Retrospektive statt: Wie geht es dem Team? Was hat sich verändert? In welche Richtung soll morgen gemeinsam weiter gearbeitet werden?

Da die Arbeitsweise Spuren hinterlässt, wird gemeinsam aufgeräumt.

Wie agile Scrum Teams agieren

Ein typischer Tag kann so aussehen:

Individuelles Ankommen – ein freundliches „Moin“ an die, die schon bei der Arbeit sind, Kaffee holen, Taskboard checken, vielleicht eine Frage stellen, warum der nächtliche Test wieder nicht auf grün steht und dann allein an den Computer.

Daily Standup Meeting – beim täglichen Planungsmeeting wird dem ScrumMaster ein Statusbericht abgeliefert, Task-Zettel werden verschoben und gelegentlich ergibt sich eine Verabredung, weil man an einer Stelle nicht alleine weiter kommt.

Pair Programming – Aus der Verabredung beim Daily Meeting ergibt sich eine Zusammenarbeit zu zweit für ein paar Stunden, bis das Problem gelöst ist.

Individuelles Verabschieden – zum Tagesende hin geht ein Entwickler nach dem anderen, die die immer spät beginnen sitzen dafür abends lange, es wird dunkel vor den Fenstern, nur noch zwei der 8 Schreibtische sind erleuchtet, leises Tastaturklappern erfüllt den Raum, gelacht hat schon seit 3 Stunden keiner mehr.

Zugegeben… dieses Bild ist extrem gezeichnet, aber beide Szenarien existieren.

Ein Gedankenspiel: Wie sieht es aus, wenn ein Softwareentwicklungsteam den Arbeitsmodus des oben beschriebenen Design-Thinking Teams annimmt?

Drei Prinzipien kennzeichnen die Arbeit in hoch performanten Teams:

  1. Selbstbestimmung,
  2. Zusammenhalt und
  3. Richtung!

Es ist ein bisschen so wie bei Schwarm- und Zugvögeln:

  • Achte auf Dich und entscheide, was Du glaubst entscheiden zu können – stoße nicht mit den anderen zusammen,
  • Bleibe bei einer nachhaltigen, gemeinsamen Geschwindigkeit und
  • Folge der Richtung (des Zentrums des Schwarms).

Weiterhin gilt:

  • Wir machen keine Fehler, wir lernen.
  • Wir heißen Veränderung willkommen.
  • Wenn es Spass macht, machen wir es richtig.

Das klingt schon auch alles nach Scrum, aber in der Realität lassen viele Unternehmenskulturen das nicht zu. Einen großen Anteil der Performance-Verhinderung in Scrum-Teams tragen dabei die klassischen Management-Strukturen aus dem letzten Jahrhundert sowie die Tatsache, dass es einen Mangel an guten Programmierern gibt und daher jeder, der programmieren kann, auch schnell in ein Scrum-Team „gesteckt“ wird – egal ob er oder sie agil arbeiten möchte oder nicht.

Design-Thinking Teams werden dagegen sehr aufmerksam zusammen gestellt, der Aufwand die richtigen Menschen für die jeweilige Herausforderung zusammen zu bringen ist um einiges höher.

Der Transfer

Projizieren wir nun den exemplarischen Tagesablauf des Design-Thinking Teams auf ein Scrum-Team:

Zwischen 8 und 9 Uhr kommen die Entwickler zur Arbeit, checken ihre Mails, plaudern mit den Kollegen, betanken sich mit Kaffee und haben dann den Kopf frei, um in einen „gemeinsamen Schaffensprozess“ einzutauchen. Eine kurze Onboarding-Session bestätigt die gemeinsame Richtung für den Tag, Details werden geplant und je nach Komplexitätsgrad der anstehenden Aufgaben werden Verabredungen für die Zusammenarbeit zu zweit und zu mehreren getroffen.

Ein „Kümmerer“ achtet auf Zeit und Fokus und erinnert seine Kollegen an die regelmäßigen „großen Pausen“, Toiletten und Küchen sind etwas weiter entfernt, so dass ein paar Schritte den Kreislauf regelmäßig anregen.

Anstelle eines Daily-Standup-Meetings gibt es mehr kurze Synchronisationspunkte. Für den Fall, dass das gesamte Team gemeinsam an einem Computer arbeitet (Mob-Programming) entfallen auch diese Synchronisationspunkte, denn diese Arbeitsweise ist gemeinsame Lernsession, Review und Abnahme in einem. Je mehr Menschen gemeinsam arbeiten um so weniger Aufgaben sind gleichzeitig „in Progress“ und um so höher ist die Durchflussgeschwindigkeit und Qualität der Arbeitsergebnisse. Entscheidungen werden sofort getroffen, geplant wird kontinuierlich.

Fertige Arbeitsergebnisse werden anderen Teams am Nachmittag präsentiert, Feedback wird als Anregung und Geschenk angenommen.

Eine kurze Retrospektive zum Abschluss des Arbeitstages gibt einen Ausblick auf eine vielleicht noch bessere Zusammenarbeit am nächsten Werktag.

Wenn wir uns nun noch vorstellen…

  • dass diese Softwareentwicklungs-Teams genauso aufmerksam wie Design-Thinking Teams zusammengestellt werden – sich die einzelnen Mitglieder vielleicht um die Mitgliedschaft bewerben, weil sie das jeweilige Produkt toll finden oder bereits Personen im Team sind, denen sie gerne folgen mögen,
  • dass der Arbeitsraum vom Team leicht an dessen Bedürfnisse angepasst werden kann,
  • dass Software-Architekten, Kollegen aus der Qualitätssicherung und des IT-Betriebs auch Mitglied des Entwicklungsteams sind,
  • dass die Product-Owner Rolle fest im Team verortet ist und so Ideen gemeinsam entwickelt, priorisiert und in Form von quick’n’dirty Prototypen an Nutzern getestet werden, bevor sie in die Umsetzung gehen,

… dann wird dort Unglaubliches entstehen.

Verpasse keine neuen Beiträge und werde zum Experten der Neuen Wirtschaft

Geschrieben von

Blogauthor Alexander Krause intrinsify.me
Alexander Krause

Alex ist agiler Ruhestifter und Arbeitsweltverbesserer. Er hilft Menschen zu einer Richtung und selbstbestimmten Zusammenarbeit zu finden, um Produktentwicklung schneller, günstiger und freudvoller zu machen.

Erschienen am

Donnerstag, 21. Januar 2016

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

Benachrichtige mich zu:
avatar
wpDiscuz
X