Henning Wolf

Ich bin agiler Berater und Geschäftsführer der it-agile GmbH. In diesen Blog schreibe ich unregelmäßig meine Gedanken zu Themen wie Agile Methoden, Softwareentwicklung, Lean, Business, Internet und anderem.

28.3.13

Was überzeugt Manager an "agil"? Teil 2: Hindernisse

Wenn ich jemanden überzeugen möchte, dann klingt es vielleicht merkwürdig, dass ich auch etwas von den zu erwartenden Hindernissen berichte. Ich bin aber davon überzeugt, dass man den "Preis" für Veränderungen nennen sollte. Denn allzu oft wird nur die neue bunte heile Zukunft gemalt und auf dem Weg bei den ersten Hürden aufgegeben. Um dies zu verhindern, sollte man zumindest generell davon berichten, dass es zu Hindernissen kommen wird.
Bei it-agile beantworten wir die Frage meist sehr global und geben für agile Transitionen von Abteilungen oder Organisationen nur 2 Versprechen: 1. Sie erhalten Transparenz, insbesondere auch über ihre Probleme. 2. Das wird ihnen nicht gefallen!
In meiner Interviewreihe mit Managern habe ich nach Hindernissen gefragt und die Summe der Antworten gibt ein interessantes Bild:

  • Es gibt zuweilen einen nicht unerheblichen Kulturschock: Das kann bedeuten, dass das bisherige Heldentum der Entwickler, der Projektleiter und Manager so nicht mehr gefragt (und belohnt) wird. Es kann aber auch bedeuten, dass "altes" Denken aufgebrochen werden muss z.B. bzgl. des Reportings ("wir hatten immer eine Detailplanung 2 Jahre im voraus!") oder der eigentlich entscheidenden Zahlen (Auslastung alleine bringt keinen Geschäftswert!), aber auch die Werte der Organisation können durchaus den agilen Grundwerten entgegenstehen. So hörte ich neulich von einem Unternehmen, in dem der folgende Leitsatz galt: "Alles gleich beim ersten mal richtig machen!" Schön wär's, agil ist es eher nicht.
  • Die Einbindung der Fach- oder Business-Seite stellt häufig ein Problem dar. Das mag auch daran liegen, dass Organisationen hier dazu neigen, Silos zu bilden, deren Zusammenarbeit sich manchmal schwieriger gestaltet als die Zusammenarbeit mit Externen. Es hat aber auch oft damit zu tun, dass zwar viele der Vorteile agiler Methoden vor allem fürs Business sind, dieses aber vielleicht gar nicht danach gefragt hat und jetzt plötzlich mit vermeintlich geringerer Planungssicherheit und mehr und häufigerer Mitwirkung konfrontiert wird. Zudem sind viele Unternehmen und ihre Mitarbeiter bisher nicht an interdisziplinäres Arbeiten in Teams gewohnt und tun sich damit sehr schwer.
  • Ein häufiges Problem ist es zudem, die Erwartungen klar und messbar zu machen, die mit der Einführung von Agilität verbunden werden. Wenn es z.B: um Produktivität geht, stellt sich die Frage, wie diese gemessen wird. Wie berücksichtigt man geringere Folgekosten durch mehr Qualität? Wie wird Produktivität denn bisher gemessen? Wird auch berücksichtigt, dass wir agil Fehlentwicklungen eher erkennen (was viel Geld sparen kann) oder geht es nur um die reine Implementationszeit von Features? 
  • Zuweilen trifft man auch sehr generell auf Widerstände gegenüber jeglichen Veränderungen. Das ist menschlich und hat vermutlich viele Gründe (und je Organisation ganz unterschiedliche). Entwickler befürchten vielleicht die Transparenz über ihre Arbeit und wissen nicht, was mit dieser Transparenz geschieht. Warum soll eigentlich Agilität eingeführt werden? Was bedeutet es für den einzelnen? Und warum sollten sie mehr Verantwortung übernehmen? Was bekommen sie umgekehrt dafür an auch individuellen Vorteilen?
  • Ich bin ja selbst auch Manager. Die meisten von uns sind ungeduldig. Insofern verwundert es nicht, dass viele in den Interviews davon berichtet haben, dass der Weg länger war als erwartet. Keiner hat ihn aber deshalb abgebrochen. Ich glaube, hier ist es einfach hilfreich, wenn man sich klar macht, dass auch agile Methoden nicht von heute auf morgen wirken und ganz schnell alle Probleme lösen (ohne dabei neue wichtige Fragen aufzuwerfen).

