Agile Review-Sonderausgabe zu New Work
Anlässlich unseres 10-jährigen Jubiläums haben wir eine Sonderausgabe der Agile Review aufgelegt. Diese erste Sonderausgabe haben wir passend zu 10 Jahren it-agile dem Thema New Work gewidmet, denn unbestritten ist die it-agile GmbH hier ein Vorreiter. In der Agile Review finden sich diese Themen:
Markus Gärtner erläutert die Sicht von Frederik Laloux auf moderne Organisationen in seinem Beitrag „Organisationen neu erfunden“.
Unser Kollege Ilja Preuss hat zu New Work mit Mark Poppenburg von intrinsify.me gesprochen.
Henning Wolf hat sich mit Björn Krings von ver.di unterhalten.
Im gemeinsamen Artikel von Markus Gärtner und Henning Wolf fassen sie zusammen, wie unsere Kollegen bei it-agile auf New Work schauen.
Stefan Roock beschreibt mit Safe-to-Fail-Experimenten eine konstruktive Methode, die für Organisationsveränderungen nützlich ist.
Mit freundlicher Genehmigung des d.punkt-Verlags aus Heidelberg drucken wir ein Buchkapitel aus der 2. Auflage des Buches „Agile Projekte mit XP, Scrum und Kanban erfolgreich durchführen“ ab. Es stammt von Stefan Roock und Henning Wolf und beschreibt die Strukturen bei it-agile.
Einen Teil dieser Strukturen beschreiben auch die Kollegen Sven Günther (Gehaltschecker) und Holger Bohlmann (Demokratie).
Leseprobe Agile Review...
Agile Review abonnieren...
Agile Review zum Thema "New Work"
Rückblick auf den Scrum-Day 2015 und Product Owner Typen
Ich (Henning) war am 17. Juni 2015 auf dem Scrum-Day in Filderstadt und habe einige Eindrücke mitgenommen, von denen ich dir berichten möchte. Ich verscuhe mich mal auf das Wesentliche zu konzentrieren, auch wenn es schwerfällt.

An der Keynote von Jeff Sutherland, einem der Väter von Scrum, fand ich vor allem beeindruckend, wie sicher sich Jeff ist, dass für die meisten Unternehmen kein Weg an Scrum vorbeiführt. Seine Keynote beschäftigte sich mit dem Thema Scrum skalieren, aber seine Interpretation dazu war es eher, wie Scrum aus der Entwicklung raus ins ganze Unternehmen kommt, also Enterprise Scrum erreicht wird. Der Schlüssel dazu ist laut Jeff (und da kann ich ihm auch nur zustimmen), dass alle in der Organisation, auch die Manager, das Agile Mindset verstehen und danach handeln. Seine Metapher dafür schien mir für Entwickler besser geeignet als für Manager: Er spricht davon, dass man ein anderes Betriebssystem installieren müsste, dabei vieles ganz neu lernen muss und nicht nur dauernd von der alten in die neue Welt übersetzen darf.

In der zweiten Keynote des Tages nach dem Mittag hat Joe Justice, der Gründer von Wikispeed, einem Open-Source-Auto-Projekt, sehr überzeugend dargelegt, welche Änderungen in nächster Zeit auf Hardware-Hersteller und -Entwickler zukommen. Er selbst unterstützt verschiedene Firmen, darunter auch Traktorenhersteller, die auch in der Hardware-Entwicklung auf Scrum setzen und auf ähnlich kurze Entwicklungszyklen von wenigen Wochen kommen inkl. auslieferbarer Produktinkremente. Schließlich lassen sich heute dank schneller Logistik und 3D-Druckern unfassbar viele Hardware-Teile günstig und schnell produzieren. Mir schwant, da schlummert für Scrum noch ein riesiges Feld (wir selbst sind inzwischen auch bei Kunden in der Hardware-Entwicklung mit Scrum unterwegs). Interessant dabei, dass Joe neben Scrum für Hardware-Entwicklung auch Praktiken von eXtreme Programming (dann eXtreme Manufacturing genannt) sieht, sowie eine neue Form der Modularisierung, die wir in der Softwareentwicklung schon seit den 90ern praktizieren: Objekt-Orientierung.

Mein eigener Vortrag zu Product Owner Typen fand im großen Saal statt und war gut besucht. Der Großteil der Zuhörer arbeitet als Product Owner. Dabei wurde in der Diskussion klar, dass viele am klassischen Problem großer Unternehmen leiden: Sie sind nicht wirklich empowert und können keinesfalls alleine das Product Backlog priorisieren. Dabei scheint es gar nicht primär am Vertrauen zu liegen, eher am Mangel an Fokus.

