LeanKanban Central Europe am 8./9. November 2016 in Hamburg: Programm steht
 
Das Motto der Lean Kanban Central Europe (LKCE) in diesem Jahr lautet "let the flow begin"! Gemeint ist der Fluss der Arbeit durch unsere Organisationen. Ich freue mich schon sehr auf Anfang November, wenn wir in Hamburg wieder mehr als 300 Teilnehmer begrüßen dürfen zur größten Kanban-Konferenz überhaupt. Wir haben eine neue tolle Location hier an der Elbe, nur ein paar Hundert Meter vom it-agile-Büro entfernt. Das Board hat wieder ein tolles Programm zusammengestellt, zum ersten Mal haben wir eine ganze Reihe von deutschsprachigen Vorträgen dabei. Insofern ist die LKCE bestimmt auch etwas für dich.

Ich empfehle rechtzeitige Registrierung, weil zum einen der Preis regelmäßig steigt. Zum anderen könnte ich mir vorstellen, dass wir dieses Jahr ausverkauft sein werden. Ich würde mich freuen, wenn ich dich auf der LKCE treffe!
 
Auszüge aus dem Programm:
Keynote von David Anderson: "Creating Robust, Resilient & Antifragile Organizations"
Keynote von Julian Birkinshaw "Fast Forward: New Organising Models in a Complex World"
Julia Culen: "Holacracy: Not Safe Enough to Try"
Andy Carmichael: "Irrefutable Demand: When you can't say 'no', understand your Options – you may have more thank you think!"
Maria Torrijos: "Dealing with a massive Backlog at the world's no. 2 online travel company"
Pawel Brodzinski and Tomek Rusiliko: "Statistical Forecasting: Software Estimation made easy"
Auf Deutsch spricht Oliver Finker: „Mit Wahrscheinlichkeiten planen – die größten Fallstricke zu aussagekräftigen Forecasts“
Auf Deutsch Anna Lorenz und Peter Rößler: „Warum gibt es keinen Flow beim Minigolf-Spielen?“

Details zu diesen und vielen weiteren Programmpunkten findest du auf der Seite der LKCE.
 
 
Direkt zur Registrierung...
 
Zu den Sessions...
 
Zur LKCE...
Lean Kanban Central Europe 2016
   
 
 
 
 
   
Neue Planning-Poker-Kartensets: Mit it-agile immer gute Karten
 
Vor ein paar Wochen war es mal wieder so weit: Unsere Vorräte an Planning-Poker-Kartenspielen waren aufgebraucht. Das ist für uns immer eine tolle Chance zu schauen, welche Veränderungen wir für die nächste Version machen. Aus dem Feedback vieler Kunden (evtl. auch deinem) und dem, was meine Kollegen bei Kunden gehört haben, ist ein neues Kartenset entstanden mit folgenden Features:
 
Planning-Poker-Kartenset für 5 Teammitglieder
Je Teammmitglied die Karten 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?
Karten der Teammitglieder über Farben unterscheidbar (Vorder- und Rückseite): rot, blau, grün, lila, gelb
Planning-Poker-Kurzanleitung und Tipps

Die alten Kartensets enthielten zwar mehr Scrum-Erklärkarten, aber die meisten Kunden fanden Karten für mehr Teammitglieder wichtiger. Wir haben das voll ausgereizt und jetzt 5 statt bisher 3 Karten je Wert.
 
Zur Shopseite Planning-Poker Kartenset...
neue Planning Poker Karten von it-agile
   
 
 
 
 
   
Dimensional Planning: Artikel-PDF direkt zum Download
 
Ein früherer Kollege von uns hat berichtet, dass er bei einer recht bekannten und erfolgreichen Software-Entwicklungsfirma in Stockholm war. Dort hatte man sich zum inkrementellen Entwickeln der Produkte ein stufenweises Konzept ausgedacht, damit man möglichst früh einsetzbare Software/Produkte erhält und diese dann Schritt für Schritt weiter ausbauen kann. „Ach, ihr meint Dimensional Planning!“ sagte der Kollege dann. Davon hatten sie nicht gehört, die Konzepte waren aber sehr ähnlich. Das erleben wir öfter.

Falls du das Konzept auch noch nicht kennst oder es deinem Product Owner oder anderen im Unternehmen gerne nahelegen möchtest, empfehle ich dir den Artikel „Dimensional Planning – der Universalhäcksler für User Storys, Iterationen und Releases“ von Stefan Roock, den wir in der agile review 01/2013 veröffentlicht haben. Er ist also nicht ganz neu, aber das Thema ist nach meiner Erfahrung noch immer aktuell.

