Auf unserer Agile.Coach Seite habe ich einen für mich wichtigen Beitrag geschrieben, auf den ich hier verweisen will. Es geht um die Definition, was ist ein agiler Coach für mich. Diese Definition kann sich im Laufe der Zeit noch schärfen und entwickeln, aber mit der jetzigen bin ich schon sehr zufrieden und bin gespannt auf Feedback. Hier geht es weiter zum Beitrag: Agile Coach – Was heißt das?...

Vor einigen Wochen habe ich ein Co-Training mit Markus Gärtner von IT-Agile in Hamburg gegeben. Das war eine spannende Veranstaltung, nicht nur wegen der Aussicht auf die Elbe und die vorbeifahrenden größten Schiffe der Welt. Einerseits konnte ich einige Konzepte mit in das Training reinzubringen, wie zum Beispiel Liberating Structures. Je länger ich mich mit dieser Sammlung von Mikrostrukturen beschäftige, desto mehr komme ich zur Überzeugung, dass diese mit zu den wichtigsten Werkzeugen gehört, über die ein Scrummaster oder Coach verfügen sollte. Ich konnte auch ein Paar bekannte Formate, wie das Name Game und Scrum from Hello in einer neuen Ausführung erleben. Mehr Details dazu in meinem Post auf dem Agile Coach Blog. Danke Markus für das wertvolle Feedback und die Gelegenheit von ihm lernen zu...

Ich habe vor kurzem ein Co-Training für einen CSPO Kurs mit Markus Gärtner in Düsseldorf gegeben. Das war eine spannende Erfahrung mit zwei Highlights. Mehr dazu auf meinem Agile Coach Blog. Company Training aussuchen * CSM Deluxe, 11-13. Juni in Berlin CSM, 25-26. Juni in Berlin Anzahl der Personen EineZweiDrei Person One Name * Person One Email...

Hier kommt eine Ansage in eigener Sache. Ich freue mich sehr, dass ich ab jetzt zusammen mit einem guten Freund und nun auch Kollegen – Timon Fiddike – unter einer gemeinsamen Fahne segeln werde. Neuigkeiten von mir werden ab jetzt auf der Webseite Agile.Coach erscheinen. Diese Entwicklung freut mich in vielerlei Hinsicht. Hier die beiden offensichtlichsten und wichtigsten Punkte. Ich bin ein großer Verfechter von Pairing. Nicht nur im Programmieren sondern auch in anderen Arten von Tätigkeiten. Das ist sicherlich ein Thema für einen eigenen Post. Hier sei erwähnt, dass Timon und ich sehr produktiv pairen können. Timon und ich haben viele komplementäre Fähigkeiten und Erfahrungen. Auch wenn wir heute beide im Bereich agiles Coaching arbeiten, so kommen wir doch aus ganz unterschiedlichen Richtungen. Timon ist ein promovierter Informatiker und erfahrener Entwickler und Trainer für Symfony, während ich aus dem Bereich Unternehmensführung und Entrepreneurship komme. Ich bin sehr gespannt wie es weiter...

Vor zwei Wochen hatte ich das Vergnügen beim Berliner Scrum Meetup das Scrum-Framework für mehrere Entwicklungsteams vorzustellen – LeSS. Die Herausforderung war groß, es galt das 3-tägige Training aus dem Frühling auf einen 15 minütigen Vortrag zu kürzen. Behalten Sie das bitte im Kopf wenn Sie meine Slides am Ende dieses Posts ansehen. Was sind die wichtigsten Punkte die für mich LeSS ausmachen? Es gibt ja eine ganze Reihe von Scaled Agile Frameworks z.B. SAFE oder DAD. LeSS verursacht, wie die Abkürzung schon sagt, nur minimale Änderungen am Scrum-Framework, um die Herausforderungen von Multi-teams zu beantworten. Es setzt grundsätzlich die Regeln von Scrum voraus. Mit dieser Anforderung so minimal wie möglich zu sein, erleichtert dem ganzen ein Framework und nicht Methode zu bleiben. Mit anderen Worten, die Prozesse der konkreten Firma können sich in das Framework eingliedern, es lässt dafür genug Raum. Was sind diese grundsätzlichen Änderungen: 1. Rolle des PO: Er kann wirklich nur noch priorisieren. Stories fertig schreiben, Kundenanforderungen vor und während des Sprints klären, all das dürfen im LeSS die Stakeholder zusammen mit dem Team. 2. Meetings verändern sich: a. Planning One wird nur noch von 1 bis 2 Vertretern der Teams besucht b. Es wird ein Overall Refinement eingeführt, bei dem auch nur von 1 bis 2 Vertreter der Team dabei sind und der Fokus ist vor allem auf der Klärung: welches Team welche Story im detaillierterem Team Refinement auseinander schneiden und klären wird. c. Es wird eine Overall-Retrospective eingeführt. In welcher PO, Scrummaster und Vertreter der Teams und ggf. Manager zusammen kommen um über Impediments zu sprechen die außerhalb des Rahmens einzelner Teams liegen. 3. Es gibt in LeSS einen sehr ehrlichen Umgang mit der Definition of Done und der Diskrepanz zum „potentially shippable product“. Diese wird mit Hilfe der Feature Team Adoption Map verständlich gemacht. 4. Auf all die Fragen, auf die andere Frameworks detaillierte Antworten geben, geben die LeSS Gründern vor allem eine Sammlung von Prinzipien, Richtlinien und Experimenten, welche in den beiden LeSS Büchern von Bas Vodde und Crag Larman beschrieben sind. Ende des Jahres soll ein weiteres neues LeSS Buch erscheinen. LeSS ist aus meiner Sicht zwar ein recht frisches Framework, aber eines mit den größten Erfolgschancen. Einerseits wurde es von zwei sehr anerkannten und erfahrenen CST gegründet und steht auf sehr soliden Füssen mit der Erfahrung die dahinter steht. Außerdem wurden LeSS Trainings bereits von der Scrum Alliance als akzeptierte Addon-Qualifizierungen für Scaled Scrum anerkannt. Mir gefällt dieses Framework mehr als alles andere was ich bisher gesehen habe, vor allem wegen seiner Ehrlichkeit und der Möglichkeit für die Teams echte Ownership für das Produkt zu übernehmen. LeSS-Intro – Scrum Meetup Berlin from Anton...