Ich habe noch einige weitere Vorträge besucht, will jetzt aber selbst dem Wert Fokus folgen. ;-)
Vortragsfolien zu Product Owner Typen...
Zum Artikel aus der letzten Agile Review zu Product Owner Typen...
Henning Wolf beim Vortrag auf dem Scrum-Day 2015
Ordentlich was gelernt: Unsere neuen Standup-Rugby-Bälle
Schon seit einigen Jahren produzieren wir Standup- oder Daily-Scrum-Bälle, auf denen die 3 Fragen für das Standup stehen:

Was hast du seit dem letzten Mal gemacht?
Was machst du bis zum nächsten Mal?
Was behindert dich?

Vielleicht kennst du aus unseren Schulungen diese Bälle. Viele Teams benutzen die Bälle gerne als Rede-Token während der Standups (und als Erinnerungsstütze für die Teammitglieder, wozu sie im Standup etwas sagen sollen). Jetzt stand vor einiger Zeit eine neue Bestellung an. Erst haben wir darüber nachgedacht, ob wir auf die Fragen aus dem aktuellen Scrum-Guide umschwenken:

Was habe ich gestern gemacht, das dem Entwicklungsteam hilft, das Sprintziel zu erreichen?
Was werde ich heute tun, das dem Entwicklungsteam hilft, das Sprintziel zu erreichen?
Sehe ich irgendwelche Hindernisse, die das Entwicklungsteam davon abhalten könnten, das Sprintziel zu erreichen?

Weil es dafür einen ziemlich großen Ball bräuchte oder sehr kleine Schrift, haben wir das verworfen. Aber wir wollten schon länger passend zur Herkunft des Namens Scrum auf Rugby- statt Jonglierbälle umsteigen. Unser Werbeartikellieferant hat in China geforscht und auch einige Anbieter gefunden, wir haben Muster erhalten und schließlich anhand eines Musters einen Lieferanten ausgewählt.

Und dann kommt der Fail: Für einen relativ kleinen Aufpreis kann man zunächst ein Andruckmuster bestellen bevor man 3.000 Bälle herstellen lässt. Ich (Henning) hätte es im Sinne von inspect & adapt besser wissen können, aber ich hatte es so eilig, weil doch die Jonglierbälle schon alle waren! Die gelieferten Rugby-Bälle liegen gut in der Hand, sind aus einem Schaum, der sich wie bei einem Stressball zusammendrücken lässt. Der Druck ist nicht so sauber wie bei den Mustern. Aber das ist alles noch nicht so schlimm. Ärgerlich wird es erst als eine Kollegin den Ball in die Hand nimmt, ein wenig dran reibt und sich dabei die Bedruckung komplett löst! Was für ein Alptraum. Wir haben sofort weitere Bälle in die Hände genommen und getestet, aber es passiert nicht immer. Hm, unterschiedliche Qualität? Nein, denn unsere Tests zeigen: Die Farbe scheint kein Problem mit Wasser zu haben, sich aber in Öl aufzulösen, wie es z.B. in Handcreme vorkommt.

Während jetzt mit großer Sorgfalt (und sicherlich mit Andruckmuster) die Suche nach einem neuen Lieferanten für ein Nachfolgemodell begonnen hat, haben wir uns überlegt, wie wir mit dem Bedarf unserer Kunden umgehen:
Ab sofort liefern wir wieder Standup-Bälle über unseren Shop, und zwar die hier beschriebenen in Rugby-Ball-Form mit den beschriebenen Problemen. 3 Stück für 10 €. Sobald wir die neuen Bälle dann erhalten haben (evtl. erst Anfang Oktober) erhält jeder Besteller kostenlos 3 neue Bälle nachgeliefert. 

Zur Produktseite der Standup-Rugby-Bälle...
Zum it-agile-Shop...
Standup-Rugby-Bälle
10 Jahre it-agile: Unabhängigkeit von wenigen Großkunden
Als wir vor 10 Jahren it-agile gründeten, hatten wir einen großen Kunden, der den Großteil unseres Umsatzes ausmachte (nämlich 84%) und zwar für Entwicklungsprojekte. Uns war schnell klar, dass das dauerhaft kein günstiger Zustand ist. Wenn der Kunde seine Budgets kürzen oder andere Anbieter in Betracht ziehen würde, wären wir sofort in unserer Existenz bedroht.