Auch für die Hindernisse gilt wieder (wie schon für die Vorteile aus meinem letzten Blogpost), dass ich hier die Summe aller Antworten wiedergegeben habe. Zum Glück hat nicht jeder Manager alle diese Hindernisse erlebt, aber einige schon auch ziemlich viele der aufgeführten. Es hat sie aber alle nicht davon abgehalten, den agilen Weg weiterzugehen, auch wenn er durch die Hindernisse bei dem einen oder anderen aktuell stockt oder steiniger geworden ist. Wenn Sie also Ihren Chef überzeugen wollen, sprechen Sie nicht über alle hier genannten Hindernisse. Sprechen sie aber schon über die, von denen Sie annehmen, dass sie auch in Ihrem Unternehmen zum Tragen kommen könnten. Vielleicht klappt ja auch bei Ihrem Chef der Managersprech, dass es keine Hindernisse, sondern nur Herausforderungen gibt! ;-)

4.12.12

Was überzeugt Manager an "agil"? Teil 1: Erhoffte Vorteile

In meinen Schulungen und auch nach Vorträgen oder in Diskussionen auf Konferenzen und Workshops erklären mir immer wieder  Entwickler, dass sie ja gerne auf agil umsteigen würden, aber Ihr Chefs nicht wollen. Deshalb habe ich mich entschieden, dass ich einmal systematisch aufarbeiten möchte, mit welchen Vorteilen man denn Manager für Agilität begeistern kann.
Um nicht nur auf Grundlage meiner eigenen Ideen zu arbeiten, habe ich Kontakt zu Managern gesucht, von denen ich wusste, dass sie sich in den letzten Jahren für den agilen Weg entschieden haben.
Im August und September habe ich also reichlich Telefoninterviews geführt. Dabei habe ich mich vor allem an den folgenden drei Fragen orientiert:
1. Was haben Sie sich einmal von der Einführung von Agilität versprochen?
2. Welche Hindernisse tauchten auf?
3. Welche Vorteile konnten Sie letztlich wirklich beobachten?

Aufsummiert über alle meine Interviewpartner ergab sich folgendes Bild an erhofften Vorteilen:
Bevor Sie jetzt aber mit dieser Liste zu Ihrem Chef gehen, warten Sie doch bitte noch zumindest die nächsten zwei Teile dieser Serie von Blogpost ab, in denen ich noch von den aufgetreten Hindernissen und den tatsächlich erreichten Vorteilen berichte.
Außerdem sei schon an dieser Stelle darauf verwiesen, dass es sich ja letztlich um die Summe an erhofften Vorteilen vieler Interviewpartner handelte. Kein einzelner von Ihnen hat mehr als drei bis vier Vorteile genannt, die er sich erhofft hatte. Das gilt es auch beim Überzeugen zu bedenken, denn es ist nicht clever, jemanden mit Vorteilen zu überhäufen, den die meisten davon gar nicht interessieren. Aber auch dazu mehr in einem späteren Blogpost.

28.3.12

Lean Startup March: Zahlen, bitte!



Heute nach intensivem Abtauchen in unserem Lean Startup mal wieder ein bisschen Erfahrungen. Dieses mal zu Metriken und Messungen.

Seit wir www.discuss2decide.de im Rahmen unseres Lean Startup March am 5. März gestartet haben, versuchen wir intensiv aus dem Nutzerverhalten und den ermittelten Metriken zu lernen.

Hier ein paar Beispiele:

  • Wir haben eine AdWords-Kampagne gestartet, um zu testen, ob es einen Bedarf nach Tools für effektivere Online-Diskussionen gibt. An zwei aufeinanderfolgenden Tagen war unser Budget von 60€/Tag mit jeweils über 100 Klicks binnen 2 Stunden aufgebraucht! Daraus haben wir geschlossen, dass es den Bedarf gibt. 
Aber: Diskussionen haben die „Bedürftigen“ nicht angelegt.
  • Um unsere Webseite/Startseite zu verbessern, haben wir per A/B-Tests zwei unterschiedliche Varianten gegeneinander aufgestellt (eine eher problem- eine eher lösungsorientiert). Es sah so aus, als ob die problemorientierte besser lief, aber in der Zählung wurden wohl von uns angelegte Diskussionen mitgezählt und es gab weiterhin nur eine sehr geringe Anzahl an angelegten Diskussionen. Ein Homepage-Vergleich mit und ohne Video hat auch nur wenig Unterschied ergeben.
  • Unsere Umfrage nach der Nützlichkeit unseres ersten Features „Kategorien für Diskussionsbeiträge“ fand nur 31 Antworten (ca. 50% fanden die Kategorien hilfreich, knapp 30% eher nicht). Sind 15 Leute aussagekräftig genug für die weitere Entwicklung?
