Blitzumfrage: Scrum-Trainingsbedarf

Vor ein paar Wochen habe ich auf meinem Blog eine Umfrage zum Thema Scrum Ausbildung gestartet. Da ich in der Schweiz wohne, trotzdem aber lieber auf English schreibe, ist die Thema Sprache interessant. Konkret: wie wichtig ist es, dass Scrum-Ausbildung auf Deutsch angeboten wird? Sind die Bedürfnisse bei deutschsprachigen Firmen ähnlich, oder hat die englisch sprächende Welt diese Umfrage dominiert?

Also habe jp gebeten, die Umfrage zu wiederholen - was eine Gegenaufforderung produziert hat — und hier sind wir ;-)

Vorher hatte ich eine Blitzumfrage zum Nokia Test durchgeführt, die gezeigt hat, dass viele Firmen eigentlich gar kein Scrum machen (und das, obwohl die Mehrheit der Teilnehmer über die 'scrumdevelopment'-Gruppe davon erfahren haben!). Und so hat sich die Frage gestellt, wie Firmen ihren Scrum Ausbildungsbedarf einschätzen.

Zurzeit wird die Scrum Ausbildung als ein Art Zunft organisiert. Der erste Schritt ist dabei, Certified Scrummaster (CSM) zu werden. Das ist die Grundlage für alle weiteren Stufen, das wichtigste ist allerdings der Certified Scrum Trainer (CST). CSTs dürfen wiederum neuen CSMs ausbilden. Zurzeit gibt es etwa 25'000 CSTs, allerdings nur 54 CSMs. Bis vor kurzem musste man bereits 5 Jahre CSM sein, bevor man sich als CST bewerben durfte.

Das Kern der Scrum Ausbildung in der CSM Kurs. Dabei bieten die meisten CSTs zusätzliche Kurse für besondere Nischen. So weit ich weiss, gibt es nur 4 deutschsprachige CST's, Boris Gloger, Andreas Schliep, Joseph Pelrine und Roman Pichler, auch wenn nicht alle ihre öffentlichen Kurse auf Deutsch durchgeführt werden.

Also stellt es sich die Frage, ob dieser Angebot dem Bedarf gerecht ist. Was braucht Ihre Firma für Scrum Ausbildung?

Unten habe ich eine Liste von Möglichkeiten zusammengestellt, die hoffentlich dem Bedarf in den deutschsprachigen Ländern gerecht wird. Bitte in der Umfrage oben rechts alles ankreuzen, was zutrifft:

Zu meinem Ausbildungsbedarf, bzw zu den Bedarf meiner Firma gehören:

• Zertifizierte Scrum Ausbildung (CSM)
  
• günstigere, nicht zertifizierte Training
• Starthilfe Workshops
  
• Workshops für Fortgeschrittene
• Agile Schätzung und Planung
  
• Agile Vertragswerke
  
• Lean Strategie-Workshops
  
• XP (SW Engineering)
• Offene Kurse
  
• Firmen-Kurse
  
• Web-basierte Ausbildung (Webinars)
  
• Podcasts
  
• Kurse auf English
• Kurse auf Deutsch
• Kurse auf Französisch
• Kurse in anderen Sprachen
  
• Englisch wäre akzeptabel
  
• Englisch ist nicht akzeptable
  
• Kein Bedarf an Training
• anderes
  
• Weiss nicht/ist egal

Zum Datenschutz: obwohl ich an die Ergebnisse nicht uninteressiert bin, die Umfrage-Software von Blogger.com sammelt keine persönliche Informationen (oder falls doch, mir sagen sie nichts). Also werde ich mit niemandem Aufgrund der Stimmabgabe kontaktieren (es sei denn, Sie nehmen aktiv Kontakt mit mir auf).

Die Ergebnisse (samt Vergleich mit der englischen Ausgabe) werde ich hier zusammenfassen, nachdem die Umfrage abgeschlossen ist.

Gastbeitrag Peter Stevens

Peter Stevens, der Autor von http://scrum-breakfast.blogspot.com, hat bei mir angefragt, ob ich nicht ein Umfrage auf meinem Blog posten könne, die er auf seinem Blog bereits in Englisch durchgeführt hatte. Darauf hin habe ich ihn eingeladen auf meinem Blog einen Gastbeitrag zu schreiben.

Wir dürfen gespannt sein. Bis bald.

Wie wird man agil?

Ob man sein Auto wäscht, einen Schrank von Ikea zusammenbaut oder Software entwickelt, man folgt einem Prozess, teils intuitiv oder entlang einer schriftlichen Anleitung per Text oder Piktogrammen.

