AgileEE2011: Videos der Keynotes online

Die wichtigsten Vorträge der Agile Eastern Europe 2011 werden jetzt nach und nach ins Netz gestellt. Die Videos sind alle sehr gelungen und die Präsentationen sind ebenfalls abrufbar.

Neben den Keynotes von Alistair Cockburn (Effective Software Development In The 21st Century: The New Face Of Software Engineering), J. B. Rainsberger (The Extreme Decade: Progress, Pain, Paradox”) und Jurgen Appelo (“How to Change the World”) jetzt auch die Keynote von

Elisabeth Hendrickson (Blog).

Ihre Session mit dem Titel "Agile Testing, Uncertainty, Risk, and Why It All Works" ist deshalb so interessant, da sehr eindrücklich der Wert von kurzer Zyklen und echten Auslieferungen erläutert wird.

Die Argumentation ist in etwa wie folgt:

  • No roll out to real customers –> Speculation build up –> big tank of toxic stuff
  • Speculation we are basing our decisions on
  • Fact is: Empirical Evidence trumps Speculation. Every. Single. Time.

 

Keynote by Elisabeth Hendrickson from AGILEEE on Vimeo.

Es gibt noch viele weitere Anregungen in dem Talk, weshalb ich empfehle das Video und die Präsentation in Ruhe anzusehen.

Agile Breakfast Konstanz – Definition of Ready

Vor einigen Tagen hatte ich die Gelegenheit auf dem 4. Agile Breakfast in Konstanz einen Vortrag zum Thema “Definition of Ready” zu halten. Das Agile Breakfast wird von der Scrum Usergroup Lake Constance (SUGLC) organisiert, findet in Konstanz im Wasserturm (wunderschöne Aussicht auf den Bodensee!) und wurde auch dieses Mal von der Firma Sybit gesponsert.

Verbreitung der Definition of Ready

Viele Scrum Team kennen die “Definition of Done”, in der definiert wird, in welchem Zustand ein Inkrement den Sprint verlässt. Laut Jeff Sutherland wenden diese jedoch nur ca. 50% aller Teams konsequent an. Die” Definition of Ready” (Definition, in welchem Zustand eine Story den Sprint betritt) ist jedoch deutlich weniger Team bekannt. Nur ca. 1% aller Scrum Teams weltweit wenden eine Defnition von “Fertig für den Sprint” konsequent an.

clip_image001

Die inkonsequente Anwendung ist erstaunlich, da die Definition of Done als auch die Definition of Ready das Potential haben die Produktivität von Teams zu verdoppelt. Jeff Sutherland fasst dies unter dem Begriff “Hyperproductive Scrum Teams” zusammen. Zusammen mit einer echten Selbstorganisation, bietet die konsequente Anwendung von DONE und READY das Potential die Produktivität um den Faktor 4-8 zu erhöhen!

Continue reading

Scrum für Schlipsträger – Nachhilfe in Sachen Change Management

Anforderungen sind jetzt Geschichte(n), was früher Rolling Wave Planning hieß wird heute als “agil” gelobt, aber generell sind Pläne pfui, das sind jetzt Backlogs und sie sind eher unverbindlich. Time Boxing, Demingzyklus und Leistungswertanalyse werden unter anderem Namen der jubelnden Entwicklerschar als brandneu und viel geeigneter als alles zuvor verkauft. Außerdem steht jetzt der Mensch im Vordergrund, alles ist Produktentwicklung und Personentage gibt es nicht mehr in der schönen Welt des Scrums.

Wenn es wie eine Ente watschelt, wie eine Ente quakt und wie eine Ente aussieht, kannst du es eine Giraffe nennen, aber es ist dennoch eine Ente.

image

Wir wissen ja: Chaos im Unternehmen ist bekanntlich Folge des bösen und generell untauglichen Wasserfallmodells. Fortschritt durch das neue Vorgehen ist hingegen wissenschaftlich belegt gemäß des Axioms “Tausend Gurus können nicht irren” sowie Beweis durch vollständige Anekdote.

