Viele Jahre lang haben Führungsrkräfte versucht, das Verhalten durch möglichst detaillierte Vorgaben, Anweisungen und Regeln zu beeinflussen – ein Vorgehen, dass den Anleihen des Taylorismus geschuldet zu sein scheint. Das funktionierte mal mit mehr, mal mit weniger Erfolg.

Ein Trick in der Interaktion mit komplexen Systemen ist: Entscheidungen und Verantwortung werden dorthin gegeben, wo die Informationen präziser und kleiner sind. In der Regel ist das eine Delegation weiter “nach unten”. So werden die Entscheidungen besser und auch eher mitgetragen. Rahmenbedingungen helfen dabei, wichtige Entscheidungsaspekte zu berücksichtigen.

Komplexe Systeme haben emergente Eigenschaften: Das Verhalten des Systems kann nicht alleine durch das Verhalten der einzelnen Teile des Systems bestimmt werden. Ein Team ist mehr als die Summe seiner Mitglieder.

Als Konsequenz daraus verwendet man in agilen Vorgehensweisen die Intelligenz der Gruppe an allen wichtigen Stellen: Planung, Schätzungen, Reviews, Retrospektiven. Keine dieser Tätigkeiten kann von einer Person alleine in hoher Qualität geleistet werden, denn dafür sind zu wenige Informationen in der gedanklichen Abbildung jedes Einzelnen. Wer einmal bei einer Planning Poker Sitzung dabei war, kann dies dort leicht erkennen: Abweichende Schätzwerte sind immer in einem unterschiedlichen Wissenstand begründet. Hier wird aus den Einzelinformationen ein Gruppenmodell, dass die Komplexität einer Anforderung besser wiederspiegelt.

Aus dem selben Grund delegiert man – wie oben geschrieben – also auch möglichst viel Kontrolle an die Teams selbst: Sie haben das vollständigste Model zur Verfügung, um ihr eigenes System zu steuern. So steigt die Stabilität des Gesamtsystems Abteilung und Organisation.

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”.

Über Moderationstechniken, Change Management auf spielerische Weise und durch Berichte von agilen Konferenzen. Besonders Christophs Einsatz ist es zu verdanken, dass die Gruppe sich immer wieder zusammengefunden hat und auch weiter bestehen wird.

Weitere Infos zu den weiteren kommenden kostenfreien Treffen der Scrum Usergroup Rhein-Neckar finden Sie hier. Kommen Sie vorbei, wir freuen uns!

Doch warum gibt es solch eine Veranstaltung überhaupt? Braucht die Unternehmenswelt hier einen Fortschritt? Spiele und professionelle Berufswelt, ist das überhaupt vereinbar?

Der Beruf des Agile Coaches beinhaltet die Vermittlung von Wissen und entscheidenden Erkenntnissen. Wer einen Coach in sein Unternehmen bestellt, möchte eine Veränderung in Richtung “agile Arbeitsweise”. Richtig eingesetzt, helfen Spiele dabei, Gegebenheiten erlebbar zu machen, so dass sie im Gedächtnis bleiben. Wer Freude beim Lernen hat, lernt leichter.

Wer sich im Trainingsmarkt umsieht, weiß, dass solche Lernformen längst ein Standard in offenen und geschlossenen Seminaren sind. Der Transfer dieser Methodik in den Coaching-Kontext ist also eine konsequente Fortsetzung einer erfolgreichen Lehrstrategie.

Viele tolle Sessions waren bei diesem Open Space dabei: Über Service Design Thinking, AgileFairytales und Teamentwicklungsspielen stand für mich vorwiegend das Thema, wie Teamleiter und Linienmanager neue Prinzipien und Arbeitsweisen begreifen dürfen.

Ein Vortrag der den Prozess der Spielerstellung erklärte, war dafür eine tolle Grundlage und schnell fanden sich mehrere Gruppen, die an neuen Spielideen arbeiteten und diese mit Teilnehmern testen konnten. Das abendliche Networking über die drei Tage war sicherlich ein Highlight für viele und die Organisatoren haben einen großen Dank verdient.

Auf den Punkt gebracht: Schön, in solch einer vielseitigen und inspirierenden Community tätig zu sein.

An jedem Intervallende habe ich die Möglichkeit, mein Produkt meinem Kunden oder Anwender zur Verfügung zu stellen. Damit ist die Zeitspanne, bis ich mit neuen Funktionen am Markt oder beim Kunden bin sehr kurz. Diese Taktung können oft nur wenige Mitbewerber erreichen. Sobald die Anwendung so ausgeliefert ein Mindestmaß an Nutzwert für die Zielgruppe darstellt, kann abgerechnet oder anderweitig monetarisiert werden.