Also arbeiteten wir in der Folge daran, die Abhängigkeit zu einem oder wenigen großen Kunden zu reduzieren.

Im Zuge dieser Anstrengungen haben wir eine ganze Reihe von Transformationen durchlaufen. Die erste war, dass wir uns nicht mehr an Ausschreibungen für Entwicklungsprojekte beteiligten. Unsere Überlegung damals war: Ausschreibungen kommen von großen Kunden, die große Projekte machen und das würde bei unserer überschaubaren Größe von damals elf Kollegen schnell wieder in ein Abhängigkeitsverhältnis führen. Außerdem hatten wir festgestellt, dass damals (also im Jahr 2005) bei Großunternehmen noch wenig Verständnis für Agilität vorhanden war - schon gar nicht im Einkauf. Es fiel uns also auch sehr schwer, mit unserem "spinnerten" Scrum und XP dort zu landen. Also fokussierten wir uns eher auf mittlere Unternehmen, deren Software direkt Marktrelevanz hatte - z.B. eBusiness. Diese waren viel offener für Agilität und beauftragten auch nicht mit Ausschreibungen, bei denen am Ende vor allem über den Preis entschieden wurde.

Unsere Strategie ging auf. Im Jahre 2014 hat unser größter Kunde 14% an unserem Umsatz gehabt. Wenn der plötzlich weggefallen wäre, wäre das schmerzhaft, aber nicht existenzbedrohend gewesen.

Fragen zum Beitrag?
10 Jahre it-agile: 2005-2015 - Das Notizbuch
Coachingtipp: Von der Sitzung zur Stehung zur Gehung
Dieser Coaching-Tipp kommt von meiner Kollegin Anna Lorenz aus unserem Münchener Team. Wenn wir zusammenkommen, um etwas zu besprechen, tun wir das meist in Form einer Sitzung. Die Erfahrung der meisten ist, dass dieses Format häufig nicht produktiv ist. Oft fehlt diesen Meetings der Fokus und die Moderation. Durch die Vorbereitung aller Teilnehmer und das Einsetzen eines Moderators kann man es verbessern.
Eine andere Möglichkeit etwas zu verändern besteht darin, die Besprechung im Stehen durchzuführen (in Ahnlehnung an das Daily Scrum im Stehen). Stehen ist unbequemer als Sitzen, deshalb werden Mammut-Sitzungen von mehreren Stunden unwahrscheinlicher. Außerdem bringt Aufstehen sofort mehr Sauerstoff ins Gehirn. Dadurch sind die Teilnehmer konzentrierter und aufnahmefähiger.

Im wahrsten Sinne des Wortes kann man noch einen Schritt weitergehen und aus der Stehung eine Gehung machen. Dann besprechen wir uns während wir einen Spaziergang machen, so wie Steve Jobs es sehr häufig praktiziert hat. Gehen bringt noch mehr Sauerstoff ins Gehirn. Außerdem nehmen wir eine sich ständig verändernde Umgebung wahr, was die Kreativität fördert. Schon Friedrich Nietzsche sagte: „Trau keinem Gedanken, der dir im Sitzen kommt.“

Und nicht zuletzt adressiert die Gehung ein Problem, das wir in allen Unternehmen sehen: zu wenig Meeting-Räume.


Von Nilofer Merchant gibt es einen kurzen TED-Talk zu dem Thema: Got a meeting? Take a walk

Welchen Coachingtipp hast du in einem unserer Trainings oder von einem unserer Coaches erhalten, der sich für dich als besonders nützlich erwiesen hat? Das würde mich interessieren, schreibe mir.

Agiler werden mit it-agile...
it-agile Coachingtipp: Timeboxing in Besprechungen
Aktuelle Schulungstermine
Hier als Service für dich unsere nächsten Schulungs- und Workshoptermine:
Certified ScrumMaster (CSM) 8.-9. Juli in Hamburg mit Markus Gärtner
Lean User Research für PMs und POs 16. Juli in Hamburg mit Markus Andrezak
Management Agiler Teams 21.-23. Juli in München mit Ilja Preuß und Christian Dähn
Certified ScrumMaster (CSM) 12.-13. August in Hamburg mit Markus Gärtner
Kanban in Action 18.-19. August in München mit Wolfgang Wiedenroth
Skalierung mit Scrum 18.-20. August in Hamburg mit Markus Gärtner
Certified Scrum Product Owner Deluxe (CSPO) 24.-26. August in Düsseldorf mit Markus Gärtner
Certified Scrum Developer (CSD) 25.-27. August in Hamburg mit Sven Günther
Kanban in Action 1.-2. September in Hamburg mit Wolfgang Wiedenroth
Meeting-Moderation 2.-3. September in Hamburg mit Claudia Reitenbach und Peter Rößler
Certified ScrumMaster (CSM) 8.-9. September in München mit Stefan Roock
Kanban Bascis 9. September in Hamburg mit Wolfgang Wiedenroth
Certified Scrum Product Owner (CSPO) 16.-17. September in München mit Roman Pichler
Scrum Basics 21. September in München mit Sebastian Keller
Certified ScrumMaster Deluxe (CSM) 22.-24. September in Hamburg mit Markus Gärtner
Retrospektiven-Training 29. September in Hamburg mit Markus Gärtner