Eine dieser Anekdoten geht wie folgt: Man nehme ein vorzugsweise leicht ausgebranntes Entwicklerteam, schule es ein paar Tage in angenehmer Umgebung durch einen hochmotivierten Scrumverkäufer, zelebriere einen unbelasteten Neubeginn, lasse das Team in Ruhe werkeln und messe sodann die Arbeitseffizienz. Überraschung – die Effizienz steigt! Wer hätte das gedacht? Und wer glaubt, dass ein solcher Versuch etwas nachweisen kann?

Continue reading

Die dunkle Seite von Scrum

Ich glaube, dass Scrum als moderner iterativ-inkrementeller Softwareentwicklungsansatz der auf Werten beruht ein großes Potential für langfristige Produktivitätssteigerungen besitzt.

Aber “reines” Scrum funktioniert nicht überall. Und “reines” Scrum hat – wie andere “reine Lehren” auch – viele “dunkle” Seiten.

Selbst Evangelisten wie Ken Schwaber gehen auf Probleme bei Einführung von Scrum in Unternehmen ein. Einige der Punkte aus “The Enterprise and Scrum” von Ken möchte ich aus einer eher skeptischen Perspektive kommentieren.

Aus Part I, “Adopting Scrum”:

Staff turnover will occur

Ja, manche Personen möchten nicht mehr Verantwortung und mehr Freiheit. Manche Angestellten arbeiten, um Geld zu verdienen – nicht weil es sich um ihre Berufung handelt. Zugrunde liegt ein Vertragsverhältnis und ein Vertrauensverhältnis. Die Organisation möchte dies nun einseitig ändern. Widerstand wird die Folge sein, Kosten entstehen, Veränderung verlangsamt sich.

Conflict will occurimage

Veränderungen führen zu Konflikten. Sind alle darauf vorbereitet mit Konflikten richtig umzugehen? Hat die Organisation Antworten auf die Fragen die in den Gesprächen gestellt werden? Hat die Organisation die Kraft die Konflikte zu lösen? Meine Erfahrungen hier sind ernüchternd. Mir ist keine ältere Organisation bekannt, die gut mit Konflikten umgehen kann. Unternehmenspolitik spielt hierbei eine wichtige Rolle. Möchte man dies überwinden, so kostet dies Geld und Zeit. Oft müssen auch Personen im mittleren und höheren  Management ausgetauscht werden.

Product management’s job will change and will be harder

Klar, Scrum verschiebt die wirklich komplexen Entscheidungen dorthin, wo sie hingehören: Zum Management. Die wichtigsten Fragen sind: WAS will ich tun – und vor allem was will ich NICHT tun?

Dafür, dass diese Fragestellungen von zentraler Bedeutung sind, wird die Rolle des PO meiner Meinung nach zu wenig beachtet. Der gestiegenen Verantwortung steht im Allgemeinen leider keine gestiegene Entlohnung gegenüber. Im Grunde ein Verlustgeschäft für die betroffenen Manager – zumindest wenn man nur die finanziellen Aspekte betrachtet und eine mögliche gestiegene Motivation durch schnellere Ergebnisse vernachlässigt.

Meiner Erfahrung nach ist es aber auch häufig so, dass aus verwaltenden Produktmanager einfach verwaltende ProductOwner gemacht werden. Zu häufig ist der PO eben nicht er “Gold Owner” und damit geht viel Einflussmöglichkeit dieser Rolle verloren.

Engineering is accountable for quality

