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?

Scrum bedingt per se einen kulturellen Wandel in Organisationen. Die agile Denkweise und die klare Sichtbarkeit von Problemen schafft den Grundstein für eine Kultur der stetigen Verbesserung (eine so genannte Kaizen-Kultur).

Nun hat sich während der letzten Jahre noch eine andere Art und Weise entwickelt, wie man eine solche Kultur etablieren kann. Die Methoden Kanban ist in die Softwareindustrie eingezogen und auch wenn manche den Begriff aus der Automobilindustrie kennen, so ist hier nur das transferiert worden, was im Softwarebereich funktioniert hat – unter dem gleichen Namen. Damit ist ein Werkzeug entstanden, was in seinem Grundprinzip ersteinmal bestechend simpel wirkt:

Wir visualisieren, was wir eh schon tun und begrenzen unsere Arbeit in einem Prozessschritt, um einen ausbalancierten Wertfluss zu erzeugen. Das hat viele schöne Nebeneffekte, wie bessere Teamarbeit und eben auch die Möglichkeit, zu erkennen, wie die eigenen Produktionsprozesse optimiert werden können.

Stattet man dann die Mitarbeiter auch noch mit der Befähigung aus, eigene Optimierungen durchführen zu dürfen und auch bei dabei eingeführten Fehlern das Vertrauen der Vorgesetzten zu genießen, beginnt ein Unternehmenswandel zur reifenden agilen Organisation.

Viele Wartungsteams haben sich dank der freien bzw. nicht notwendigen Einteilung in Iterationen dieses Modells bereits bedient und es lohnt sich in passenden Situationen, Kanban als Weg in die agile Welt zu nutzen. Evolution statt Revolution?

Die Frage ob Scrum oder Kanban besser ist, mag man beantworten mit der Frage, ob man besser eine Schraube oder einen Nagel verwendet, um ein Gemälde zu befestigen: Anbringen kann man es wohl mit beidem – mal ist jedoch das eine sinnvoller und mal das andere. Und manche meinen auch, es sei sowieso ein Vergleich von Äpfeln mit Birnen. Ich denke mir: Hauptsache es schmeckt.

Auch aus der Sprecherperspektive war das Bild rund: Ein Speakerdinner zum Wohlfühlen, eine gewissenhafte Programmauswahl und problemlose Technik machten es uns leicht. Das clevere Farbleitsystem verriet, wo welcher Raum ist und die Agenda hatte jeder direkt um seinen Hals am Keylane. An diesen Kleinigkeiten merkt man, dass die drei Köpfe des Just Community e.v. nicht zum ersten Mal eine Veranstaltung dieser Größe organisiert haben – und es war dieses Jahr die NRWConf mit den meisten Teilnehmern überhaupt seit Gründung.

Mit meiner Session names “Teamcharta – Gemeinsam sind wir stark” hatte ich mir ein Thema vorgenommen, dass auch im agilen Umfeld eher exotisch als typisch ist und ich war sehr neugierig, wie der Anklang bei einer Entwicklerkonferenz wohl sein würde.

Ein voller Saal überraschte mich positiv: Viele Teilnehmer hatten ein großes Interesse, über den technischen Tellerrand hinauszusehen und sich mit der Art und Weise zu beschäftigen, wie Teams Konflikte vorbeugen können.

Und auch von dem Feedback einiger Teilnehmer zu anderen Sessions habe ich den Eindruck gewonnen, das viele inhaltlich spannende Beiträge dabei waren.

Eine rhetorisch gekonnte und inhaltlich ansprechende Keynote von Dr. Ingo Dahm machte aus dieser Veranstaltung nicht zuletzt einen Gewinn. Mein Fazit: Wirklich lohnenswert.

Durch die tolle Unterstützung von weiteren Helfern, vor allen Dingen Kostja Klein, der die Frankfurter .NET Usergroup leitet, konnten wir in kurzer Zeit eine rege und aktive Gruppe gründen, die sich seitdem ca. einmal im Monat trifft zum Austausch, Weiterbilden und Fachsimpeln im Landhaus Ludwigshafen.

