69er - Taskboard

Es sind bereits drei Tage im Sprint 1 des 69er Projekts vergangen. Wo stehen wir?

Im vergangenen Beitrag 'Sprint 1 Planning & Estimation Meeting' habe ich angekündigt, einen Einblick in unseren Daily Scrum zu geben und hier sind wir - unser Task Board:



(Wir wollten das Rad nicht nochmals erfinden, daher haben wir uns beim Taskboad von Mountain Goat Software orientiert.)

Wie läuft der Daily Scrum ab?

Das gesamte Team ist anwesend, inkl. Product Owner. Der Daily Scrum geht maximal 15 Minuten. Jedes Teammitglied geht gedanklich die Tasks durch. Dabei werden:

• überfüssige Task entfernt
• fehlende Tasks hinzugefügt
  
• verbleibende Aufwände pro Task überprüft und gegebenenfalls korrgiert (nach oben oder unten)
  
• Zustand der Tasks überlegt
  

Anschliessend gehen wir User Story für User Story durch jedes Teammitglied beantwortet folgende Fragen:

• Was hab ich gestern gemacht?
• Was mache ich heute?
• Was sind meine Hindernisse?

Untermauert wird die Fragerunde mit dem Verschieben von Tasks oder Korrektur des Aufwands. Hindernisse markiert das Team mit brüllenden Fussballstars! Peter Cech steht für fehlende Informationen, Oliver Kahn für blockierendes Hinderniss. (siehe Taskboard, rot eingerahmt)

Jeder bekommt die Chance, mitzuteilen wo er steht, wie er vorankommt und ob er Hilfe braucht.

Der Daily Scrum wird abgeschlossen mit der Frage, wie der heutige Einsatz am Projekt sein wird. Scrum geht davon aus, dass ein Team fix an einem Projekt arbeitet, quasi den gesamten Tag, die gesamte Sprintdauer und letztendlich das gesamte Projekt. Sehr ideal, aber leider nicht realistisch, denn wir Arbeiten auch noch für andere Projekte. Wir haben Scrum hier adaptiert und eingeführt, dass wir die verbleibende Restzeit im Sprint davon abhänig machen, wieviel jeder am Sprint arbeitet, auf täglicher Basis.

Nach dem Daily Scrum wird das Sprint Burndown Chart generiert und and das Taskboard (rechts oben) gepinnt. Es ist Gegenstand für den kommenden Daily Scrum, am nächsten Morgen - und alle freuen sich auf den kommenden Morgen, wenn es endlich wieder heisst - Gentlemen, Daily Scrum!

[Update]
Weiter zum Sprint Burndown Chart
Zurück zum Sprint 1 Planning & Estimation

69er - Sprint 1 Planning & Estimation Meeting

Heute hat das Team gemeinsam die Aufwandschätzung und Planung vom Sprint 1 für das 69er Projekt absolviert. Für alle ein ganz neue Aufgabe, die mit dem agilen Vorgehen nach Scrum eingeführt wurde. Trotz 4 arbeitsintensiven Stunden kann sich das Ergebnis sehen lassen:

Wie gehen mit vier User Stories und 12 Story Points in den ersten Sprint. Basierend auf dem aktuellen Wissenstand haben wir im schlechtesten Fall 98h Aufwand, den wir 132h unterbringen müssen.

Zurück zu Sprint Zero
[UPDATE]
Weiter zum Taskboard

69er - die Persona bitte

Für das 69er Projekt haben wir in der frühen Konzeptionsphase mit Benutzergruppen die Bedürfnisse der potenziellen Nutzer erarbeitet. Als Ergebnis haben wir viel Anwendungszenarien erhalten. Wir haben das Use Cases genannt - ganz klassisch mit UML dokumentiert.

Schnell wurde klar, dass sich Benutzer der gleichen Benutzergruppe unterscheiden würden, ganz einfach aufgrund ihrer unterschiedlichen Interessen und Bedürfnissen.

Ein Use Case Beispiel (nicht im 69er Kontext):

• Akteur: User
• Aktion: kann Abstimmen

Wenn man diesen Use Case bespielsweise in den Kontext einer Wahl des nächsten Präsidenten betrachtet, könnte man folgendes festellen: User ist nicht gleich User!

Je nach politischer Gesinnung, finanziellem Hintergrund, persöhnlichen Präferenzen, äusserlichen Einflüssen, Anonymität der Mitteilung, etc. kann es User geben, die eben NICHT dafür, sondern dagegen stimmen würden.