Eine Frage, die ich mir immer wieder stelle: Woher wissen die Techniker, was Qualität ist? Qualität muss im Kontext betrachtet werden. Eine Entwicklung für eine Messepräsentation muss nicht unbedingt wartbar oder performant sein. Für eine Software, die der Grundstein für ein Produkt ist, ist dies jedoch sehr wichtig. Zu oft erlebe ich in der Praxis, dass hier immer mit einem Maß gemessen wird. Technik ist nicht Business, Business soll aber die Richtung (“was”) vorgeben. Wenn Technik dann nur eine Art von Qualität liefern kann, dann ist dies zu teuer und es wird kein Geschäftswert generiert.

Compensation policies need to change

Damit wird Scrum zur Restrukturierungsmaßnahme im großen Stil. Viel Spaß mit dem Widerstand, auf den man treffen wird. Betriebsrat? Gewerkschaft? Sind die Manager wirklich so gut, diese Veränderungen an die Belegschaft zu verkaufen?

Jobs will change

Für Deutschland eine spannende Sache. Veränderung der Stellenbeschreibung bei Festangestellten. Vielleicht wollen diese ihre alte Position behalten und klagen dagegen? Nicht jeder ist mit den Veränderungen einverstanden. Mit Widerstand ist zu rechnen – wiederum muss mit Kosten und Verzögerungen gerechnet werden.

Management’s primary responsibility will shift from command to servant leadership

Das Management wird reduziert auf die Beseitigung von Hindernissen. Hier wird stets davon ausgegangen, dass Selbstorganisation funktioniert. Ich bezweifle dies. Leider sprechen meine Erfahrungen dagegen. Die meisten Teams, die ich kenne, denken zu technisch und zu sicherheitsorientiert. Zu langsam und damit unbezahlbar. Der Grund? Meist Überforderung in Form von Multi-Projekt-Abarbeitung und dauernde Veränderung des Fokus. Ja, ein Management-Problem. Ihr könnt aber sicher sein, dass das Management dies gerne lösen würde – aber nicht kann. Superheld Produktmanager (PO) scheitert an der Realität. Wer hätte das erwartet?

Trotz Selbstorganisation wird im Allgemeinen auch nur der Manager an die Wand gestellt. Single wrinkable neck eben.

Management turnover will occur

Für viele Manager ist der Deal mies: Mehr Verantwortung, mehr Stress und Druck. Weniger Einflussmöglichkeiten. Immer noch im Schussfeld, wenn es Probleme gibt – während die Entwicklung ziemlich geschützt ist. Naja, da kann man verstehen, dass der eine oder andere Manager eine Position vorzieht, in denen er mehr bewegen kann.

Fazit

Aus meiner Sicht sieht das Fazit so aus:

Mit Scrum werden die Defizite einer Organisation deutlich. Jede Organisation hat Defizite und Probleme. Was tun? Ken warnt davor, Scrum anzupassen – da dann die Probleme nicht beseitigt werden. Verständlich – aber auch realistisch? Vielleicht. Wenn man in der Lage ist die Kosten einer Einführung von Scrum (as from the book) zu bezahlen. Falls dies nicht der Fall ist, muss mit Kompromissen gearbeitet werden.

Sorry, wollte euch nicht den Tag vermiesen ;-)

Prophet im eigenen Lande …

Es gibt doch das Sprichwort, dass der Prophet im eigen Land nicht viel gilt. Irgendwie fühle ich mich so, nachdem ich die Excel-Tabelle von Jeff Sutherland gesehen habe.

Ein ähnliches Planungswerkzeug habe ich zusammen mit ein paar anderen POs vor fast zwei  Jahren bei unseren Teams eingeführt und im Allgemeinen sehr gute Erfahrungen damit gemacht. Unser Werkzeug war nicht ganz so detailliert, hat aber stets seine Aufgaben erfüllt.

Leider konnte es sich auf Grund erheblichen Widerstands von “Traditionalisten” (und einiger externer Berater) nicht durchsetzen. Naja, vielleicht lernen sie nun von Jeff, dass Excel nicht böse sein muss, und dass eine genauere Betrachtungsweise der Teamzusammensetzung in der Vergangenheit ein relevanter Parameter für die zukünftige Velocity sein kann.