Agile Softwareentwicklung ist kein Prozessmodell und es gibt nicht DEN agilen Weg. Agil ist ein Bewusstsein, eine Haltung. Das agile Manifesto fast das gedankliche Modell in 4 Werten und 12 Prinzipien zusammen.

Die agilen Werte.[http://agilemanifesto.org/]

Die agilen Pinzipien.[http://agilemanifesto.org/principles.html]

Agil sein bedeutet, dieses Werten und Prinzipien zu folgen.

Erfolg!

Erfolg! Was genau heisst das? Traditionell definiert sich Erfolg durch Lieferung on time, on budget und gemäss Spezifikation.

Doch an dieser Definition ist ganz richtig! Man kann Projekte on time, on bugdet und gemäss Spezifikation abwickeln und mit dem Ergebnis verdient man keinen Cent. Andererseits gibt es Projekte, die über Budget, über den Deadlines und mit weniger Funktionen als spezifiziert abgeschlossen werden und man verdient damit viele hundert Dollar.

Es muss also noch etwas geben, ausser Deadlines einzuhalten. Was?

Als ich noch studierte habe ich oft nebenbei Websites mit PHP programmiert, viel herumgespielt, ausprobiert und umgebaut, bzw. weggeworfen. Solange ich Spass hatte, war ich erfolgreich, auch wenn etwas nicht funktioniert hatte. Mein Definition von Erfolg beruhte auf persönlichen Erfolgserlebnissen, he - Programmieren macht Spass!

Später, bei meiner ersten Anstellung als Software Engineer, wurde die Codebasis schnell sehr gross. Teilweise wusste man garnicht, warum oder wo etwas überhaupt funktioniert. Plötzlich wurde Wart-, Pfleg-, und Integrierbarkeit von Code wichtig. Ich musste lernten sauberen, eleganten und pflegbaren Programmcode in einem Team zu schreiben. Erfolg definiert sich nun so: technisch hervorrangend.

Trotz technisch hervorrangendem Programmcode wurden viele Projekte ein Desaster! Ich musste feststellen, dass Software neben mir und dem Team noch viele andere Stakeholder hatte, dessen Bedürfnisse es zu befriedigen galt - Endbenutzer, Betrieb'ler, Projektleiter, Controller und natürlich mein Chef, der mir meinen Lohn zahlt. Ich lernte, dass der Wert einer Software die gesamten Kosten abdecken muss. Erfolg hatte plötzlich eine unternehmerische Dimension!

Alle drei Dimensionen von Erfolg schliessen sich nicht aus, vielmehr sind alle besonders wichtig, denn nur im Zentrum findet man die Antwort auf die Frage, was neben Deadlines noch wichtig ist.

Ohne persöhnlichen Erfolg ist man schwer motivierbar. Ohne technischen Erfolg gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmerischen Erfolg wird sich das Team vom Unternehmen abwenden und eine neue Herausforderung suchen.

Der unternehmerische Erfolg wird von Softwareentwicklern oft zu Gunsten des persönlichen und technischen Erfolgs vernachlässigt, denn die sind einfacher zu erbringen und dafür ist jeder Softwareengineer letztendlich auch verantwortlich. Absurder Weise erwartet man aber, dass sich die Softwareentwickler dem übergeordneten Ziel - unternehmerischer Erfolg - unterordnen. Manager und Entscheidungsträger interessieren sich nicht für sauberen, eleganten und pflegbaren Code und die persönlichen Vorlieben der Entwickler - sie sind an Ergebnissen interessiert, am Return of Investment von einem Projekt.

Leider gibt das Management den Teams den Weg nicht vor, man erwarten dass das Team die Details klärt und einen richtigen Weg wählt. Wenn das erhoffte Ergebnis ausbleibt, werden Massnahmen eingeleitet, die sicherstellen, dass Entwicklerteams die gewünschten Erfolge bringen. Die Kosten sind an der Stelle ein beliebtes (Streit)Thema. Es gibt dann aus Managementsicht drei Ansätze:

• Vorgabe harter Deadlines um Entwicklungzeit zu reduzieren
• Outsourcing der Entwicklung in scheinbar billigere Länder
• beides

Wenn einem diese drei Punkte bekannt vorkommen, ist es vielleicht Zeit den unternehmerischen Erfolg bei Entwicklungsteams überhaupt ins Spiel zu bringen.

Warum agil?

Agil ist populär, viele Grosse Unternehmen gehen agil vor: Google, Microsoft, Symantec und viele mehr. Sie alle haben agile Prinzipien adaptiert, teilweise sogar eine eigene agili-irgendwas Methode entwickelt. Erwartungsgemäss schiessen derzeit auch agile Zerifizierungsfirmen aus dem Boden, die auf der agilen Welle mitschwimmen und gegen Entgelt "Certified Agile Consultant" Titel vergeben - die Zertifizierungspraktiken sind oft zweifelhalf. Vielerorts genügt die Teilnahme eines Kurses zur Erlangung des Titels, von Zertifizierung keine Spur. Überbewerten Sie das nicht!

Professor Frederick P. Brooks, Jr., University of North Carolina USA, behauptete 1986, dass sich binnen 10 Jahren keine einzige Technologie oder Management-Methode die Produktivität, Nachhaltigkeit oder Einfachheit um den Faktor 10 erhöhen würde. In seinem Buch aus dem Jahr 1995:

"The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition" MA: Addison-Wesley

kommt er zum Ergebnis, dass es keinen Königsweg gibt.

Agil ist auch kein Köngisweg! Grundsätzlich sollte man agil nicht anwenden, wenn man ausschliesslich die Produktivität erhöhen möchte!

Die Vorteile von agil rühren daher, dass man anders arbeitet, und nicht schneller! Agil Arbeiten ist ein Lernzprozess für jedes Team, und dass kann 2 bis 3 Iteration dauern. Während dessen wird man langsamer sein, nicht schneller! Das Team muss agil praktizieren und lernen, ähnlich einem kleinem Kind, dem man Basketball spielen beibringt. Zunächst wird jedes Kind den Ball in die Hand nehmen, ihn für sich beanspruchen und ihn nicht mit den anderen Teilen. Es dauert seine Zeit, bis man den Kindern vermitteln kann, dass es ein Teamspiel ist und man den Ball abgeben muss.

Agil mag momentan gerade "cool" und "in" sein, aber das ist kein Grund, agil vorzugehen. Wenn man agil vorgehen möchte, dann gibt es nur eine Frage:

Wird uns agiles Vorgehen dabei helfen, erfolgreicher zu sein?

Wenn man diese Frage beantworten kann, weiss man ob agil richtig für einen ist.

In den kommenden Posts werde ich ein paar Punkte aufzeigen, die bei der Beantwortung der Frage helfen können:

• Wann ist man "erfolgreich" - wenn Deadlines erfüllt werden?
• Welche Arten von Erfolge gibt es? Welche sind für agil wichtig?
• Wie sieht eine Organisation aus, die agiles Vorgehen nachhaltig unterstützt?
  

SpringOne 2008, Antwerpen

Auch dieses Jahr ist die namics bei der SpringOne in Antwerpen, Belgien vertreten. Die SpringOne ist einen Entwickler Konferenz, bei der sich Spring Entwickler und Spring Anwender treffen, um neue Features und Ideen von Spring Core, Spring Enterprise oder Spring in Production zu diskutieren.

Wer live dabei sein möchte: RSS- Feed, Flickr

SpringOne2008

Guidewire Case Study beim Scrumbreakfast #7

Professor Stuart Read vom IMD Lausanne hat am Scrumbreakfast #7 eine Case Study von Guidewire vorgestellt. Anders als erwartet hielt Stuart keine herkömmliche Präsentation, sondern gestaltet den Scrumbreakfast als Diskussion bzw. Workshop.

Guidewire ist ein Unternehmen, was mit Scrum aufgebaut wurde, von der ersten Stunde an. Nicht nur, dass es Sprint Team gibt, um Software zu entwickeln, nein - Guidewire ist eine komplett agil aufgebaute Organisationsstruktur. Die Firma reorganisiert sich jeden Monat. Teams wurden neu zusammengestellt, Funktionen und Rollen neu verteilt und interessanter weise zogen sogar die Teams mit ihrem gesamten Desktop um.

Beim Scrumbreakfast #7 traff Stuart auf eine Gruppe von Scrum Anwendern (und solche, die im Begriff sind, Scrum einzusetzen) und wollte von den praktischen Erfahrungen lernen.

Stuart begann den Workshop mit der Frage, welche Personen für agile Teams eingestellt werden sollten: keine Indiviualisten, Teamplayer, Early Adaptors und Output-orientierte Personen. Darüber hinaus wurde darauf eingegangen, wie man den Recruiting Prozess gestalten könne: das Team entscheidet. Der gesamte Entscheidungs- und Organisationsprozess bei Guidewire kommt von der Basis - Bottom-up.

Dann stellte Stuart die Frage, ob man als Kunde eine Software von einem Unternehmen kaufen würde, wenn sich dessen Organisation ständig ändert. Hat man da Verrtauen? Vertrauen, das ist wohl das Kernelelement. Regelmässig liefern, was man versprochen hat - der Schlüssel zum Erfolg.

Guidewire hat in der Zwischenzeit mehr als 350 Mitarbeiter und soll an der Börse notiert werden. Erstmalig in der Erfolgsgeschichte des Unternehmens gab es nun ein Problem - fehlende Hierachie. Es gab keinen CTO, keinen CEO, keinen CFO etc. Wie führt man ein Unternehmen an die Börse, wenn es keine definierten Strukturen hat?

"Wer ist der CTO von Guidwire?"

"Ja, welchen meinen Sie, den von diesem Monat oder den vom vorherigen?"

Stuart fragte uns Teilnehmer, wie wir das Unternehmen beraten würden? Ein paar Minuten später lieferte er die Anworten:

• Die Entwickler-Teams werden in Pods von 3 bis 6 Personen organisiert.
• Jeder Pod hat einen Pod Leader, quasi einen Team Captain.
• Wird ein Team zu gross, gibt es einen Split.
  
• Jedes Team arbeitet an einem spezifischen Teil des Produkts.
• Jeder im Team ist in der Lage, an allen spezifischen Elementen des Teil-Produkts zu arbeiten.
• Die physische Umgebung wurde an dem Team angepasst, um die Kommunikation zu erhöhen - alle sitzen beieinander.
  
• Reviews von Pods werden vom Head des Produktteils durchgeführt, nicht vom Pod Leader.
• Pod Leader werden nach Kompetenz ausgewählt - er kann jeden Job, den ein anderes Teammitglied erledigen kann, auch selbst erledigen.

Guidewire, ein agil organisiertes Unternehmen, dass erfolgreich ist. Die Menschen, die dort arbeiten, würden wohl nie in einem stark hierarchisch organisierten Unternehmen arbeiten und umgekehrt auch nicht. Stuart erzählte, dass man einen CTO von der IBM bei Guidewire eingestellt habe, der das Unternehmen nach kurzer Zeit wieder verliess ...

Mein Resümee

Das Scrumbreakfest #7, organisiert von Peter, war ein interessanter Anlass, insbesondere, weil ich viele organisatorische Prinzipien und Ansätze die diskutiert wurden, bei meinem akutellen Arbeitgeber namics wiederfand. Und dabei ist mir eines klar: nach namics würde es definitiv schwer ein vergleichbares Arbeitsumfeld zu finden ...

barcampbodensee

Auf dem barcampbodensee gab es in den letzten zweit Tagen interessante Sessions, die sich mit diversen Methoden zum Entwicklen von Software beschäftigt haben.

Unter anderem wurde vorgestellt, wie man Game Software mit eXtreme Programming(XP) entwickelt. Dabei konnte man sehen, welche Elemente von XP zur Anwendung kommen, z.B. Pair Programming, User Stories und Continuous Integration.

In einer weiteren Session konnte man sich einen Überblick verschaffen, wie man mit Ruby on Rails eine Webapplikation baut und diese testet. Neben den Routinen, die Ruby on Rails bereits zum Testen mitbringt, wurde der Einsatz von Selenium zum GUI Testing gezeigt - alle automatisiert und integriert.


Mein erstes Barcamp, mein Eindruck: lohnt sich, macht Spass und man lernt viele interessante Leute und deren (teilweise verückte) Ideen kennen.

Was möchte ich tun?

Bisher habe ich das Thema Ruby on Rails mit geringer Wertschätzung immer unter "sollte ich mal irgendwann angehen" gelegt ...

Ok, jetzt ist es soweit. Ich habe mir von einem erfahrenen Ruby on Rails Kollegen Christian Felder ein Buch ausgeliehen: Agile Webdevelopment with Rails.

Get Excited

Nach nunmehr 6 Kapiteln Studium weiss ich eines - das ist DIE Technology um einerseits schnell eine Webapplikation zu realsieren und anderseits dies agil zu tun!

Das Buch selbst ist so aufgebaut, dass man entlang einer Kunden Beziehung einen Shop implementiert. Man trifft den Kunden regemässig und arbeitet die verschiedenen Aufgaben in Interationen ab - gefällt mir sehr gut, und es ist so einfach. Ich entwickle schon seit ein paar Jahren Webapplikation im Java und .NET Umfeld und wenn ich nun nach nur 6 Kapiteln in diesem Buch mal einen Strich machen darf: Es ist so einfach! In der Java und .NET Welt muss man derart viele Handstände machen, um vergleichsweise triviale Dinge zu lösen - in Ruby ist das oft nen Einzeiler!

Der Ruby Erfinder hat mal gesagt: "I wanna be a YES-guy!" - Mit Ruby on Rails hat er mindestens das wohl erreicht!

Next:

Get Started