Also haben wir die User unterschieden und pro Charakter eine Persona konzipiert.

Mike, 52, Prof. für Physik
Mike lebt allein, er hat keine Kinder. Mike betreibt gern Outdoor Sport und nutzt dafür jede freie Minute. Es ist ein naturverbundener Mensch, verabscheut Hass und Gewalt.

Dank Mike haben wir eine ganz neue Sicht auf den Anwendungsfall:

• Akteur: User
• Aktion: kann dagegen stimmen

Persona sind also ein wichtiges Mittel, um unterschiedliche Bedürfnisse gleicher Benutzergruppen zu modellieren. In unserem 69er Projekt werden der Persona User Stories zugeordnet. Jede Persona hängt am Task Board, so dass man sich immer das Benutzerverhalten in den Erinnerung bringen kann.

69er - mein neues Scrum Projekt

Ab Montag, den 28. Juli 08, beginnt für mich (endlich) wieder einmal ein Scrum Projekt, das Vierte nunmehr.

Ich möchte meine Erfahrungen und Erkenntnisse auch hier erneut auf meinem Blog dokumentieren. Da es sich um ein Kundenprojekt handelt und keine projektspezifischen Details beschrieben werden können, gebe ich dem Projekt einen fiktiven Namen: 69er

Das 69er Setup sieht momentan so aus:

Team

• 2-3 Entwickler
• 1 Publisher/Flasher
• 1 Designer
• 1 Product Owner
• 1 Scrum Master (wird von einem Team-Mitglied übernommen, abwechselnd)

Technology

• Ruby on Rails
• Flash
  

Zeit

• 9 Wochen à 5 Arbeitstage, d.h. 4 Sprints à 2 Wochen plus 7 Tag

Das Product Backlog

Das Backlog ist gut gefüllt, wir haben an der Zahl 23 User Stories, deren Aufwand und Komplexität bislang noch nicht klar ist. Womöglich werden die User Stories noch zerlegt und somit in der Anzahl vermehrt.

Was ist bisher geschehen?

Der Auftraggeber hat das Team angefragt, seine Vision von einem Kundenportal in einem recht sportlichen Zeitfenster zu realisieren. Nach einer sehr kreativen Konzeptionsphase wurde die Vision zunächst in verdauliche Einheiten heruntergerebrochen und die high-level Rahmenbedinungen festgelegt, z.B. soll es einen Web Applikation entwickelt werden.

Das Team hat, basierend auf der Vision, mögliche Benutzergruppen und deren Nutzungsbedürfnisse erarbeitet mit dem Auftraggeber abgestimmt. Letztendlich wurden einige Persona und deren User Stories in ein Product Backlog aufgenommen und eine grobe Sprintplanung gemacht. Dies, zusammen mit einer groben Aufwandschätzung, Wireframes und der Beschreibung der Vorgehensmethode, wurden dem Auftraggeber als Offerte zugestellt. Nach formalen Anpassungen kam es zur Beauftragung. Was wir haben:

• provisorisches Product Backlog
  
• provisorische Sprint Planung
• provisorische Resourcenplanung

Scrum Adaption

Der Auftraggeber anerkennt unser Vorgehensvorschlag nach Scrum, wird allerdings nicht in seiner Funktion als Product Owner teilnehmen. Daher hat das Team beschlossen, einen Product Owner Proxy einzusetzen - der Key Account Manager auf Unternehmensseite. Er kennt den Auftraggeber, dessen Vorstellungen und Wünsche. Er ist in der Lage, das Projekt erfolgreich abzuwickeln und kann die Aufgaben eines Product Owners nachkommen. Der Scrum Master wird vom Team gestellt. Diese Rolle soll abwechselnd pro Sprint neu vergeben werden.

Wie gehts weiter?

Für das Scrum Team ist dieses Vorgehen bislang unbekannt, zumindest praktisch. Daher ist es jetzt wichtig, alle ins Boot zu holen, um gemeinsam ein akzeptables Vorgehen zu erarbeiten. Zu Begin der nächsten Woche wird es für das Team eine kurze Einführung in Scrum geben. Anschliessend werden wir gemeinsam folgende Punkte angehen:

• DONE Definition erarbeiten
• Setup der Tools und Entwicklungsumgebung
• Offene Punkte und indentifizierte Hindernisse
  

Los gehts mit dem Sprint 1 Planning & Estimation Meeting

Demnächst, hier auf dem Blog!

Ham and Eggs - Und Scrum?