Vor kurzem habe ich einen neuen Blogeintrag von Marty Cagan gelesen, dem Experten für Produktmanagement. Seine Beobachtung entsprechen so sehr meinen, dass ich mich entschieden habe seinen Post zu übersetzen. Mit seiner freundlichen Erlaubnis, die deutsche Übersetzung des Posts (http://www.svpg.com/product-fail): ­­ Produkt Fail Ich sehe die gleiche fundamentale Arbeitsweise bei der Mehrheit der Unternehmen. Und für mich ist es offensichtlich, dass diese Arbeitsweise nicht im Geringsten der Arbeitsweise von wirklich erfolgreichen Unternehmen entspricht. Ich muss Sie warnen, diese Diskussion kann ein wenig deprimierend sein, vor allem, wenn viele Punkte stark auf ihr Unternehmen zutreffen. Falls das der Fall ist, möchte ich Sie bitten trotzdem weiterzulesen. Wir beginnen mit einem Spaziergang durch die Grundlagen dieses Prozesses, der noch heute von einer großen Mehrheit der Unternehmen zur Produktentwicklung angewendet wird. Ich werde versuchen sachlich zu bleiben und zunächst kurz nur den Prozess beschreiben: Alles beginnt mit Ideen. In den meisten Unternehmen kommen diese von Führungskräften oder von wichtigen Stakeholdern oder Anteilseignern oder von (potentiellen) Großkunden. Auf jedem Fall gibt es immer eine ganze Reihe von solchen Ideen, die wir, die Produktorganisation, in verschiedenen Bereichen tun müssen. Die meisten Unternehmen wollen diese Ideen in einer Roadmap priorisieren und dies tun sie aus zwei Gründen. Erstens, sie wollen das zuerst an den wertvollsten Dingen gearbeitet wird. Und zweitens, wollen sie in der Lage sein, vorherzusagen wann bestimmte Dinge fertig sein werden. Um dies zu tun, gibt es fast immer eine Quartals- oder Jahresplanungssitzung, wo die Unternehmensführung die Ideen beurteilt und die Prioritäten in der Produkt-Roadmap verhandelt. Aber um zu priorisieren, braucht die Führung zuerst einen Business-Case für jede Idee. Einige Unternehmen haben formelle Business-Cases und andere informelle, aber so oder so geht es um die Notwendigkeit, zwei Dinge über jede Idee herauszufinden: 1) wie viel Geld wird sie einbringen? und 2) wie viel Geld oder Zeit wird sie kosten? Diese Informationen werden dann verwendet, um die Roadmap zu erstellen, in der Regel für das nächste Quartal, aber manchmal auch für ein ganzes Jahr. An diesem Punkt erhält die Produkt- und Technologie-Organisation ihren Marschbefehl. Und in der Regel werden die Elemente mit der höchsten Priorität der Reihe nach abgearbeitet. Sobald eine Idee es an die Spitze der Liste schafft, ist der erste Schritt des Produkt-Managers, die beteiligten Stakeholder zu kontaktieren, die Idee auszuarbeiten und eine Liste von Nutzer-Anforderungen zu erstellen. Diese können als gewünschte Benutzererfahrungen oder eine Art funktionale Spezifikation oder in anderen Formate formalisiert werden. Ihr Zweck ist es, den Designern und Entwicklern mitzuteilen, was hergestellt werden soll. Sobald die Anforderungen gesammelt sind, wird das UX-Team (angenommen, das Unternehmen hat ein solches Team) aufgefordert, das Interaktionsdesign, das visuelle Design und bei physischen Produkten, das Industrie-Design, herzustellen. Im Anschluss werden diese Anforderungen und Design-Spezifikationen...