Was bei Großprojekten oft Monate und Jahre dauert, beginnt hier von Anfang an. Darüber hinaus habe ich frühes Feedback meiner Anwender, welches maßgeblich in meine Produktgestaltung einfließen kann und so eine gute langfristig erfolgreiche Positionierung am Markt sichern kann.

Spinnt man den Gedanken der häufigen Auslierferung weiter, kommt man schnell zu der Erkenntnis, dass solche Lieferintervalle bestimmte technische Voraussetzungen haben: Kontinuierliche Integration, automatische Tests und schnell durchführbare Deploymentprozesse. Hat man diesen Reifegrad erreicht, entsteht quasi mit jedem Feature, dass ein Team in einer Iteration abschließt, Wertschöpfung für das Unternehmen. Welche Projekte können das schon behaupten?

In der Realität ist dies für viele Unternehmen ein Weg, der Mut, Ausdauer und Kraft kostet. Und vielleicht liegt gerade hier das Potential, sich vom Mitbewerber abzuheben oder auch als interner Dienstleister überzeugen zu können. Noch sind es wenige Firmen, die so weit gegangen sind und ich bin mir sicher: es werden jedes Jahr mehr werden.

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.

In der ruhigen und winterlichen Kulisse empfing uns der Bodensee in einer der schönsten Locations, in denen ich bisher gesprochen habe: Ein renovierter Wasserturm, direkt am Ufer des Sees, im obersten Stockwerk mit zwei ausgebauten Räumen versehen, die wir nutzen konnten.

Wie wir zu Beginn meines Vortrags schnell feststellten, war jedoch keiner wegen des Gebäudes hier. Die unterschiedlichen Motivationen der Gäste im vollständig belegten Raum erfassten wir vorneweg (siehe Bild).

Ein Anliegen meines Vortrags sollte es sein, Bewußtheit für die Andersartigkeit von Menschen zu schaffen und den Hintergrund von Konflikten zu thematisieren.

Als Lösungsangebot konnten die Zuhörer die Teamcharta für Scrum Teams und das Harvard Verhandlungsmodell als Inspiration, um strittige Situationen besser behandeln zu können kennenlernen.

Eine Teamcharta ist ein gemeinsam erstelltes Dokument, welches diese Teile enthalten kann:

•  Rollen (Wer gehört zum Team, in welcher Funktion?)
•  Verantwortlichkeiten (Wer darf was?)
•  Prozessvereinbarungen (Wie lange ist unsere Iteration?)
•  Regeln des Zusammenlebens (Handys aus im Meeting?)
•  Meetingzeiten (Wann ist das Daily Scrum?)
•  Technische Vereinbarungen (Testgetrieben? Testcoverage?)

Gerne verwende ich ein Mindmap-Diagramm, um alle Aspekte optisch ansprechend abzubilden. Der Ausdruck gehört dann an die Wand des Teamraums.

Die rege Diskussion um den Einsatzbereich des Werkzeugs im Anschluß des Vortrags machte Spaß und mündete darin, dass eine Teamcharta für sehr gute Teams das Zusammenfinden erleichtert, normale Teams am meisten profitieren und schwierige Teams, also solche mit nicht aufgearbeiteten Problemen auf der Beziehungsebene der Mitglieder, mit einer Teamcharta so deutlich auf den Konflikt gestoßen werden, dass man sich den Einsatz vorher gut überlegen darf.

Ansonsten gilt: Alles kann, nichts muss. Gestaltet das Dokument so, wie es für das Team funktioniert und Konsenz und Dissenz werden transparent. Ein weiterer Schritt zu einem Hochleistungsteam ist dann zurückgelegt.

Als Agile Coach arbeite ich sehr gerne und häufig in Gruppen: Entweder in Entwicklerteams oder mit Führungskräften wie Product Ownern, ScrumMastern und Managern in einem Transitionsteam.

Dabei sehe ich eine wichtige Aufgabe darin, die Gruppenarbeit effizient zu gestalten. Zu einem Meeting gehört ein Ziel, eine ausgearbeitete Agenda und ein passender Zeitrahmen. Wie kann der Moderator die Gruppe darüberhinaus unterstützen?

Ein Teil seiner Aufgabe ist das Festhalten von Gruppenergebnissen. Ein kurzes Fotoprotokoll von Whiteboards, Flipcharts und mehr ist meine übliche Vorgehensweise. Irgendwie war ich in der Rückschau mit der optischen Qualität der Ergebnisse nicht richtig zufrieden.

Es darf ein wenig mehr sein.