Was haben Hühner und Schweine mit Scrum zu tun? Ein Video der Rails Conference 2008 verschafft einen Überblick.

ArmerKater.de

Ich lese den Blog armerKater.de, un neulich hab ich die Slides dort gefunden, urspünglich vom PM-Blog. Sehr gut.

| View | Upload your own

Der agile Mentor - Planning Meeting Sprint 1

Im Anschluss an die Retrospective von Sprint Zero kam der eigentlich wichtige Teil, zumindest für mich. Mein nächstes Ziel war es, eine Aufwandschätzung vom Team zu bekommen, um einen Sprint planen zu können. Damit das gesamte Team hinter diesem Ziel steht, habe ich eine List angewandt: Wir haben geschaut, was im Sprint Zero realisiert werden konnte. Bis zu diesem Zeitpunkt wurden keine User Stories verwendet, also haben wir die abgeschlossenen Arbeitspakete im Plannungstool einfach mal zusammengezählt: 21 von 26, nicht schlecht! Oder doch?

Also fragte ich,

• ob dass ein gutes Ergebnis sei? - konnte man nicht richtig beanworten, wahrscheinlich schon
• hatte man sich über-committed? - konnte man nicht richtig beantworten, eher nicht - es sind ja ständig neue Dinge dazu gekommen
• wieviel Aufwand steht hinter 21? - konnte man nicht beantworten
• warum wurde 26 nicht erreicht? - ja, man hätte noch viele Dinge gemacht, die man da nicht sehen könne
• wo stehe man denn im Hinblick auf den Endtermin - konnte man nicht beantworten, eher so ein Bauchgefühl

Viel Verwirrung - und ich kam mir vor wie ein Lehrer vor seiner 8.Schulklasse, der eben verkündet hat, dass man auf der Klassenfahrt kein Alkohol trinken darf, toll!
Was soll denn das? Wo führt das hin? Warum müssen wir das tun?

Ratlosigkeit! Nach ein paar Sekunden Schweigen habe ich vorgeschlagen, dass wir die kommenden zwei Wochen planen (hatten wir bei Sprint Zero nicht gemacht). Wir wollen uns gemeinsam ein Ziel setzten und dieses erreichen und - viel wichtiger - wir wollen wissen, was wir in zwei Wochen erreichen KÖNNEN

Wir befragten das Plannungstool - was gibts überhaupt noch zu tun?

Schnell wurde festgestellt, dass man im Planungstool Tasks, Issues, Bugs, Packages, Components, SubTask u.v.m. auf gleicher Ebenen behandelt und viele Zusammenhänge, z.B SubTask --> Tasks --> Components bestehen. Ausserdem fehlte die Aufwandschätzung pro Arbeitspaket, unabhängig von der Granularität. Von meinem Standpunkt aus sah das alles unübersichtlich aus. Ich konnte mir absolut kein Bild darüber machen, was noch getan werden musste und wie Arbeitspakete zusammen hingen- keine Ahnung, und ich war nicht allein! Also beschloss man, schnell ein paar Arbeitspakete zu eleminieren und zusammenzufassen - eben aufräumen.

Ich beobachtet das Geschehen und so langsam wurde mir klar, dass das Plannungstool eher ein Gedächtnisstütze jedes Einzelnen war. Alles, was einem so eingefallen ist bei er Bearbeitung von Issues, wurde als Task, SubTask, Component, Issue oder was auch immer hinuzugefügt. Damit änderte sich die Menge und Inhalt der Informationen im Tool quasi stündlich. Das Plannungstool diente der Dokumentation.

Planung? Auf dieser Basis unmöglich!

Nach der Bereinigung verständigte man sich auf eine Entität für planbare Arbeitspakete im Plannungstool - Task. Components, SubTasks, Issues und alles andere sind Dokumentation, Tasks sind Arbeitspakete, planbare Arbeitspakete.

Ok, ich gab dem Team die Aufgabe, für die nächsten Tasks die Aufwände zu schätzen. Was die nächsten Tasks sind, sollte das Team selbst entscheiden. Ich beschäftigte mich damit, die verfügbaren Ressoucen abzuklären.

Am Ende beschloss das Team Arbeit für 184h anzunehmen.

Zürück zur: Retrospective Sprint Zero
Weiter zur: Retrospective Sprint 1

Der agile Mentor - Retrospective Sprint Zero

Nachdem im Sprint Zero der Daily Scrum von Team eingeführt wurde, lebte die Kommunikation auf - in manchen Punkten mussten Teammitglider sogar gebremst werden. Im Grossen und Ganzen haben wir es erreicht nicht mehr als 15 min pro Daily Scrum zu nutzen.