Hier der Abstract:
Kleine User Storys haben viele Vorteile. Leider ist nicht immer offensichtlich, wie man eine größere Anforderung in mehrere kleine User Storys zerlegt. Dieser Artikel stellt Dimensional Planning vor: eine relativ unbekannte, aber umso mächtigere Technik zum Zerlegen von User Storys, die sich auf Iterationen und Releases anwenden lässt – und sogar auf Organisationsentwicklung.   

Viel Spaß beim Lesen und Ausprobieren!
 
 
Zum Artikel-PDF...
 
Zur agile review...
Dimensional Planning – Der Universalhäcksler für User Storys
   
 
 
 
 
   
Neuer Workshop: Konfliktmanagement für Scrum Master und agile Coaches 
 
In unseren Scrum-Trainings besprechen wir immer die Herausforderungen, die Selbstorganisation für Scrum-Teams und ihren Scrum Master mit sich bringen. Der größte Unterschied zu klassischen Teams mit einem Teamleiter oder Projektleiter besteht darin, dass es im Zweifelsfall nicht den einen Entscheider gibt, sondern das Team sich einigen muss. Das birgt Konfliktpotenzial und so ist es eine wichtige Kompetenz für jeden Scrum Master, souverän mit Konflikten im Team umgehen zu können.

Für diese Herausforderung haben wir für den 2./3. November ein Seminar mit Conrad Giller neu im Angebot, der ein erfahrener Konfliktmanagement-Trainer ist und sein Training speziell auf die Bedürfnisse von Scrum Mastern und Scrum-Teams angepasst hat.


Zusätzlich bieten wir am 23. November mit Conrad einen Worskhop zur „Entwicklung von Scrum-Teams“ an, in dem jeder Teilnehmer über sein aktuelles Team reflektiert und jeder nächste Schritte für die Arbeit mit seinem Team mitnimmt, um es noch besser zu machen.
 
 
Zu Konfliktmanagement für Scrum Master...
 
Zu Entwicklung von Scrum-Teams...
Konfliktmanagement für Scrum Master
   
 
 
 
 
   
Agiler Tipp: Team-Sprechstunde einführen
 
Eigentlich wollte ich diesen Monat vom Fit-for-Purpose-Survey vom letzten Mal berichten, aber dafür haben zu wenige den Fragebogen ausgefüllt. Ich sammle also weiter Erfahrungen in meinen Schulungen und komme später darauf zurück.

Der Tipp in diesem Monat stammt von meinem Kollegen Stefan Zumbrägel:
Mein Team arbeitete in einem skalierten Umfeld mit weiteren Teams in einer Multi-Projekt-Umgebung. Alle Teams waren Komponententeams mit jeweils etwas Grundwissen über die anderen Komponenten. Dadurch waren die Teams trotz der bestehenden Abhängigkeiten in der Lage zu einem gewissen Grad autonom zu arbeiten. Innerhalb ihrer Komponente waren die Teams für den kompletten Prozess bis zu Produktivsetzung und den anschließenden Support zuständig.

Da die Komponente meines Teams eine sehr zentrale in dem System war und sich einige Teammitglieder zudem in den bestehenden Communities of Practice engagierten, kam es immer wieder vor, dass Personen aus anderen Teams oder aus dem Linienmanagement mit Fragen an einzelne Teammitglieder herantraten. Dies war im Projektumfeld und im Unternehmen die Kultur und hat zunächst aus Sicht des Teams kein Problem dargestellt.

Mit der Zeit wurden diese Anfragen aber mehr und wurden bald vom gesamten Team als Störung empfunden. Es war schwierig, im Pairprogramming oder allein über einen längeren Zeitraum konzentriert an den Sprintinhalten zu arbeiten.

Das Team war in einer Zwickmühle. Man wollte auf der einen Seite die Teams unterstützen, aber selber konzentriert arbeiten. So entstand die Idee Team-Sprechzeiten in Anlehnung an Öffnungszeiten bei Behörden einzuführen. Nur in dieser Zeit stand das Team für Anfragen von außerhalb zur Verfügung. Es wurde eine Stunde pro Tag angeboten. Außerhalb dieser Zeiten wurden Anfragen freundlich aber bestimmt abgewiesen. Konkret haben wir Schilder an den Türen mit den Sprechzeiten angebracht und zum Teil das Telefon auf den ScrumMaster weitergeleitet.

Als ScrumMaster war ich gerade in der ersten Zeit stark gefordert, das Team bei der Aufrechterhaltung dieser Regel zu unterstützen. Zum einen moralisch, zum anderen vor allem in der Argumentation mit und gegenüber den anfragenden Personen. Diese „Pförtnerrolle“ war nach einer Eingewöhnungszeit nicht mehr notwendig.