Deswegen habe ich mir Mitte des Jahres einen Tag gegönnt, um Neues über Flipchart- und Whiteboard – Illustration zu lernen. Es ist verblüffend, was alles möglich ist, wenn man sich auf ein Thema konzentriert und einen guten Mentor hat. Von Werkzeugen, über Kniffe und ästhetische Gestaltungsregeln waren schöne Impulse dabei.

Alleine die Beschäftigung mit seinen Arbeitsmitteln ist eine Sache, die man doch selten macht in Bezug auf Marker, Stifte, Papier und Hilfsmittel. Warum haben Stifte eigentlich dicke und dünne Seiten, wenn sie keine Rundspitze haben? Was kann man damit machen? Für Techniker wie mich auf jeden Fall eine ungewohnte Materie.

Die letzten Monate habe ich gebraucht, um das neu gelernte zu verinnerlichen und gut anwenden zu können, in der Hoffnung, den Menschen, mit denen ich arbeite, oft eine treffende Visualisierung anbieten zu können, die dabei hilft, zu verstehen, was ich kommunizieren möchte.

Das bisherige Kundenfeedback war positiv, was mich sehr freut. Zu meinem Scrum-Prozessschaubildern und Trainingsinhalten gibt’s also nun eine hübsche Garnitur. Denn das Auge isst ja bekanntlich mit.

Wer dies nicht hinreichend berücksichtigt, läuft Gefahr, schwelende und immer wieder neu auflodernde Konflikte zu erleben und mögliche Synergien unter Kollegen zu verhindern. Eine Teamcharta ermöglicht es, Klarheit zu schaffen, bevor Konflikte entstehen.

Um sich auf gemeinsame Konventionen einigen zu können, bedarf es jedoch auch einer guten Methodik. In einem kurzen Exkurs führe ich Sie in die Theorie der Verhandlungsführung bei gegensätzlichen Positionen ein, damit Sie auch in festgefahrenen Situationen einen Konsens finden. Ein Praxisbeispiel vertieft die Theorie des Vortrags.

Ich freue mich über die Einladung der Scrum User Group Bodensee und auf viele Freunde agiler Methoden. Die Teilnahme ist kostenfrei. Kommen Sie doch auch vorbei! Mehr Infos finden Sie hier.

Wer gibt in agilen Teams an wen Leistungsbeurteilungen heraus? Soll ein ScrumMaster das Team bewerten? Kann das ein Product Owner machen? Gibt es Boni und wenn ja für wen und unter welchen Bedingungen?

Nach einer mehr als einstündigen Diskussion der sieben Teilnehmer ging die Gruppenmeinung zusammenfassend in die nachstehende Richtung, wenn auch keine vollkommene Einigkeit bei dieser komplexen Fragestellung bestand:

• Boni sind schwierig bis gar nicht sinnvoll zu nutzen, was auch meiner Kenntnis der aktuellen Theorien zur intrinsischen und extrinsischen Motivation von Menschen entspricht. Geld muss möglichst schnell aus den Köpfen der Mitarbeiter verschwinden.
• Wenn man Boni nutzen möchte, sollten diese überraschend ausgeschüttet und nicht vorhersehbar sein. Ob diese dann für jeden Mitarbeiter monetär sind oder als Sachmittel für Teaminvestitionen zur Verfügung stehen, ist diskussionswürdig.
• Zielvereinbarungen sind mit Vorsicht zu genießen, wenn sie dem Teamziel entgegenstehen. Es gab im Gespräch Beispiele dazu, wie Einzelzielvereinbarungen zur Beschädigung von Gruppen- und Unternehmenszielen beigetragen haben.
• Ein Linienmanager kann sich in regelmäßigen Einzelgesprächen und mit Unterstützung von 360°-Feedback sein Bild über die Teamleistung eines Mitglieds machen. Eine Anpassung einer Vergütung oder andere Sachleistungen hängen daneben vor allem natürlich auch von den Bedürfnissen des Mitarbeiters ab.

Die Diskussion zu diesen wichtigen Themen ist damit nicht zu Ende sondern steht viel mehr an einem Anfang, auf den auch Bücher wie Beyond Budgeting und Einflussfaktor Personalmanagement Antworten geben wollen.

Es hilft, zu berücksichtigen, dass sich Systeme nach den Metriken ausrichten, an denen sie gemessen werden. Aus diesem Grund sind dies in Scrum eben nur potentziell auslieferbare Features.

Andere Metriken führen in diesem Kontext häufig zu unschönen Dysfunktionen. Ein Beispiel: Würde man ein Team zum Beispiel an seiner Commitment-Erfüllungsrate messen, entstehen schnell seltsam Phänomene, wie Teams, die bewusst zu wenig Arbeit annehmen, um genug Sicherheit zu haben, ihr Commitment auch in jedem Fall zu halten.

Und wie vergüten Sie Ihre Mitarbeiterleistung angemessen?