Schulungsübersicht it-agile...
it-agile Schulungen
Treffen wir uns?
Am 20. August sehen wir bei 24translate den Augenhöhe-Film mit anschließendem Austausch zu dem Thema. Weitere Infos und Anmeldung...
Markus Gärtner berichtet am 24. September über "Large-Scale Scrum (LeSS) - Scrum im Großen und Ganzen" im Rahmen unserer Veranstaltungsreihe "Der Norden Agil" (in unserem Büro in Hamburg). Weitere Infos und Anmeldung...
it-agile Schulungen
Schiff des Monats: Unicorn Ocean
Die Unicorn Ocean ist ein Frachtschiff mit 225 Meter Länge und 32 Metern Breite. Das Schiff an sich ist nicht besonders spektakulär, aber der Name (Unicorn = Einhorn) erinnerte mich an ein scheinbares Paradox agiler Denkweisen.

Die Agilen werden häufig als "Treehugger" gesehen, die mit rosa Einhörnern im Wald tanzen und die harte Realität nicht wahrhaben wollen. Dass es tatsächlich eher anders herum ist, fällt mir immer wieder auf, wenn wir bestimmte, immer wiederkehrende Diskussionen in Schulungen führen.

Irgendwann fragt vielleicht ein Teilnehmer einer Product Owner-Schulung, was er denn machen soll, wenn das Team zu langsam ist. Meine Antwort: "Wenn die Geschwindigkeit des Teams es nicht erlaubt, ein erfolgreiches Produkt herzustellen und du nicht siehst, dass das Team schneller wird, dann musst du als Product Owner das Projekt abbrechen." Die Reaktion ist meist Entsetzen: "Das kann man doch nicht tun. Das ist doch viel zu hart."

Oder es fragt ein Teilnehmer einer Scrum Master-Schulung, wie mit Teammitgliedern umzugehen ist, die sich nicht ins Team integrieren. Mein Beitrag zur Diskussion: "Wir geben niemanden leichtfertig auf. Aber wenn wir alles versucht haben, müssen wir überlegen, die Person aus dem Team zu entfernen." Wieder Entsetzen: "Das kann man doch nicht tun. Der arme Mensch." 

Wenn ich die Reaktionen sehe und höre dann muss ich mich immer sehr zurückhalten, um nicht zu fragen, wer hier mit den rosa Einhörnern im Wald tanzt und wer sich ernsthaft mit der Realität beschäftigt. Was häufig verwechselt wird, ist Klarheit bzw. Härte in der Sache und Respekt gegenüber den Menschen.

Wenn man entscheidet, ein Projekt abzubrechen, bedeutet es eben nicht, dass die Menschen im Team unfähig wären. Vielleicht lässt sich das Produkt gar nicht wirtschaftlich entwickeln. Vielleicht passt die Teamzusammensetzung nicht. Vielleicht behindern die Organisationsstrukturen, dass sich das Team entfalten kann. Und so ähnlich verhält es sich mit einem Teammitglied, das aus dem Team entfernt wird. Erstmal bedeutet es nur, dass das Teammitglied sich in dem Team nicht einbringen kann. Auch das kann auf eine ungünstige Teamzusammensetzung zurückzuführen sein. In einem anderen Team sieht die Welt vielleicht schon ganz anders aus. Und natürlich kann sich auch herausstellen, dass ein Mitarbeiter im Unternehmen nicht gut aufgehoben ist und dann muss man sich trennen. Aber auch das geht mit Respekt.

Wie siehst du das Ganze? Wie gehst du mit solchen schwierigen Situationen um? Schreibe uns gern dazu. Danke im Voraus.


Wenn du eine größere Aufnahme des Schiffs des Monats sehen willst, klicke einfach auf das nebenstehende Bild.

Schiff des Monats: Unicorn Ocean