Vierzehn Tage später, am Ende von Sprint Zero plante ich eine Retrospektive, um den Puls des Teams zu fühlen. Dabei wurden folgende Punkte mit Verbesserungspotenzial festgehalten:

• Daily Scrum schweift teilweise ab
  
• AJAX Exception Handling fehlerhaft
• Close Event bei Lightboxe löst einen Reload aus - Usability!
• viel unused Code, viel FIXME und TODO
• Testabdeckung mangelhaft
• Exception bei Suche
• Wireframe zum Task - Wo liegt der? Bessere Vorbereitung!
• Tooling und Infrastruktur Handling kompliziert

Ok, gut!

Wir haben die Punkte angesehen und ein paar herausgenommen, die im kommenden Sprint 1 verbessert werden können.

Zurück zu: Sprint Zero
Weiter zum: Planning Meeting Sprint Zero

Der agile Mentor - Sprint 0

Nachdem ich mich mit der Projektsituation und der Arbeitsweise des Team vertraut gemacht hatte, brauchte ich einen Plan - ganz entgegen den Scrum Prinzipien.

Zunächst gab es vier Punkte, die ich dem Team nahebringen wollte:

1. tägliche Status-Meetings (max. 15 min)
2. fokussiertes Arbeiten im 2 Wochentakt - wir wollen alle 2 Wochen etwas produzieren
3. Aufwandschätzungen zu den Arbeitspakten vom Team
4. Planung der kommenden 2 Wochen

Um diesen Plan umzusetzen und das Commitment vom Team zu bekommen habe ich ein Meeting zu einem Kaffee einberufen. Bereits nach wenigen Argumenten waren das Team dafür, dass man tägliche Statusmeetings einführen sollte, denn oft gingen wichtige Informationen unter oder waren nicht für jeden im Team verfügbar. Da das Team räumlich eng beieinander sass, machten wir die die Stand-up's an einem Arbeitsplatz, wer nicht da war nahm per Skype teil.

Mehr nicht! Das war die erste und einzige Neuerung. Als nächstes wollte ich den 2 Wochen Takt inklusive Planung einführen. Ich hatte etwas Zeit gewonnen, die nächsten Punkte vorzubereiten.

Was daraus wurde und was das Team von den Stand-up's hielt, sollte ich in der ersten Retrospective erfahren.

Dranbleiben!

Zurück zur: Scrum Einführung
[Update]
Weiter zur: Retrospective Sprint Zero

Get Started: Workreportr

Vor etwas mehr als einem Monat habe das Ruby on Rails Buch endlich mal aufgeschlagen und war sofort begeistert. Schnell war mir klar - das musst du mal machen! Ok, ich brauchte ein Übungsprojekt und hier sind wir nun ...


Get Started:

Das Projekt heisst Workreportr und es lebt bei amazee.com.

Da amazee eine social collaboration Plattform ist, kann jeder mitmachen. Also bitte, einfach beitreten und mitwirken.

Danke, jp

Der agile Mentor - Scrum Einführung

Vor kurzem wurde ich bei einem externen Projekt als agiler Coach hinzugezogen. Bei diesem Team hatte ein Entwickler bereits Erfahrungen mit Scrum. Es wurde der Wunsch geäussert, nach Scrum vorzugehen. Der zuständige Projekt Manager überliess diese Entscheidung dem Team und so arbeitete man nach Scrum. Kurz vor dem ersten Release wurde ich als Entwickler und agiler Mentor hinzugezogen.

Nach wenigen Tagen ergab sich folgende Bild:

Vor dem Projekt wurde ein detaillierte Spezifikation geschrieben, die zum Projektbeginn von einem Entwickler in Arbeitstasks runtergebrochen wurde, ohne Aufwandschätzung. Der Endtermin war fix. Man zerlegte die Realisierungzeit in kleine Teil-Releases und verteilt die Arbeitspakete (gleichverteilt, x Tasks pro Release). Daraus abgeleitet ergab sich eine grobe Releaseplanung bis zum Projektende. Verschiedene Elemente von Continous Integration wurde installiert: Version Control, Build Server, Unit Testing. Rollen, Regel und die Scrum Rituale, Planning & Estimation Meeting, Sprints, Demo, Retrospective und Daily Scrum wurden nicht angewendet. Der Kunde, in seiner Funktion als Product Owners oder im allgemeinen, war im Verlauf der Realisierung nicht involviert. Es gab eine ausführliche Definition von DONE, kaum jemand hielt sich dran. Wöchentlich wurden Status Meetings abgehalten. Als Projektmanagement und Entwicklertool wurde Jira eingesetzt. Wenige Wochen vor dem ersten Release wusste man nicht, ob man fertig würde. Zusammenfassend kann man sagen: kein agil, kein Scrum!