Sweden-Nordic-Museum-King

Urlaub? Warum soll ich Urlaub berücksichtigen – wir mitteln einfach über das ganze Jahr!

Wunderbar, wenn es fixe externe Termine gibt und man frühzeitig wissen muss, ob diese eingehalten werden können.

Alle weiteren Kommentare verkneife ich mir jetzt.

Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner

Das letzte Treffen der Scrum User Group Karlsruhe in 2009 beschäftigte sich mit der Rolle des Scrum Product Owners. Genauer: “Herausforderungen für unseren Product Owner”.

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

meckpomm1

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

  • Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
  • Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
  • POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
  • POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

  • Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
  • Product Owner sollte ein gutes technisches Verständnis haben
  • Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
  • Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
  • … sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu  der verbreitesten Form der Scrum Implementierung zählen ;-(

Scrum Product Owner – eine sehr anspruchsvolle Aufgabe

Heiko arbeitet seit einiger Zeit als Product Owner und erlebt damit die Herausforderungen dieser Rolle gerade selbst. Seine Erkenntnis: Die Rolle des Product Owners wird zur Zeit unterschätzt. Dem kann ich nur zustimmen und ich habe ja auch bereits darüber geschrieben.

Für mich dient die Rolle des POs in Scrum leider zu oft als schwammige Wolke hinter der sich die böse komplexe Welt verstecken lässt. Letztendlich werden dem PO – und nicht dem Team oder dem Scrum Master – die wirklich schwierigen Entscheidungen auferlegt. Der Product Owner muss entscheiden, welche Dinge getan werden sollen – und welche eben nicht (was meist eine noch schwerere Entscheidung ist).

Die Anforderungen an den Product Owner sind sehr hoch: Wissen in den Bereichen Projektmanagement, Produktmanagement, Vertrieb, Marketing, Prozesse, Emtwicklungsmethodik (um die richtigen Fragen zu stellen) und Business Development. Kommunikation ist wichtig und die Fähigkeit ein Ziel formulieren und verfolgen zu können.

Stellt doch mal beim nächsten Treffen eurer lokalen Scrum-Gruppe – oder bei einem größeren Scrum-Event – die Frage, wer von den Anwesenden die folgenden Voraussetzungen erfüllt:

  • Aktive Ausübung der Rolle Product Owner
  • Kenntnisse in den Bereichen Business Development, Vertrieb, Marketing, Produktmanagement, Projektmanagement (alternativ: Zuverlässiges Bauchgefühl)
  • Kommunikationsgenie & Motivationsgott
  • Ahnung von Entwicklungsprozessen und ein IT-Hintergrund (vgl. “Chief-Engineer” von Toyota)
  • Echter Gold-Owner (ohne wegen 10 TEUR zum Vorgesetzten laufen zu müssen)
  • Angestellter
  • Keine Überlastungserscheinungen ;-)

Ich vermute, dass keiner der Anwesenden diese Anforderungen erfüllen kann – aber probiert es doch einfach selbst aus ;-)

SLM: MikeCohn über Bandbreite und Skalierbarkeit agiler Methoden

Ein Video mit Mike Cohn (Mountain Goat Software) in dem er u.a. über die Skalierbarkeit von agilen Methoden spricht.

Mike sieht es kritisch, dass in einigen Veröffentlichungen der Eindruck erweckt wird, als ob agile Methoden nur für ein einzelnes kleines Team auf einer einsamen Insel funktionieren würden. Die Beschränkung auf die Beschreibung der Kernkonzepte sei zwar ein guter Ansatz, um die Grundlagen/Konzept zu erklären. Die Wirklichkeit sehe jedoch anderst aus und dies dürfe in Artikeln und Büchern über die agilen Methoden nicht mehr vernachlässigt werden.

Zudem vertritt er die Meinung, dass Agile sehr gut skaliert und deshalb sollte auch mehr darüber veröffentlicht werden.