Etwas verzweifelt waren wir über die geringe Anzahl echter Benutzer unseres Dienstes und führten es auf zu rudimentäre Funktionalität zurück. Deshalb haben wir uns in der zweiten Woche primär damit beschäftigt, die Features zu bauen, die wir selbst für notwendig halten. Parallele Messungen ergaben keine relevanten Aussagen, so dass wir dazu übergegangen sind, statt quantitativer Messungen und Auswertungen qualitative Interviews zu führen. Davon haben wir ca. 10 geführt und uns weitere Kandidaten für Interviews auf unserer Seite warmgehalten, die wir noch später befragen wollen.
Die Interviews hatten je nach Kontext zwei unterschiedliche Teile:

  1. Im ersten Teil ging es uns um ein besseres Verständnis des Problems "Online-Diskutieren". Hier haben wir z.B. Erkenntnisse darüber gewonnen, dass es für Teilnehmer wichtig ist, dass sie wissen, was mit dem Diskussionsergebnis passiert und wie verbindlich es ist. Daraus ist ein Feature für den Start von Diskussionen entstanden.
  2. Im zweiten Teil haben wir die Verwendung von discuss2decide.com beobachtet bzw. uns beschreiben lassen: Welche Konzepte sind dabei klar, wo hakt die Bedienung? Hieraus ist u.a. die Umstellung unseres Subscription-E-Mail-Benachrichtigungsmodells auf ein Join-the-discussion-Modell entstanden. 
Kurzum: Wenn Du keine ausreichend aussagekräftigen Zahlen hast, dann sprich mit Leuten, die das Problem haben oder sogar schon Benutzer sind!

P.S.: Noch ein paar Zahlen zum Schluss: Wir hatten jetzt über 3.000 unterschiedliche Besucher auf unserer Seite und es wurden mehr als 250 Diskussionen angelegt, der Großteil waren aber Diskussionen zu Testzwecken.

5.3.12

Lean Startup March: discuss2decide.com - 1. Auslieferung an Tag 3

Am liebsten hätte ich schon am Freitag diesen Beitrag geschrieben, dann aber mit dem Hinweis auf "Auslieferung an Tag 2", aber das haben wir dann doch nicht geschafft. Aber fangen wir am Anfang an.

Letzten Donnerstag haben wir uns pünktlich zu siebt zum 1. März in unserem Satellitenbüro getroffen und mit unserem Lean Startup begonnen. Dabei waren wir relativ schnell mit unseren Hypothesen zu Vision, Problem und Lösung in ersten Würfen fertig. Wir hatten uns aber auch schon vorher darauf verständigt, dass wir thematisch an einem Online-Tool für bessere, strukturiertere Diskussionen arbeiten wollen, die zu Entscheidungen führen. Gefährlich mag sein, dass wir ein solches Tool gerade für it-agile gut gebrauchen könnten, aber wir hoffen, jetzt schnell herausbekommen zu können, ob es nicht auch für andere interessant ist.

Nach diesen Hypothesen, die jetzt bei uns an der Wand hängen, haben wir große Mengen von Annahmen und möglichen Features erarbeitet und gewichtet danach, was wir zuerst herausfinden möchten. Daraus hat sich unser 1. Minimal Viable Product (MVP) ergeben, wobei wir entgegen vorheriger Erfahrungen mehr haben wollten als nur eine Umfrage oder Fake-Mocks (zumindest, wenn sich der Aufwand eines "echten" MVP in Grenzen hält). Faktisch hatten wir unser 1. MVP am Freitag Abend fertig, wollten aber noch ein wenig polieren. Das hat heute fast den ganzen Tag gekostet, sich aber gelohnt. Das Ergebnis ist unter www.discuss2decide.com zu bewundern.

Mit diesem ersten MVP wollen wir herausbekommen, ob Leute bereit sind, ein neues Tool statt bisheriger Foren oder E-Mail (oder etwaiger anderer Lösungen) zu verwenden und ob Ihnen die von uns zur besseren Strukturierung eingeführten Kategorien dabei helfen. Feedback willkommen!

29.2.12

Lean Startup March: Ich bin dabei