Ok, ich habe mir also eine Strategie zurechtgelegt, wie Scrum vom Team angenommen und vollumfänglich implementiert werden könnte. Grundsätzlich gab es zwei Optionen:

• Sofortige Scrum Einführung mit allen Ritualen, Rollen und Regeln, quasi "von jetzt auf gleich", oder
• Sequentielle Implementierung, nach und nach ein weiteres Element aufnehmen.

Aus der Erfahrung heraus schien mir die erste Option zu unrealistisch. Ein etabliertes, produktives Team ist alles andere als glücklich, wenn ein Aussenstehender ein neues Vorgehen einführt, dazu noch eines, was so radikale Veränderung mit sich bringt und kaum Akzeptanz findet. Ich entschied mich also für die zweite Option.

Als ich zum ersten Mal mit Scrum in Berührung kam, war ich in einem Projekt als Software Engineer tätig, was mässig erforgreich war. Der Kunde wurde mehrfach hingehalten, die Reaktionszeit war schlecht und die Bug Rate war sehr hoch. Die Projektleitung wurde ausgetauscht und mit der neuen Person kam ein neues Vorgehen - agil nach Scrum! Der ScrumMaster hat zu Beginn nur eine Regel eingeführt - wir wollen fokussierter arbeiten und alle 3 Wochen etwas nützliches produzieren.

Ich legte mir einen Plan zurecht - was daraus geworden ist und welche Erfahrungen ich gemacht habe?

Dranbleiben.

Warum machst DU Scrum?

Neulich wurde ich mit dem Vorwurf konfrontiert, Scrum der Karriere wegen zu verfolgen. Hm, nun ja - man kann zweifellos zugeben, dass man zu einen kleinen Personenkreis zählt, denn bislang ist die Scrum Gemeinde in Europa recht klein, und dass, obwohl Scrum keineswegs etwas Neues ist.

Aus meiner Sicht gibt es nur ein Alleinstellungsmerkmal bezüglich der Karriere - man arbeitet anders.

In einem Beitrag Erfolg! habe ich drei Sichten beschreiben, die Erfolg definieren:

• Stufe 1: persönlicher Erfolg
• Stufe 2: technischer Erfolg
• Stufe 3: unternehmerischer Erfolg

Aus Entwicklersicht behaupte ich, dass man mit Scrum zwangsläufig mit Stufe 3 auseinander setzen muss - quasi der Entwickler der dritten Generation.

Ich sehe das als absolutes Job-Enrichment! Mit Scrum kann ich meine Arbeit so erledigen, dass ich alle Stufen erreiche. Aber Moment mal, kann man das mit klassischem Projektvorgehen, z.B. nach Wasserfall nicht ereichen?

Nun, die Antwort muss jeder selbst finden. Ich allerdings fand mich bei diesem Vorgehen immer wieder mit der Tatsache konfrontiert, dass ich Dinge machen musste, bei denen ich bereits zu Beginn wusste, dass sie wenig Erfolg bringen werden, weder persönlich, noch technisch, noch unternehmerisch.

Man hat eine detaillierte Spezfikation vorliegen und die arbeitet man ab. Nicht selten stellt man während dessen fest, dass die Spezifikation nicht alle Fragen beantwortet oder sich sogar in wichtigen Punkten wiederspricht. Dazu kommt, dass man in früheren Phasen der Analyse oder Konzeption als Entwickler garnicht involviert ist - Argumente und Hintergründe, warum z.B. genau DIE Architektur gewählte wurde, ist oft nicht transparent. Architekten, Business Analysten, GUI Experten und Designer gehen in zu Beginn oft parallel vor, sodass die Spezifikation nicht aus einem Guss ist und teilweise nicht aufeinander abgestimmt wird. Und zu guter letzt ist meistens mehr als die Hälfte der Zeit bzw. Budget bereits aufgebraucht, bis man mit der Realisierung beginnen kann ...

Ich habe Scrum eher auf die harte Tour kennengelernt und habe mich anfänglich nicht damit identifizieren können. Heute, nach diversen Erfahrungen mit agilen Projekten nach Scrum würde ich das Thema agil als Evolutionsstufe bezeichnen. Zurück führt kein Weg mehr!