Im Schnitt waren bei unseren Treffen beinahe zwei dutzend .NET Freunde, was uns davon überzeugt hat, dass hier in Mannheim, Heidelberg, Ludwigshafen und Umland ein großes Interesse an Technolgie und Austausch existiert.

Alle Sprecher für dieses Jahr und der erste Sprecher für 2012 stehen auch schon fest. Und mit diesem schönen Ausblick bleibt nur noch zu sagen: Happy Birthday #dotnetrna.

Und wer möchte, der sage weiter, dass es diese Gruppe gibt. Wir freuen uns immer über neue Gesichter und neue Sprecher mit spannenden Themen.

Jeder Mensch bringt seine Tagesform ein, seine aktuellen Lebensthemen, seine Erfahrung und viele weitere Faktoren, die das Zusammenleben und Arbeiten beeinflussen. Es gibt verschiedene Modelle zur Gruppenentwicklung, welche diese Komplexität auf ein handhabbares Maß reduzieren.

Kommen Scrum-Teams neu zusammen oder werden in ihrer Zusammensetzung stärker verändert, durchlaufen sie verschiedene Entwicklungsstufen. Als erstes dominieren Unsicherheit, Hoffnungen und Befürchtungen aber auch Vorfreude. Die Teammitglieder kennen sich teilweise oder auch vollständig noch nicht.

Hier bieten sich als ScrumMaster vor allem Aktivitäten an, die Vertrauen aufbauen und ein Kennenlernen ermöglichen:

* Kollaborative Gruppenspiele
* Vorstellen bisheriger Projekt- und Erfahrungshistorie
* Partnerinterviews mit anschließender Gruppenpräsentation
* Wertearbeit von Einzelnen und der Gruppe

Besteht eine grundlegende persönliche und berufliche Basis, können Gemeinsamkeiten und Verbindendes herausgearbeitet werden. Formen der Zusammenarbeit können definiert werden, durch:

* Eine gemeinsame Vision/Mission
* Teamnormen bzw. eine Teamcharta
* Konventionen auf technischer Ebene

In der darauffolgenden Differenzierungsphase bildet sich die informelle Hierarchie eines  Teams heraus. Rollen werden detaillierter ausgeprägt, es klärt sich, wer sich für welche Themen verantwortlich macht und fühlt. Um mit auftretenden Spannungen umgehen zu können, kann ein ScrumMaster diese Aktionen planen:

* Einführung des Teams in Gewaltfreie Kommunikation oder andere Kommunikationsmodelle
* Erarbeiten von Regeln für konstruktives Feedback
* Anwenden von Win-Win-Strategien wie dem Harvard-Modell für Verhandlungen

Darauffolgend kann das Team in die hochproduktive Arbeitsphase gelangen – es steht in der vollen Blüte Scrums.

Durch die gemeinsame Basis, vereinende Ziele und einen wertschätzenden, vertrauensvollen Umgang entsteht eine Atmosphäre, die Kreativität und Fehler zulässt. Dies kann noch weiter gestärkt werden durch:

* Lernen von Kreativitätstechniken
* Verbindende Events (Teamabende, Outdoor-Events)

Die meisten genannten Aktivitäten können im Rahmen einer Retrospektive oder gesonderten Teamentwicklungsworkshops eingebracht werden – abhängig vom Grad der Komplexität des Teams, der Herausforderungen und des Unternehmens.

Schaut man sich im Detail diesen aufwändigen Findungsprozess an, wird sich für viele die Frage nach der Häufigkeit von Teamveränderungen beantworten: Teams sollten so selten wie möglich verändert werden – außer sie funktionieren auch nach intensiver Investition nicht.

Und wie sollten nun Scrum Teams generell zusammengestellt werden? Darauf hat Mike Cohn eine Antwort (bzw. einige Fragen).