Ich bin schon ein bisschen aufgeregt, denn ab morgen starte ich gemeinsam mit 6 meiner Kollegen von it-agile unseren Lean Startup March. Wir haben uns über Slack-Zeit bei it-agile und Urlaub einen ganzen Monat freigeschaufelt und wollen ein Startup hochziehen nach den Ideen des Lean Startup von Eric Ries (The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses) und dem Customer Development von Steve Blank (The Entrepreneur's Guide to Customer Development).
Die Grundidee bei Lean Startups ist der Build-Measure-Learn-Zyklus, in dem validiertes Lernen erfolgt. Es geht also anfangs primär darum, herauszufinden, ob es und für was für ein Produkt es eigentlich einen Markt und Kunden gibt und welche unserer Annahmen diesbzgl. stimmen und welche nicht. Dabei denkt man den Zyklus "von hinten". man stellt sich also die Frage: Worüber möchte ich etwas lernen? Danach fragt man sich, was man wohl messen müsste, um das lernen zu können? Auf dieser Basis entscheidet man, was man minimal bauen muss, um diese Messung zu erhalten. Das muss keinesfalls immer gleich ein System sein, manchmal reicht eine Webseite mit einem Button darauf. Ich verrate inhaltlich noch nichts weiter für heute, aber das wird in den nächsten Tagen folgen.

19.12.11

Certified ScrumMaster Test: Jetzt wird's ernst!

Seit Oktober bin ich auch Certified Scrum Trainer und darf Zertifizierungsschulungen zum Certified ScrumMaster (CSM) und Certified Scrum Product Owner (CSPO) geben. Bisher gibt es beim CSPO gar keinen Test und beim CSM nur eine "Selbstevaluation" (die genau genommen mehr den Trainer als die Teilnehmer bewertet). Aber in 2012 wird der CSM-Test neu aufgesetzt und zwar wie folgt:
  • Ab Januar 2012 enthält der Test komplett neue, andere Fragen als bisher.
  • Wer diesen Test bis Ende März 2012 ausfüllt, kann nicht durchfallen. Voraussetzung für den Test bleibt wie bisher die erfolgreiche Teilnahme an einem CSM-Kurs.
  • Ab Anfang April 2012 besteht man den Test oder fällt durch.
  • Ab Anfang April 2012 haben CSM-Kandidaten die Möglichkeit den Test binnen 60 Tagen nach ihrem Kurs bis zu zweimal ohne zusätzliche Kosten durchzuführen. Nach den 60 Tagen fällt eine Gebühr von 25$ an für eine erneuten Test. Nach drei erfolglosen Versuchen empfiehlt die Scrum Alliance, erneut einen CSM-Kurs zu besuchen, bevor der Test wiederholt wird.
  • Der neue Test umfasst 35 Fragen und hat kein Zeitlimit zum Ausfüllen. Kandidaten können sich Bookmarks auf Fragen setzen, Antworten zu Fragen ändern und sogar den Test stoppen, um später binnen der 60-Tages-Frist darauf zurückzukommen.
  • Am Ende des Tests werden den Kandidaten die Fragen angezeigt, die sie falsch beantwortet haben. Es wird aber keine Liste möglicher Antworten mehr angezeigt. Dies soll sicherstellen, dass zum einen die Prüfungsfragen geschützt bleiben, und zum anderen sollen die Kandidaten ihre Kursunterlagen erneut studieren, bevor sie den Test wiederholen.
  • Kandidaten, die beim ersten Mal durchfallen, können sofort erneut den Test durchführen (und müssen nicht abwarten). Der zweite Versuch kann aber auch zu einem späteren Zeitpunkt innerhalb der 60-Tages-Frist erfolgen.
  • Sobald Kandidaten den Test durchgeführt und bestanden haben, können sie ihren Status alle 2 Jahre erneuern. Die Scrum Alliance wird ein "Professional Development Unit Program (PDUs)" dafür aufsetzen bis spätestens Januar 2012. CSMs müssen dann PDUs sammeln, um ihren Zertifizierungsstatus zu behalten. Details hierzu folgen später.
  • Die aktualisierten Lernziele der CSM-Kurse können bei der Scrum Alliance heruntergeladen werden. Sie stellen die Basis für Struktur und Inhalt des neuen CSM-Tests dar.
Der CSM-Test wird vorerst nur auf Englisch möglich sein. Andere Sprachen und ein Test für die CSPO-Kurse werden aber wohl folgen.

1.11.11

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Schon lange habe ich mir ein Buch gewünscht, in dem es einfach nur viele agile Projektberichte gibt. In diesen Berichten soll es nicht nur alles super und toll gelaufen sein, sondern auch mal gekracht haben, auch mal etwas schwerer gefallen sein. Ich würde dann gerne lesen, was die Leute im Projekt daraus gelernt haben, wie sie agil mit dem Problem umgegangen sind.
Endlich gibt es dieses Buch.
Ich musste es zwar selber herausgeben, es lebt aber von den vielen Autoren der Projektberichte, bei denen ich mich auch hier bedanken möchte (im Buch mache ich das natürlich auch). Es finden sich Berichte über Scrum-Einführungen in Teams, Scrum und Kanban im Mix fürs Unternehmen, agil für Startups, Kanban für Maintenance und Verwaltung und noch viel mehr in diesem Buch.
Ich hoffe, dass es den Lesern genau so gut gefällt wie mir!