Heute gehen wir mit einem Prinzip aus dem agilen Manifest den kollektiven Burnout an, das uns hilft „nein“ zu sagen. Wir erklären Dir, warum es schwer ist nein zu sagen und welche vier Bedingungen Du in Deinem Projekt oder Produkt brauchst, damit Du nein sagen kannst, damit wir am Ende „ja“ zu den wirklich wichtigen Dingen sagen können.
9 neue Erkenntnisse für agile Teams mit Magic Maze
Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.
Magic Maze für agile Teams -Was bisher geschah…
In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem
Kollegen Veit sowie Stefan Zumbrägel beim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten.
Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze
Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!
Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.
Feedback aus der Community
Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten , in dem sie zwei Erkenntnisse geteilt hat.
„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“
Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.
„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.
Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!
Was wir neues gelernt haben
Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!
Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.
Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.
Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.
In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.
Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?
Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“
Viel Spaß beim Ausprobieren und Danke fürs Lesen!
Dieser Artikel ist 2019 bereits erschienen und jetzt neu veröffentlich worden.
Ich Habe Magic Maze im Dezember 2018 kennen gelernt, als mein damaliger Kollege Veit richter es in einer Open Space Session angeboten hat. Damals hatte er das Spiel schon einige Male eingesetzt und konnte wertvolle Erkenntnisse mit uns teilen. Seitdem habe auch ich es mit verschiedenen Teams genutzt. Wir haben es auch auf User Groups und Open Spaces eingesetzt, um es anderen Coaches in der Community vorzustellen, damit auch diese von diesem Brettspiel profitieren können. Und wer hätte es gedacht… es sind neue Erkenntnisse entstanden!
In diesem Blogbeitrag möchte ich alte und neue Erkenntnisse noch einmal zusammenfassen. Wer das Spiel noch nicht kennt, bitte erst den Beitrag vom letzten Jahr lesen, damit ihr die Spieldynamik versteht. Auf diese werde ich hier nicht mehr eingehen (mehr dazu im Originalartikel, welcher oben verlinkt ist,) sondern nur noch auf die Erkenntnisse.
Bereits in Teil 1 enthaltene Erkentisse:
Neue Erkenntnisse:
Dieses Learning hat auch deshalb so gut funktioniert, weil es eine Gruppe mit 8 Spielern war. Ich habe mich gefragt, warum das so ist und dieser Effekt bei kleineren Gruppen nicht so häufig zu sehen war.
Ich bin mir sicher es werden in den nächsten Runden weitere Erkenntnisse dazukommen. Ich bin jetzt schon total beeindruckt, wie ein Brettspiel ohne jegliche Anpassung so viele wertvolle Botschaften für agile Teams liefern kann. Und das verbunden mit Unmengen von Spaß. Denn ich habe noch keine Situation erlebt, in der die Spieler nach dem ersten Scheitern (und ja liebe Spieler, es ist normal das die erste Runde in die Hose geht 😉 ) aufhören wollten.
Last but not least, Ehre wem Ehre gebührt. Danke lieber Veit , dass du mir dieses Spiel gezeigt hast und auch vorher erkannt hast, dass es sich super für die Arbeit mit agilen Teams eignet.
Wer seine IT-Projekte mit einer agilen Methode wie Scrum oder IT-Kanban durchführt, findet immer wieder Hindernisse heraus, die das Unternehmen davon abhalten, effizient und mit Freude zu arbeiten. Mal ist es ein Product Owner, der zu selten greifbar ist für sein Team, mal ein abstürzender Build-Server und mal fehlende Fähigkeiten im Entwicklungsteam für eine neue Produkt-Herausforderung. Solche Hindernisse werden Impediments genannt.
Probleme rufen nach einer Lösung.
Und meistens wollen wir sie so schnell wie möglich weg haben. Aus dem Sinn, gelöst und erledigt. Nicht wahr? Natürlich – wir wollen handeln. Nicht zuletzt ist es ja auch ein Teil der Rolle eines ScrumMasters und des Managements, die Bahn frei zu machen für die Entwicklungsteams.
Mit dem schnellen Sprung vom Problem zur Lösungsidee verpassen wir häufig aber eine wichtige Chance: Dem Problem gewissenhaft auf den Grund zu gehen. Oft sind die wahrgenommenen Auswirkungen nämlich nur die Symptome eines darunterliegenden, tieferen Problems. Und wenn wir dies nicht herausfinden, ist unsere Maßnahme entweder erfolglos oder behebt die Grundursache nicht – und das Problem kommt wieder. Vielleicht in einer anderen Form, vielleicht zu einer anderen Zeit. Aber es ist nicht nachhaltig gelöst. Wir verbennen Zeit und Energie.
Im Umfeld des Toyota Produktionssystems hat sich aus dieser Erkenntnis das so genannte A3-Denken entwickelt. A3 Denken ist dabei eine strukturierte iterative Vorgehensweise zur gemeinsamen Lösung komplexer Impediments.
Dabei ist physisch gesehen ein A3 tatsächlich ein DIN A3 großen Papierbogen mit einer spezifischen Unterteilung in Prozessschritte. Das A3-Denken ist somit also ein Denkprozess zur Lösung von Impediments in einem Unternehmen. Und dieser Prozess wird dann auf solch einer Vorlage festgehalten.
Die Prozessschritte eines A3s decken dabei einmal den vollständigen PDCA – Zyklus ab. Wir umkreisen ein Problem, um seine Essenz zu verstehen, erstellen Handlungsalternativen, setzen diese um und nutzen die Ergebnisse, um zu lernen.
Welche Vorteile ergeben sich daraus?
Während man mit einem solchen strukturierten Problemlösungverfahren arbeitet, trainiert man sein logisches Denken und kommt immer wieder auf neue Aspekte, die einem vorher nicht klar waren.Sie möchten gleich loslegen und einen A3 selbst ausprobieren?
Eine deutsche A3 – Vorlage finden Sie hier als Download (PDF, 1.2 MB). Um den Denkprozess dahinter zu lernen, empfehle ich das Buch Managing To Learn und die sehr schön illustrierten A3-Thinker Karten. Ein Beispiel zu einem ausgefüllten A3 – Bogen finden Sie auch bei Henrik Kniberg (auf Englisch).
Was kann man damit noch tun?
Wie eine ScrumMasterin letztens in einem Einzel-Coaching zu mir sagte: Das kann man ja auch prima im privaten Bereich einsetzen, um neue Lösungen zu entwickeln. Vielleicht kennen Sie ja auch diese immer wiederkehrenden Themen, die irgendwie nie richtig gelöst werden? Was würde passieren, wenn Sie einmal die Forscher-Brille aufsetzen und auf die Suche nach den Grundursachen gehen?
Wir sind häufig in Besprechungen. Oft mehrmals täglich. Unsere Kollegen laden uns ein, an wichtigen Themen zu arbeiten. Oder wir sie. Der Einladende entwirft eine Agenda, definiert ein Thema, stellt ein Problem zur Diskussion, möchte ein Ziel erreichen in einer vorgegebenen Zeit. Manchmal sind diese Besprechungen wirklich wichtig, oft nur teilweise informativ, manchmal versucht man aus Höflichkeit nicht zu laut zu gähnen oder gleich ganz zu entschlafen.
Das muss doch anders gehen. Wie wäre es, wenn wir das grundlegende Prinzip unserer Besprechungen umdrehen würden? Was passiert, wenn wir nur einen minimalen strukturellen Rahmen vorgeben und freiwillige Teilnehmer einladen, über ihre Lieblingsthemen zu reden? Wie wäre es, wenn man dabei nicht nur gehen könnte, wenn einen die Langeweile ergreift sondern sogar selbstverständlich geht, wenn man woanders mehr Beitragen kann? Und es sich dabei noch wie die längste Kaffeepause der Welt anfühlt?
Genau das ist ein so genannter Open Space:
Unter einem Open Space versteht man ein erprobtes Konferenzformat des selbstorganisierten Austausches, um in wichtigen Themen neue Ideen und Lösungen zu finden.
Seit 1985 gab es weltweit über 60.000 dieser Zusammenkünfte von manchmal nur 6 bis weit über 2.000 Personen. In allen möglichen Branchen wurden so neue Räume geöffnet für Lösungen und Innovationen.
In Deutschland trifft sich die agile Szene ebenfalls gerne auf diese Art und Weise. Denn es gibt viele Ähnlichkeiten zwischen agilem Arbeiten und einem Open Space:
Ein Facilitator erleichtert Selbstorganisation: Wie ein Agile Coach ist ein Open Space Facilitator jemand, der den Prozess sehr gut kennt und bei den Inhalten den Teilnehmern vertraut. Er unterstützt durch laterale Führung die Selbstorganisation aller, um gemeinsam bemerkenswerte Ergebnisse zu erreichen.
Und jeder gestaltet dieses Ergebnis mit. Denn ein Open Space lebt von dem, was die Teilnehmer mitbringen sowie eine Scrum Einführung von den Zielen und Wünschen der Teammitglieder und Organisation abhängt. Ohne Leidenschaft und Verantwortungsübernahme wird agiles Arbeiten schnell fade und langweilig, jede Besprechung zur Einschlafhilfe.
Informationen sichtbar machen, um zu entscheiden: In einem Open Space visualisieren wir die Themen des Tages an einem Anschlagbrett, ganz ähnlich wie ein Taskboard eines agilen Teams. So sieht jeder alle Informationen und kann die richtigen Entscheidungen treffen.
Wir dürfen Freiwilligkeit voraussetzen. Wer bei einem Open Space teilnimmt, ist nur da, weil er es möchte. Auch zu einer neuen Arbeitsweise wie Scrum kann man niemanden zwingen, das wäre ein Anti-Pattern.
Die Intelligenz der Gruppe nutzen: Wenn viele kluge Köpfe zusammenkommen, sind Lösungen komplexer Probleme leichter. Verschiedene Perspektiven der Intelligenz der Gruppe nutzt Scrum in seinen Besprechungen und Schätzverfahren. Im Open Space nutzen wir dieses Potential voll aus.
Fazit: Agile Transformationen und Open Spaces passen von ihrer Grundhaltung hervorrgangend zusammen, was auch die oben aufgezeigten Parallelen unterstreichen. Nutzen Sie die Kraft des Open Space in Ihrem Weg zum agilen Unternehmen.
Dan Mezick, der diese Idee beim Scrum Gathering Paris darstellte, zeugt auch von positiven Erfahrungen beim Einsatz von Open Space in agilen Transitionen und bemerkenswerten Ergebnissen.
Wann hatten Sie das letzte Mal ausgiebig Zeit, mit allen Ihren Kollegen zusammenzukommen, um intensiv die Themen zu besprechen, die Ihnen am Herzen liegen? Wenn das schon eine Weile her ist, dann probieren Sie doch einmal einen Open Space bei Ihnen aus! Und wenn Sie in einer agilen Transition sind, dann erst recht.
Stellen Sie sich vor, Sie würden in Ihrem Unternehmen agile Methoden wie Scrum oder IT-Kanban einführen. Vielleicht arbeiten Sie sogar schon so?
Softwareentwickler arbeiten nun in kleinen Teams von 5 – 9 Personen. ScrumMaster und Agile Coaches investieren viel Energie, diese Teams zu stärken und zu schützen. Im Laufe der Zeit entwickelt dabei jedes Team seinen eigene Definition davon, wie gute Softwareentwicklung aussieht und funktioniert.
Doch was ist mit Querschnittsthemen?
Wie koordiniert man gemeinsame Auslierferungen, an denen mehrere Teams arbeiten? Wie lernen wir teamübergreifend neue Softwareentwicklungspraktiken? Wie entwickeln wir Entwicklungsrichtlinien, die für alle Teams passen? Wo kommen Tester zusammen, um herauszufinden, was gute Qualität für sie bedeutet?
Wenn wir agil mit mehreren Teams arbeiten möchten, brauchen wir teamübergreifend einen Weg, solch einen Austausch zu gestalten. Eine Art von loser Interessensgemeinschaft aus Praktikern. Menschen, die freiwillig und aus Leidenschaft zusammenkommen – vielleicht wie wir Deutschen das so gerne in Vereinen tun (nur weniger bürokratisch)?
Vor über 20 Jahren beschäftigten sich die Sozialforscher Jean Lave und Étienne Wenger mit der Bedeutung von sozialen Konstrukten in Lernprozessen. Und sie formten den Begriff der „Communities of Practice“ – kurz: CoP.
Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden.
Eine Teilnahme an solch einer Community ist immer freiwillig – und unabhängig vom bisherigen Wissensstand. Anfänger, Fortgeschrittene und Experten treffen sich regelmäßig, um gemeinsam zu lernen.
Wie beginnt man nun so eine Community of Practice?
Das ist leicht! Derjenige, der für ein Thema eine große Leidenschaft besitzt, sucht nach Gleichgesinnten im Unternehmen. Man legt gemeinsam erste Ziele fest und lädt alle interessierten Kollegen zu einem großen Willkommens-Termin ein. Dort informiert man dann über das Vorhaben und bittet die Teilnehmer, um Feedback, ob sie in Zukunft auch mit an Bord sind. Ein erfahrener ScrumMaster als Experte für Teamprozesse kann von Anfang an schon als Facilitator den Weg der CoP begleiten.
Wie sähe Ihre Firma mit solchen Lerngemeinschaften aus? Was wäre dann anders? Wer würde zu welchen Themen wohl im Austausch sein? Wenn Sie Lust bekommen haben, selbst eine Community of Practice zu Gründen oder Kollegen dabei zu helfen, mit ihrer Initiative erfolgreich zu sein, empfehle ich Ihnen dieses Buch. Und danach viel Spaß bei der Umsetzung! Denn gemeinsames Lernen macht uns doch oft am meisten Spaß, oder?
Während Scrum schon seit etlichen Jahren die Veränderung in den IT-Abteilungen der Welt anführt, hat sich in den letzten Jahren noch ein Weg zu mehr Agilität entwickelt: IT-Kanban. Es lohnt sich daher, die Frage zu stellen, wo beide Wege Ähnlichkeiten besitzen und auch zu erkennen, wo Unterschiede sind, um entscheiden zu können, welche Vorgehensweise besser passen kann.
Scrum ist ein Framework für die Entwicklung und Wartung komplexer Produkte in Teamarbeit. IT-Kanban ist eine Change Management Methode, die eine schrittweise Transformation einer IT-Abteilung ermöglicht. Die Richtung dieser Veränderung kann hin zu mehr Agilität sein, muss es aber nicht. Das hängt von Ihren konkreten Zielen ab.
Scrum ist eine Revolution. Eine drastische Veränderung im Unternehmen, die auf diese Weise viele Probleme auf einmal beseitigen kann und alle anderen deutlich sichtbar macht.
IT-Kanban hingegen setzt auf Evolution in kleinen Schritten. Für manche Firmen ist dieser Weg angenehmer, dafür verpasst man möglicherweise das Potenzial, das in einer radikalen Veränderung steckt.
Ein wichtiges Konzept teilen beide Vorgehen: Sie etablieren Pull-Systeme also Umgebungen, in denen die Teams selbst entscheiden, wieviel Arbeit sie annehmen wollen. Und da es bei dieser Arbeit darum geht, mit möglichst wenig Aufwand den Kunden so früh wie möglich zufrieden zu stellen, folgende beide dem Denken der Lean Production (schlanke Produktion).
Das Sichtbarmachen von Wissensarbeit ist eine weitere Stärke, die beide Vorgehen nutzen: Durch Taskboards werden die in Arbeit befindlichen Aufgaben sichtbar und transparent für alle: Fortschritt wird greifbar.
Ein wichtiges Ziel ist eine optimierte Wertschöpfungskette. Das Mittel dazu die Etablierung einer Kaizen – Kultur durch Inspektion und Adaption.
Während Scrum dazu feste Iterationen als eine Art „Projekt-Herzschlag“ einsetzt, folgt IT-Kanban dem Fluß der Arbeit durch das System: Besprechungen werden durch situative Notwendigkeit einberufen.
Bei allen Unterschieden und Gemeinsamkeiten stellt sich damit die Frage, welcher Weg für Sie besser passt? Neben diesem Überblick ist die tiefere Beschäftigung mit beiden Vorgehensweisen wichtig, um die richtige Wahl für Ihre Situation zu treffen, denn der Transfer auf Ihren Kontext ist das Entscheidende.
Das klappt zum Beispiel mit einem Tagesworkshop, einer professionellen Kanban-Simulation oder auch im Selbststudium – für den weiteren Einstieg finden Sie hier entsprechende Buchtipps.
Jeder Entwickler hat es schon einmal erlebt: Man kommt morgens zur Arbeit und ein Kollege hat sich krank gemeldet und wird vielleicht sogar längere Zeit nicht mehr ins Büro kommen.
Wer kümmert sich nun um die liegenbleibenden Aufgaben? Hat jemand das notwendige Wissen und kennt den Quelltext des Programms und die darin getroffenen Designentscheidungen gut genug, um schnell übernehmen zu können?
Um so schlechter das Wissen im Team verteilt ist, um so höher ist der etwas sarkastisch benannte „Truck-Faktor“ – die Wahrscheinlichkeit, dass das Projekt scheitert, wenn ein Entwickler ausfällt.
Eine Lösung ist der regelmäßige Austausch über geschriebenen Quellcode. Während eine Version davon die bekannten Quellcodereviews darstellen, ist die aktivere Variante das so genannte Pair Programming („Programmieren in Paaren“).
In einem permanenten Wechselspiel von zwei Entwicklern vor einem Computer entsteht so Quelltext, der während der Entstehung von vier Augen gesehen wird. Der gerade entwickelnde Kollege kommentiert während er Quelltext schreibt, was er tut, denkt also quasi laut.
Wenn der Programmierer, welcher gerade nicht die Tastatur hat, Fragen, Anmerkungen oder Ideen hat, teilt er sie dem Partner mit oder bittet kurzerhand um die Tastatur und „läßt Code sprechen“. So entsteht eine Feedbackschleife direkt dort, wo die Kunst bzw. das Handwerk stattfindet.
Dies spart nicht nur anderweitigen Kommunikationsaufwand, macht häufig mehr Spaß und hilft, Teams zusammenzubringen sondern steigert auch die Qualität, denn es rutschen weniger Bugs in den Produktivcode, wie die Grafik erläutert: Nur noch die Fehler, die beide Entwickler machen würden, kommen ungesehen davon.
Der zeitliche Aufwand steigt dabei, jedoch arbeiten Paare oft etwas schneller, sodass mit leicht höheren Produktionskosten gerechnet werden muss – dies ist jedoch häufig eine sinnvolle Investition in vielen Vorhaben, die eine längere Lebensspanne überdauern sollen, berücksichtigt man die oben genannten Vorteile. Vielleicht kennen Sie ja die Kosten von Fehlern, die an Ihre Kunden ausgeliefert worden sind? Entscheiden Sie selbst, ob diese Investition interessant sein kann!
Übrigens wird dann auch die Planung einer Iteration leichter, denn mehr Entwickler können nun immer mehr Aufgaben bearbeiten, da sie das benötigte Wissen gemeinsam haben.
Meine Empfehlung: Probieren Sie es aus und sprechen Sie über die Erfahrungen in einer Retrospektive.
…und wie wäre es eigentlich mit Pair Administration, Pair Designing und Pair Management?
Update: Nächster Management 3.0 – Kurs am 25. / 26.10.2012 in Mannheim – jetzt noch anmelden
Wir Ingenieure finden die Betrachtung, dass die Welt kausal funktioniert, irgendwie einleuchtend. Ich werfe Geld in den Fahrkartenautomaten und er druckt ein Ticket aus. Tut er das nicht, ist der Drucker vielleicht defekt oder das System muss neu gestartet werden. Aber nicht nur Ingenieure, die meisten Menschen sind der Meinung, dass es in der Regel einen Grund für ein Verhalten oder eine Situation gibt. Manchmal findet man ihn vielleicht einfach nicht so leicht. Oder?
Dieses Kausalität genannte Phänomen hat unsere Managementkultur stark geprägt. Führungskräfte versuchen in chaotischen Zuständen oder bei drohenden Fehlschlägen regelmäßig, die Kontrolle über die Situation zurückzugewinnen und die vermeintlich verantwortlichen Faktoren in die gewünschte Richtung zu beeinflußen. Im schlimmsten Fall gibt es die Suche nach einen Schuldigen.
Kausalität leistet der Wissenschaft einen unschätzbaren Dienst: Siedepunktberechnungen und Konstruktionspläne, vorhersagbare Flugbahnen von Raketen werden möglich. Und doch gibt es genügend Fragen, die wir nicht beantworten können: Wird unser Softwareprojekt wie geplant mit den definierten Funktionen fertig werden? Wie wird das Wetter in drei Wochen sein? Komme ich pünktlich zu meinem Termin am Freitag Abend durch die Münchener Innenstadt?
Wieso können wir diese Fragen nicht exakt beantworten? Was ist anders an ihnen?
Die Antwort ist die Komplexität. Damit ist nicht gemeint, wie man schnell denken könnte, dass es unüberschaubar viele Faktoren in einer Fragestellung gibt, sondern das unvorhersagbares Verhalten eines Systems. Dies zeigt uns zum Beispiel das Eulersche Dreikörperproblem von nur drei simplen Wassermolekülen: Die Zutaten sind simpel, das Systemverhalten komplex.
Solche Gegebenheiten blieben auch unseren Forschern nicht verborgen: Mittlerweile gibt es eine ganze Wissenschaft, die sich mit solchen Zusammenhängen beschäftigt, genannt die Disziplin der Komplexitätstheorie.
Wenn wir aufhören, kausales und lineares Denken auf komplexe Systeme wie Softwareprojekte und Teams anzuwenden und stattdessen auf die Komplexitätstheorie setzen, bedienen wir uns eines Modells, dass deutlich nützlicher ist und uns Antworten auf Fragen ermöglicht, die wir sonst nicht erhalten. Die Anwendung dieses Ansatzes auf die Führung von Scrum- und Kanban-Teams heißt „Agiles Management„.
Agiles Management ist ein häufig übersehener Teil agilen Vorgehens. Es gibt viele verfügbaren Informationen über agile Softwareentwicklung, agiles Testen und agiles Projektmanagement, aber wenig konkrete Praktiken für Entwicklungs- und Teamleiter. Unabhängig davon müssen auf dem Weg zum agilen Unternehmen aber nicht nur Entwickler, Tester und Projektmanager neue Praktiken lernen. Auch Entwicklungs- und Teamleiter müssen eine solche neue Herangehensweise zur Führung und Steuerung agiler Organisationen lernen.
Mehrere Studien identifizieren, dass das traditionelle Management das grösste Hindernis bei der Einführung agiler Softwareentwicklung ist. Entwicklungsleiter und Teamleader dürfen also neu erfahren, was ihre Rolle in der agilen Organisation ist.
Jürgen Appelo hat sich seit einigen Jahren mit genau diesem Thema in seinem bekannten Blog auseinandergesetzt, im Buch „Management 3.0“ sowie den gleichlautenden Kursen seine Erkenntnisse aus seiner eigenen Zeit als Manager einer großen agilen Firma in den Niederlanden veröffentlicht.
Zweimal hatte ich im vergangenen Jahr die Gelegenheit, Jurgen in seinen Kursen zu besuchen und bin zu der Überzeugung gekommen, dass die Denkweisen und Werkzeuge, die er entwickelt hat, vielen Führungskräften im 21. Jahrhundert helfen können, professionell und erfolgreich in komplexen Umgebungen zu arbeiten. Daher biete ich in Kooperation mit Jurgen als offizieller Trainer in diesem und den kommenden Jahren offene Management 3.0 Kurse in Deutschland an.
Wenn auch Sie sich diesem Thema intensiver widmen möchten, finden Sie vieles dazu in Jurgen Appelos Buch und in meinen Kursen.