tinyPM 1.1 Agile Project Management Tool Released

tinyPM, wie der Name bereits verrät, ein schlankes Tool zum Managen von agilen Projekten.

Ich habe mir kurz die Zeit genommen und die Software ausprobiert. Wirklich gut, hat mich überzeugt. Einfach, schlank, auf das wesentliche reduziert, sehr usable und leicht zu bedienen. Kaum Schnick-Schnank und bis zu 5 Usern auch noch Freeware (Communitiy-Edtion).

Features:

• Backlog
• User Stories
• Iteration Planung
  
• Taskboard
• und vieles mehr ...

Goodies:
Ich find, dass einige Dinge sehr schön gelöst sind:

• Automatische Taskgenerierung (Dinge, die man bei jeder User Story braucht)
• Verschlagwortung von User Stories und Tag Cloud
• Sehr übersichtliches Dashboard
• History, woran habe ich gearbeitet (filterbar)
• Wiki, einfaches und gutes Wiki im Tool - für die Brainstorming's

Summary:

Ich bin ja ein Fan von Flip-Chart und White Boards, aber das Tool hier ist echt mal nicht schlecht. Einfach mal ausprobieren, lohnt sich.

Ergebnisse: Blitzumfrage/Training

Die Umfrage zu Scrum-Trainingsbedarf war eine Woche aktiv und leider sind nur 7 Antworten gekommen. Die grosse Frage ist, können wir diese Ergebnisse überhaupt brauchen?

Tun wir ein Moment so, als ob die Ergebnisse relevant sind, und schauen wir, was sie bedeuten würden. Wie ist der deutschsprachige Scrum-Markt anders als die globale Scrum-Markt?

Akzeptanz der CSM

Das erste was auffällt ist die hohe Akzeptanz der CSM. Bei der internationale Umfrage hat man etwa gleich viel Interesse für zertifizierte und nicht zertifizierte Ausbildung. Hingegen bei den deutschsprachigen spricht eine klare Mehrheit für den CSM.

Woran liegt das? Ich kann mir vorstellen, das Scrum eher in den Startlöchern hierzulande steht. Das heisst, es sind die 'early adopters', die auszubilden sind. Also die, die für Scrum werben und für sich einen Zukunft mit Scrum sehen. Für sie ist die Zertifizierung wichtig.

Hingegen im englisch sprachigen Ausland, die uns ein bischen im voraus ist, ist man womöglich eher mit Ramp-Up und Roll-Out beschäftigt: grössere Zahlen von Entwicklern und Projektleitern, die ausgebildet werden müssen, wo die Kosten eine grössere Rolle spielen.

Bei beiden Sprachgruppen stellt man fest, das agile Planung und Schätzung ein wichtiges Thema ist. Wie kann man ein agiles Projekt aufgleisen...

Und die Sprachfrage

Nicht überraschend, man hat eine starke Vorliebe für Kurse auf Deutsch und man ist nur mittelmässig von Kursen auf Englisch begeistert -- aber auch nicht total abgeneigt, was meine persönliche Erfahrung eher nicht entspricht. Diese Erfahrung bezieht sich auf Firmen, die die Ausbreitung überlegen. Hier ist Englisch weniger akzeptabel, da die Kenntnisse sehr unterschiedlich sind. Die early Adopters haben wohl ihre erster Kontakt über den Englisch sprachigen Schriftweg gemacht und haben dabei weniger Berührungsängste.

Sind die Ergebnisse brauchbar?

Rein statistisch gesehen, sicher nicht. Die Umfrage ist weder wirklich representativ, noch sehr breit verbreitet. Und dennoch, in manchen Bereichen, v.a. die Akzeptanz der CSM-Ausbildung wie auch die Sprach-Frage, entspricht die Umfrage meine Erfahrungen. Ferner habe ich bei diversen Umfragen beobachtet, die Verhältnisse zwischen den Stimmen werden sehr früh ersichtlich. Also meiner Meinung nach: sicher nicht perfekt, aber auch nicht wertlos.

Ich für mich habe vor, so zu tun, als ob die stimmen würden. Ich habe mir den Ziel gesezt, die CST-Stufe zu erreichen (na gut, die englische Version dieser Umfrage und die vereinfachte Bedingungen haben dazu beigetragen). Ich weiss, was mein nächster Kurs sein wird. Schauen wir mal! So ist das Leben, man entscheidet auf Grund von unvollständigen und womöglich unrichtigen Daten...