Das Ergebnis war sehr positiv. Wenig überraschend: Das Team konnte in der ungestörten Zeit viel effizienter und stressfreier arbeiten. Die Anzahl der Anfragen ging stark zurück. Es wurde nicht untersucht woran das lag, die Vermutung ist aber, dass selber Lösungen gefunden oder Anfragen gebündelt wurden und damit besser beantwortet werden konnten. Außerdem gab es viel positive Resonanz für die konsequente Umsetzung. So kam aus anderen Teams die Rückmeldung, dass es so zwar einen kleineren Zeitraum gibt für Fragen, dafür aber auf jeden Fall jemand da ist und sich Zeit für die Anfrage nimmt.



Hattest du in deiner agilen Praxis ein Erlebnis, das du teilen magst? Dann schreibe mir doch gerne.    

 
 
Agiler werden mit it-agile...
Agiler Tipp: Teamsprechstunde
   
 
 
 
 
   
Aktuelle Schulungstermine
 
Hier als Service für dich unsere nächsten Schulungs- und Workshoptermine, in denen es noch freie Plätze gibt:

Kanban:
Kanban Management Professional 1 (KMP I) 13./14. September in Hamburg
Kanban Management Professional 2 (KMP II) 11./12. Oktober in Hamburg
Kanban Management Professional 1 (KMP I) 18./19. Oktober in Hamburg
Kanban Management Professional 1 (KMP I) 23./24. November in München
Kanban Management Professional 2 (KMP II) 6./7. Dezember in Hamburg
Kanban Management Professional 1 (KMP I) 13./14. Dezember in Hamburg

Scrum-Zertifizierungen:
Certified ScrumMaster Deluxe (CSM) 11.-13. Oktober in Hamburg
Certified Scrum Developer (CSD) 25.-27. Oktober in Hamburg
Certified ScrumMaster (CSM) 31. Oktober-1. November in Hamburg
Certified Scrum Master deluxe (CSM) 28.-30. November in Hamburg
Certified Scrum Developer (CSD) 29.November-1. Dezember in München
Certified Scrum Master (CSM) 6./7. Dezember in Hamburg
Certified Scrum Developer (CSD)19.-21. Dezember in Hamburg 

Scrum-Specials:
Konfliktmanagement für Scrum Master 2./3. November in Hamburg
Entwicklung von Scrum-Teams 23. November in Hamburg
Agiles Management:
Denkwerkstatt Komplexithoden 23. September in Hamburg
Management Agiler Teams 27.-29. September in Hamburg
Management 3.0 5.-6. Oktober in Hamburg 

Effektive Meetings:
Grundlagen der Meeting-Moderation 18.-19. Oktober in München
Eine Frage der Retrospektive 3. November in Hamburg
Eine Frage der Retrospektive 6. Dezember in München
Grundlagen der Meeting-Moderation 19./20. Dezember in Hamburg
 
Schulungsübersicht it-agile...
it-agile Schulungen
   
 
 
 
 
   
Schiff des Monats: Parat
 
Einen Schlepper mit dem Namen Parat zu versehen, finde ich eine gute Idee. Der Schlepper hat eine Länge von 28m und eine Breite von 9m, hilft aber Containerschiffen mit mehr als 300m Länge beim sicheren Ein- und Auslaufen im Hafen.

Parat zu sein, scheint mir ein ganz wesentlicher Aspekt agiler Arbeitsweisen zu sein. Das ist das Flexibilitätsversprechen. Es bedeutet eben nicht, einfach immer nur schneller zu sein, sondern parat und bereit, wenn man gebraucht wird.
Parat kann dabei ganz unterschiedliche Dinge bedeuten, mir fallen zunächst ein:
gut vorbereitet auf die konkrete Aufgabe
gut vorbereitet im Sinne genereller Fähigkeiten/Ausbildung
verfügbar
sofort einsatzbereit
jederzeit fähig, sich Unvorhergesehenem zu widmen

Agile Teams sind für ihren Bereich immer gut vorbereitet sein, gerade cross-funktional besetzte Teams sind oft auf überraschend breite Anwendung vorbereitet. Mit dieser Verfügbarkeit ist es meist leicht, mit Beginn eines neuen Sprints kann neu geplant werden. Das hat einen Preis, weil es die Umpriorisierung bisher eingeplanter Aufgaben bedeutet. Diese verschieben sich dann nach hinten.

Wenn man anderes wollte, also Teams, die direkt parat sind für neue Aufgaben ohne etwas liegenlassen zu müssen, dann könnte man von den Hafenschleppern lernen: Die sind nämlich nicht zu 100% ausgelastet. Das schafft Flexibilität.


Bist du immer parat? Schreibe mir gern deine Meinung dazu.



Für eine größere Aufnahme des Schiffes, klicke einfach auf das nebenstehende Bild.
 
Schiff des Monats: Parat