Beispiel für Skalierbarkeit
Er spricht über ein Projekt mit 700 Personen und wie dieses mit agilen Methoden durchgeführt werden kann.

Zunächst ist es wichtig das übergeordnete Ziel (Vision) durch einen “Chief-Product-Owner” definieren zu lassen. Diese wird dann über eine Hierarchie von Product Ownern in die Teams getragen. Wichtig: Die POs managen das Projekt nicht sondern sind dafür zuständig die Ziele zu formulieren.

Die Teams sind ebenfalls hierarchisch strukturiert, die Koordination der Teams erfolgt durch diese selbst: “… but teams coordinate their work in ways their determine …”.

Mike fasst nochmals zusammen, was nötig ist, damit Teams funktionieren können:

  • Geld / Money (Salary, Infrastructure)
  • Unterstüzung / Moral Support (Feedback, removing impediments)
  • Ziel / Guidance (Vision)

Schätzungen
Im zeiten Teil spricht er Über Abschätzungen und weist darauf hin, dass es für Teams wichtig ist zunächst in relativen Größen zu schätzen. Erst in einem weiteren Schritt können diese Schätzungen dann auf Dauer und Aufwand umgelegt werden.

Seht euch das Video einfach selbst an …

Investitionen in einen Product Owner

Joe Little schreibt in “Should we invest in a better Product Owner?” …

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year…

Was ich dazu meine? Der Product Owner kann ganz schön viel Mist bauen und mit den falschen Entscheidungen das Team perfektes “Muda” (Abfall/Quatsch) erzeugen lassen. Geld zum Fenster raus eben. Aber natürlich befindet sich der Product Owner hier in bester Gesellschaft mit anderen Managern.

Jetzt glaubt Joe allerdings, mit einem Kurs zum Certified Product Owner wäre das Problem gelöst:

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course).

Ok,ok – der Realitätsverlust ist doch nicht so groß:

… I suspect that most Product Owners need more than just the course to get those results …

Den nächsten Ansatz finde ich allerdings sehr gut: Coaching!

… perhaps some coaching from someone really good

Leider gibt es dies zu selten. Ich meine das Coaching, “someone really good” und natürlich jemanden der wirklich gut ist und Zeit für Coaching hat ;-)

Jup, und er hat Recht – wenn der PO in einem Cost Center angesiedelt ist, dann ist auch das problematisch. Man denkt nicht wirklich in Business Value sonder erfüllt andere Zielvorgaben.

  And thus they have no concept of BV delivered by IT, much less metrics around that.

Was ich auch immer wieder erlebe:

  • Product Owner aus dem Marketing / Vertrieb ohne Einsicht, dass beispielsweise auch die technischen Aspekte berücksichtigt werden müssen (technical debt) um auch langfristig gute Ergebnisse zu erzielen
  • Product Owner die aus der IT Abteilung kommen ohne echtes Verständnis für Business Value und den treibenden Kräften in einem Markt.
  • Product Owner die entweder die Ideen hinter Scrum nicht verstehen (wollen) oder ganz und gar an den Lippen freiberuflicher Berater hängen.

Was hilft? Ausbildung in den Bereichen Marketing, Vertrieb, IT/Informatik und allgemeine Betriebswirtschaft. Danach kontinuierliches Coaching und Weiterbildung. Dafür muss der PO von der Persönlichkeitsstruktur her geeignet sein. Die Anforderungen hat IMHO Christian Schmidkonz in seinen Präsentationen (Beispiel) zur Scrum-Einführung bei der SAP gut zusammengefasst. Personen mit solchen Skillsets gibt es nur selten – und diese sind meist freiberuflich tätig.

Zusammenfassung

Ein guter Product Owner ist ein kritischer Erfolgsfaktor, schon alleine weil ein schlechter PO alle Stärken eines Spitzenteams und eines hervorragenden Scrum Masters zunichte machen kann.